Created attachment 63196 [details] test case Filing a bug for https://lists.webkit.org/pipermail/webkit-dev/2010-July/013705.html I'll post a test case. With this HTML, the line wrappings are inconsistent between screen and printer. Note that this happens only on Mac. Mac Safari: FAIL Win Safari: OK Mac Chromium: FAIL Win Chromium: OK Linux Chromium: OK
Created attachment 63197 [details] result for screen
Created attachment 63198 [details] result for printer
This is probably caused by NSFont's renderingMode method, which is used internally by: WKGetGlyphTransformedAdvances Last time I looked at the AppKit source (years ago), the renderingMode returned integral widths for glyphs for screen fonts, but non-integral widths for printer fonts. Lucida Grande was an exception and always subpixel positioned. This was years ago though, but I suspect is the root of the problem. We could just always subpixel position, but then we wouldn't match AppKit.
(In reply to comment #3) > This is probably caused by NSFont's renderingMode method, which is used internally by: > > WKGetGlyphTransformedAdvances > > Last time I looked at the AppKit source (years ago), the renderingMode returned integral widths for glyphs for screen fonts, but non-integral widths for printer fonts. I see. Sounds like we might want to use non-integral widths even for screen fonts. Is incompatibility with AppKit serious? I'm also curious if subpixel positioning won't break web compatibility. If these concerns are not so important, I'd like WebKit uses non-integral widths. If I understand correctly, I cannot see the code from outside Apple, right? If so, can I request the change? > Lucida Grande was an exception and always subpixel positioned. Thanks for the info. I confirmed we can get the same result between screen and printing with Lucida Grande. Please let me know if there are some other workarounds for this. Thanks for your comments!
Any one has any thoughts on this? Thanks!
I've chatted with David about this bug (thanks David!). Ideally, we want to use printer font even for screen as it's high quality. However, David worried that we may break compatibility by using printer fonts on screen. I propose to use screen fonts even for printing only on Mac Chromium for now. Because - Changing screen fonts of both Mac Safari and Mac Chromium can introduce compatibility issues and it seems to be difficult to make this decision soon. - If we change screen font only for Mac Chromium, it means there will be discrepancy of screen rendering between Mac Safari and Mac Chromium. Difference of printing result would be more acceptable. - With this change, we can check if users complain about lower quality fonts on printing using Chromium's dev-channel. Patch will come soon later. Any comments will be appreciated!
Created attachment 64480 [details] Patch v1
(Adding dglazkov) Hi Dimitri, I'm not sure who's good reviewer to make this kind of decision on chromium. Could you tell me a good reviewer for this or review this patch by yourself? Thanks!
Comment on attachment 64480 [details] Patch v1 WebCore/ChangeLog:9 + for chromium isn't implemented yet. Is it time to implement it? :)
(In reply to comment #9) > (From update of attachment 64480 [details]) > WebCore/ChangeLog:9 > + for chromium isn't implemented yet. > Is it time to implement it? :) Good point :) Actually, I was planning to implement it once after Chromium DRT becomes ready. I don't know the status of it well, but I'll look into it.
Comment on attachment 64480 [details] Patch v1 Clearing flags on attachment: 64480 Committed r65591: <http://trac.webkit.org/changeset/65591>
All reviewed patches have been landed. Closing bug.