My company is using HiqPdf for some time now, and we had a discussion on what rendering engine HiqPdf parses its html. We couldn't find it on the website of HiqPdf itself nor stackoverflow.
http://www.hiqpdf.com/
I would suspect Webkit but does anyone know this for sure?
HiQPdf rendering engine is compliant to WebKit standard. It accepts the -webkit-prefixed CSS extensions.
webkit specific styles work for HiQPdf, so I'm going to agree that webkit is the rendering engine, though I can't find any documents to support that either.
Related
Yesterday a colleague of mine noticed a big inconsistency between the rendering of the google Roboto Condensed font on our site, when displaying on Firefox and Chrome. On Firefox the font doesn't seem to be the same at all.
I did some reading here on stackoverflow, but I can't seem to understand if this problem is the same as mine, because the person is using local fonts, and I'm serving directly from google.
Also it seems like somewhere in the wordpress installation, the Roboto Condensed font is being called twice - once imported directly from the theme, once imported by a plugin we're using to customize the menu of the site.
On the other hand, I read that different font weights being used on the same font might produce different results in different browsers, but couldn't grasp what is the right way to use them.
Any help will be appreciated. Here is the site that I'm talking about:
www.podmosta.bg
Best Regards,
Kostadin
This is resolved now.
Turned out that I wasn't loading Roboto Condensed with included cyrillic characters included. Just loaded up the proper version of the font and everything went fine.
I'm making a WebKit-based text editor app for Mac, and I need to find a way to zoom the document in and out.
I've seen this StackOverflow article here, it suggests just scaling the view that Webkit is rendered into. The problem is, since Webkit doesn't know about it, this breaks things like drag & drop and causes Javascript to report the wrong cursor locations. Unfortunately, for some reason, the Cocoa WebKit API only supports scaling text up or down, not the whole page.
Safari and Chrome are both able to do this properly. I've gone as far as to look through the Chromium source code to figure out how it's done, but unfortunately it's using a completely different cross-platform API.
Any advice would be greatly appreciated. I'm not opposed to using private APIs, if I can figure out how to use them in a safe way.
-Keaton
The APIs for doing this aren't currently public, but they've been around for years and aren't likely to change. You can find them in WebKit's WebViewPrivate.h header. You won't find that header on your system, so you'll have to redeclare those methods yourself in a category. Something like:
#interface WebView (Zoom)
- (IBAction)zoomPageIn:(id)sender;
- (IBAction)zoomPageOut:(id)sender;
- (IBAction)resetPageZoom:(id)sender;
#end
Another option is just to set the CSS zoom property on the html element in your editor. You can do that in markup (<html style="zoom: 1.5">) or in JavaScript (document.documentElement.style.zoom = "1.5"). That doesn't require using any private APIs.
I have a JSF application that is updating sections of itself dynamically via AJAX.
It runs ridiculously slow in IE7, but later versions of IE are fine, along with Firefox and Chrome.
I suspect it is an issue with client-side rendering performance - it's a pretty big chunk of HTML that is being updated dynamically, and there's not much JS code besides updating the DOM with the response (analogous to $(element).html(response) in jQuery).
Can this be tracked down to specific elements or not? For example, are there specific elements or CSS styles to focus on? Where else should I be looking?
Thanks!
A quick work around is to use chromeframe.
It renders the page use chrome engine and you can put the frame in IE6,7 and 8
http://code.google.com/chrome/chromeframe/
Dynatrace AJAX edition should be able to help you track down the issues - http://ajax.dynatrace.com/ajax/en/
Presume you're using jQuery are you using an up-to-date version?
I'm sure this has been discussed before, but I can't find any canonical question / answer.
Currently, IE9 and Firefox 4+ both use different font rendering that produces (for some) more blurry fonts but overall better kerning and more consistent results. Also, it renders non-standard fonts on Windows much better. I've have not done a thorough investigation, but I think it has to do with the fact that both IE9 and Firefox use now a different graphics layer which in apparently renders fonts differently. Also, the reason some of the standard fonts such as Arial, Tahoma etc. look in Firefox the same as 10 years ago is that it actually has a list of exceptions for them (look for gfx.font_rendering.cleartype_params.force_gdi_classic_for_families).
So far so good. The problem is Chrome. It still uses the old font rendering that makes the non-standard fonts practically unusable. Just for illustration, the font I had in mind was: http://www.google.com/webfonts/specimen/Play. Just open the sample in Firefox/IE9 and Chrome and you should see the difference. Is there anything I can do? Or should I look for a more optimized font.
Update: I see it's a common problem: the headings on http://www.smashingmagazine.com look very jaggy in Chrome.
Update: Sample image:
I have read that Chrome (originally Chromium) has anti-aliasing issues that's why it's jaggy.
Using font-faces also makes a difference than using local fonts in your system. So, all we can do is just wait until they fix this issue or help the Chromium Project if you can.
Known issue. You can try gdipp or MacType.
Copying my anwswer from Making CSS3 #font-face font rendering play nice with ClearType on Windows
A similar question here: Font-face embedded fonts look fuzzy in Windows 7 browsers got an answer that solved the same issue for me.
The fontsquirrel font generator http://www.fontsquirrel.com/fontface/generator optimizes fonts and adds them with hinting/rendering info that helps the windows font rendering engine render them better. It also generates smaller files, which will download faster.
I am having my first foray into website design and I am learning a lot. I am also now seeing why web developers are not a huge fan of developing for Internet Explorer. Nothing seems to work how I expect. However, since the website has to work cross-browser, I am spending time looking at it in Firefox, Chrome, and IE. Something that is very non-obvious to me, however, is how to tell where problems lie in the website.
For example, the layout of one of my pages forces a footer to the bottom of the page. It looks great in Chrome and Firefox, but there's something broken in IE that make the footer align to the right (and cause a horizontal scroll to appear). I have played around with the code, but nothing really is responding to how I want in IE (even though it does in other browsers).
Are there any tools that can help "debug" the problems on a web site so fixing it is more than just a trial-and-error approach? Thanks.
One of my favorites that works in all browsers is X-Ray. You simply stick the link on that page into a bookmark and it loads some external JavaScript on top of the page you're testing. It reveals a bunch of parameters about the DOM object you click on, as well as its hierarchy in the model.
As for your specific footer problem, I would look to a potential lack of clearing of floats and divs that are wider than their parent containers somewhere up the line.
There are frameworks like GWT, ext-js, YUI which hide a lot of the browser bugs from you. But today (near the end of 2009), there still isn't a good, realiable way to narrow down browser issues and to fix them.
PS: I'm collecting tools that help during debugging here: Which tools do you use to debug HTML/JS in your browser?
I assume you have checked that your code is valid, with
HTML validator, for example: W3C Markup Validation Service
CSS checker, for example: W3C CSS Validation Service
And, of course, you should have correct doctype in your html file. Without doctype, some browsers go to quirks mode to emulate bugs in old browsers.
A cross-browser JavaScript library, like jQuery and its UI components, can be very helpful in avoiding idiosyncrasies between browsers. Microsoft provides the IE Developer Toolbar, it's not quite as easy to use as Firebug, but can still be very helpful. A Just-In-Time debugger like MS Script Debugger or Visual Studio are also a time saver.
I like Firebug for Firefox
and IE8 has Developer Tools from the tools menu and IE Developer Toolbar for older versions.
Chrome has similar tools from the page menu.
All of which allow you to see elements on the page as they are rendered in their specific browsers, which I usually find very helpful in debugging browser specific problems.