Bug 43340 - Printer font is different from screen font
Summary: Printer font is different from screen font
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Printing (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-02 05:34 PDT by Shinichiro Hamaji
Modified: 2010-08-18 01:43 PDT (History)
6 users (show)

See Also:


Attachments
test case (2.42 KB, text/html)
2010-08-02 05:34 PDT, Shinichiro Hamaji
no flags Details
result for screen (188.32 KB, image/png)
2010-08-02 05:35 PDT, Shinichiro Hamaji
no flags Details
result for printer (245.21 KB, image/png)
2010-08-02 05:36 PDT, Shinichiro Hamaji
no flags Details
Patch v1 (1.73 KB, patch)
2010-08-16 02:08 PDT, Shinichiro Hamaji
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Shinichiro Hamaji 2010-08-02 05:34:37 PDT
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
Comment 1 Shinichiro Hamaji 2010-08-02 05:35:42 PDT
Created attachment 63197 [details]
result for screen
Comment 2 Shinichiro Hamaji 2010-08-02 05:36:21 PDT
Created attachment 63198 [details]
result for printer
Comment 3 Dave Hyatt 2010-08-03 11:30:34 PDT
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.
Comment 4 Shinichiro Hamaji 2010-08-03 20:32:07 PDT
(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!
Comment 5 Shinichiro Hamaji 2010-08-06 01:05:12 PDT
Any one has any thoughts on this? Thanks!
Comment 6 Shinichiro Hamaji 2010-08-16 02:07:35 PDT
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!
Comment 7 Shinichiro Hamaji 2010-08-16 02:08:31 PDT
Created attachment 64480 [details]
Patch v1
Comment 8 Shinichiro Hamaji 2010-08-16 22:46:01 PDT
(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 9 Dimitri Glazkov (Google) 2010-08-17 07:27:54 PDT
Comment on attachment 64480 [details]
Patch v1

WebCore/ChangeLog:9
 +          for chromium isn't implemented yet.
Is it time to implement it? :)
Comment 10 Shinichiro Hamaji 2010-08-17 22:57:39 PDT
(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 11 WebKit Commit Bot 2010-08-18 01:43:11 PDT
Comment on attachment 64480 [details]
Patch v1

Clearing flags on attachment: 64480

Committed r65591: <http://trac.webkit.org/changeset/65591>
Comment 12 WebKit Commit Bot 2010-08-18 01:43:17 PDT
All reviewed patches have been landed.  Closing bug.