[webkit-dev] Printer font is different from screen font

[Shinichiro Hamaji]

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 at 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/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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100802/519557a6/attachment.html>