Printer font is different from screen font
Hi, I've noticed WebKit uses slightly different font size for printing on Mac. My colleague told me Mac's font API has a feature to select the best font for printing. This feature isn't good for a team in Google because they want exactly same results between screen and printing. I searched a workaround for this, but I couldn't find. I'm not sure if it actually improves the printing results, so it would be best if we can remove this code (FontDescription::usePrinterFont). But I guess this proposal will be objected :) Another proposal is adding a -webkit prefixed CSS property to allow users to customize the behavior. Like -webkit-font-media: auto | printer | screen (auto is the default) I'm not sure if this is a good name though. Does this plan sounds good? If so, we'd like to start implementing this. Any comments will be really appreciated. Thanks!
On Jul 30, 2010, at 2:10 AM, Shinichiro Hamaji wrote:
I've noticed WebKit uses slightly different font size for printing on Mac.
We should discuss specifics instead of this broad issue. There’s a good chance this is something that has been misdiagnosed.
My colleague told me Mac's font API has a feature to select the best font for printing.
Your colleague may be talking about the -[NSFont printerFont] method. That method is used to select a font that is supported for printing. It is not optimizing for printing, but rather must be used to guarantee that WebKit doesn’t try to use a font for printing that is incompatible with the printing machinery. The documentation for this is at <http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSFont_Class/Reference/Reference.html#//apple_ref/occ/instm/NSFont/printerFont>.
This feature isn't good for a team in Google because they want exactly same results between screen and printing.
We’ll have to discuss a specific example. You could test this by modifying your copy of WebKit to turn bypass the calls to the printerFont method in FontCacheMac.mm, FontMac.mm, and SimpleFontDataMac.mm. If you get your improved results from that we can continue the discussion. I think it’s more likely you will find that printing doesn’t work any more. Before we start discussing adding features and modes to control this behavior you should do the experiment to see if this would do something helpful. -- Darin
Thanks for your feedbacks! I did a few experiments before my email post but I forgot to mention about it. Sorry that my first post was not so specific :( Now I've done a few more experiments. Let me explain what I've seen so far. * The issue The example HTML in question is https://bugs.webkit.org/attachment.cgi?id=63196 Here is a screenshot for this HTML on my Mac OSX 10.5: https://bugs.webkit.org/attachment.cgi?id=63197 And this is the printed image for this HTML: https://bugs.webkit.org/attachment.cgi?id=63198 Though this screenshot was taken from its print preview, I confirmed that this result agrees with the paper my HP printer produced. You can see line wrappings are inconsistent between them. On the screen, the first line wraps after the word "tempor", but with the printer, the first line wraps after "eiusmod". * Experiments I created a super simple patch with which we always uses the screen font even for printing. The patch is diff --git a/WebCore/platform/graphics/FontDescription.h b/WebCore/platform/grap hics/FontDescription.h index 86a4349..3ef4e85 100644 --- a/WebCore/platform/graphics/FontDescription.h +++ b/WebCore/platform/graphics/FontDescription.h @@ -84,7 +84,8 @@ public: FontWeight lighterWeight() const; FontWeight bolderWeight() const; GenericFamilyType genericFamily() const { return static_cast<GenericFamilyType>(m_genericFamily); } - bool usePrinterFont() const { return m_usePrinterFont; } + //bool usePrinterFont() const { return m_usePrinterFont; } + bool usePrinterFont() const { return false; } // only use fixed default size when there is only one font family, and that family is "monospace" bool useFixedDefaultSize() const { return genericFamily() == MonospaceFamily && !family().next() && family().family() == "-webkit-monospace"; } FontRenderingMode renderingMode() const { return static_cast<FontRenderingMode>(m_renderingMode); } I printed the example HTML with this modification using my HP printer and this time the print result agreed with the screen. I also printed the document, changing scale smaller and bigger. The results of both attempts were OK. I also printed Apple's top page and again the result was fine. I did these experiments just with one printer so other printers would stop working with this change. I also created another simple patch with which WebKit always uses printer fonts. I checked a dozen of random websites and didn't see something broken. I printed the example HTML and of course the printed result agreed with the screen. Please let me know if there are something I should check. Thanks! On Sat, Jul 31, 2010 at 3:27 AM, Darin Adler <darin@apple.com> wrote:
On Jul 30, 2010, at 2:10 AM, Shinichiro Hamaji wrote:
I've noticed WebKit uses slightly different font size for printing on Mac.
We should discuss specifics instead of this broad issue. There’s a good chance this is something that has been misdiagnosed.
My colleague told me Mac's font API has a feature to select the best font for printing.
Your colleague may be talking about the -[NSFont printerFont] method. That method is used to select a font that is supported for printing. It is not optimizing for printing, but rather must be used to guarantee that WebKit doesn’t try to use a font for printing that is incompatible with the printing machinery.
The documentation for this is at < http://developer.apple.com/mac/library/documentation/Cocoa/Reference/Applica...
.
This feature isn't good for a team in Google because they want exactly same results between screen and printing.
We’ll have to discuss a specific example.
You could test this by modifying your copy of WebKit to turn bypass the calls to the printerFont method in FontCacheMac.mm, FontMac.mm, and SimpleFontDataMac.mm. If you get your improved results from that we can continue the discussion. I think it’s more likely you will find that printing doesn’t work any more.
Before we start discussing adding features and modes to control this behavior you should do the experiment to see if this would do something helpful.
-- Darin
participants (2)
-
Darin Adler
-
Shinichiro Hamaji