Bug 43340 – Printer font is different from screen font

• Component: Printing
• Status: RESOLVED FIXED

[Shinichiro Hamaji]

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

[Shinichiro Hamaji]

Created attachment 63197 [details]
result for screen

[Shinichiro Hamaji]

Created attachment 63198 [details]
result for printer

[Dave Hyatt]

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.

[Shinichiro Hamaji]

(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!

[Shinichiro Hamaji]

Any one has any thoughts on this? Thanks!

[Shinichiro Hamaji]

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!

[Shinichiro Hamaji]

Created attachment 64480 [details]
Patch v1

[Shinichiro Hamaji]

(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!

[Dimitri Glazkov (Google)]

Comment on attachment 64480 [details]
Patch v1

WebCore/ChangeLog:9
 +          for chromium isn't implemented yet.
Is it time to implement it? :)

[Shinichiro Hamaji]

(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.

[WebKit Commit Bot]

Comment on attachment 64480 [details]
Patch v1

Clearing flags on attachment: 64480

Committed r65591: <http://trac.webkit.org/changeset/65591>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.