1823888 - Printing to pdf doubles synthesized bold characters on Windows and macOS, when printed at small print font-size

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[MarjaE]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:109.0) Gecko/20100101 Firefox/111.0

Steps to reproduce:

I tried to print a page containing a table and bold text.

http://amizaur.prv.pl/www.wargamer.org/GvA/weapons/british_hardness_veh.html

I used the system print dialogue because modals trigger my migraines. I scaled everything down by 50% so that tables wouldn't get cut off.

Actual results:

The bold text in the headers got doubled up, making them unreadable.

This is the same as bug 488159, which was closed, and can't be re-opened.

Expected results:

The bold text should not get doubled up.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Printing: Output' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Could you attach the output of printing that on your system? Does it repro when printing as PDF or only when actually sent to the printer?

Comment 3

[MarjaE]

Attachment: Printing with my usual css and 50% scale

Comment 4

[MarjaE]

So yes, it does reproduce with pdf.

It depends on the scale factor when printing.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:dholbert, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[Daniel Holbert [:dholbert]]

I can't reproduce. I tried macOS 10.15 (not quite the same as yours but the closest I've got available.)

I did the following, starting with a relatively-fresh installation/Firefox configuration:

1. Visit http://amizaur.prv.pl/www.wargamer.org/GvA/weapons/british_hardness_veh.html
2. Click the red "x" for the ad at the top-center that covers up part of the table.
3. Cmd+P
4. Scroll down, click "Print using the system dialog"
5. Select "Scale: 50%" and uncheck the "Ignore scaling and shrink to fit page widht"
6. Click PDF, choose "Open in Preview"
7. Inspect the resulting PDF.

I did notice that I'm getting a different font from what your attached PDF shows. I suspect that's because you've got some locally-applied CSS to force a particular font (your attachment name mentions "with my usual CSS"). [REQUEST]: Could you clarify what your "usual CSS" is? (In particular the font, though other aspects may be relevant/necessary too.)

(I wonder if what's going on here is that your font doesn't include a bold face, and we're doing a synthetic-bold which involves drawing the characters twice, and that doesn't look great under some circumstances?)

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #6)

I I tried macOS 10.15 (not quite the same as yours but the closest I've got available.)

Correction: I misread, the version that I tested actually was 10.14 (specifically 10.14.6, Mojave). So OS-version isn't a relevant difference between our configurations, fortunately.

Comment 8

[Daniel Holbert [:dholbert]]

Aha, ok. Looking at the source of the PDF, it looks like you're rendering the page using the "Andika" font.

I can reproduce the issue (at least on macOS 10.14.6) if I install "Andika Regular" TTF file from https://fonts.google.com/specimen/Andika , and install the "Stylus" add-on and add a stylesheet rule * { font-family: Andika !important; } for the site in question; and THEN I follow my STR from comment 6.

If I take the additional step of installing Andika-Bold.ttf from the Google Fonts provided zip bundle, then I don't get the issue.

So this seems to be an issue where synthetic bold has visibly-doubly-stroked characters for Andika Regular.

Comment 9

[Daniel Holbert [:dholbert]]

(Just to confirm that we're getting the same results -- does the issue go away for you, too, if you explicitly install Andika-Bold.ttf from the "Download Family" zip on https://fonts.google.com/specimen/Andika ? [assuming I'm correct about that being the font you're using])

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (reproduces the issue in Firefox on mac/win if you print with 50% print-scaling)

Comment 11

[Daniel Holbert [:dholbert]]

Testcase 1 reproduces the issue for me (using Google-Fonts-provided Andika-Regular.ttf as an included web-font), on macOS Catalina 10.14.6 as well as on macOS Ventura 13.3.

At 50% scale, it's egregiously bad, as in the reporter's attachment. I think that's the crux of the issue here.

The doubling is also barely-visible at 100% scale if you look very closely (you can see two overlapping dots above the "i" for example, and for the period; and you can see two corners on the curved ends of "t", "s", "e", and "y" characters). But Safari produces this same rendering as we do there. And their 50%-scale rendering looks like their (and our) 100%-scale-rendering, but just scaled down.

On Linux, I can't reproduce any issues; my PDF seems to end up with the regular font face, no synthetic bolding, I think?

Comment 12

[Daniel Holbert [:dholbert]]

Testcase 1 reproduces the issue for me in Firefox Nightly 113 on Windows 11, too. (50% print-scale looks egregiously-bad; 100% print-scale has the barely-visible issues with dots and double-corners on curved ends that I described in comment 11).

Chrome has no issues there (not even the barely-visible issues). They must use some sort of different approach to synthetic bold.

Comment 13

[Daniel Holbert [:dholbert]]

Aha, actually this is broken in Safari as well, if I explicitly request a small font-size, font-size:8px and print at 100% scaling.

I think the difference I'm seeing between Safari vs. Firefox in comment 11 might just be that Safari is rendering 16px-sized text and scaling it down, vs. Firefox is rendering 8px font-size text, or something to that effect; and on an apples-to-apples comparison, we actually produce the same result.

So at this point it's looking a little bit like this font (Andika Regular) has something specific to it that makes its synthetic-bold rendering look bad at small font sizes, at least with the approach to synthetic-bold that Firefox and Safari use (though not Chrome).

jfkthame, do you have any insights here? Is there anything obvious that we (and Safari) are doing wrong here to produce this bad outcome with the small font-size, or is this just a bug in the font itself?

Comment 14

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (reproduces the issue in Firefox and Safari, printed at default 100% print scale)

Comment 15

[MarjaE]

I can confirm that installing the updated Andika, all 4 versions, solves the original issue for me, so I think this shows a synthetic bold issue.

I have a lot of user css but I don't think it'll help here.

Comment 16

[Daniel Holbert [:dholbert]]

(In reply to MarjaE from comment #15)

I can confirm that installing the updated Andika, all 4 versions, solves the original issue for me, so I think this shows a synthetic bold issue.

That's good to hear! Thanks for confirming that.

Comment 17

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 printed with Firefox Nightly 113 on macOS [looks broken]

Comment 18

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 printed with Safari 16.4 on macOS [looks broken]

Comment 19

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 printed with Chrome 111 on macOS [looks fine]

Comment 20

[Jonathan Kew [:jfkthame]]

This is somehow related to the synthetic-bold computations here, or the equivalent inside webrender.

I tried applying a hack in gfxFont:

diff --git a/gfx/thebes/gfxFont.cpp b/gfx/thebes/gfxFont.cpp
--- a/gfx/thebes/gfxFont.cpp
+++ b/gfx/thebes/gfxFont.cpp
@@ -2285,6 +2285,12 @@ void gfxFont::Draw(const gfxTextRun* aTe
   }
   auto* textDrawer = aRunParams.textDrawer;
 
+  // Don't do synthetic bold via webrender.
+  if (textDrawer && ApplySyntheticBold()) {
+    textDrawer->FoundUnsupportedFeature();
+    return;
+  }
+
   fontParams.obliqueSkew = SkewForSyntheticOblique();
   fontParams.haveSVGGlyphs = GetFontEntry()->TryGetSVGData(this);
   fontParams.haveColorGlyphs = GetFontEntry()->TryGetColorGlyphs();

to take webrender out of the equation, forcing synthetic-bold rendering to fall back to the blob-image path, but this did not appear to make any difference.

What we're doing is determining an amount of "boldness" (horizontal expansion of the glyphs) to apply, based on the font size, and then calculating how many "strikes" with an offset of one device pixel each are required to create that effect. We attempt to take account of the transform matrix in effect -- and that's where things break down in the printing case, because it seems we encounter a very different matrix, our calculated xscale factor gets large, and we end up thinking that a "one pixel" offset is way too big.

(It probably doesn't help that for output such as PDF, the concept of "one device pixel" isn't really meaningful, so I don't know what we should expect to happen here.)

I don't really understand how scaling works in the case of print output, tbh. But empirically, I'm finding that clamping the used xscale value in relation to the font size seems to avoid the bad result here.

Comment 21

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1823888 - Clamp scale factor used in computing synthetic-bold offsets, to avoid bad print/pdf output. r=dholbert

Comment 22

[Jonathan Kew [:jfkthame]]

Note that so far, I have tested this only on macOS with save-to-pdf output; no physical printer currently on hand.

Comment 23

[Daniel Holbert [:dholbert]]

Attachment: photo comparing testcase 2 in macOS Nightly (top) vs. patched local build (bottom), printed with Daniel's physical printer

(In reply to Jonathan Kew [:jfkthame] from comment #22)

Note that so far, I have tested this only on macOS with save-to-pdf output; no physical printer currently on hand.

Here's a comparison with testcase 2 printed to my physical printer (Brother HL-2280DW).

Current Nightly is on top, with visibly doubled-up glyphs, to the point where i renders as two distinct characters (no overlap at all between the two strikes), and v in visibly looks like a skinny "w". Looks like comment 17, basically.

Patched build is on the bottom, and looks quite nice!

Comment 24

[Daniel Holbert [:dholbert]]

I also tried a modified testcase & confirmed that bold text still looks bolder than regular text (i.e. synthetic bolding is still making a user-visible difference) in a physical printout, with my local build that includes jfkthame's patch.

Comment 25

[BugBot [:suhaib / :marco/ :calixte]]

There is an r+ patch which didn't land and no activity in this bug for 2 weeks.
:jfkthame, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.

Comment 26

[Daniel Holbert [:dholbert]]

Yeah, this is nearly landable, modulo some small nits on phabricator ( https://phabricator.services.mozilla.com/D174864#5770427 ), mostly adding a few explanatory comments.

Comment 27

[Jonathan Kew [:jfkthame]]

I've updated/expanded the comments, and just lando'd this.

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f8e228c8856b
Clamp scale factor used in computing synthetic-bold offsets, to avoid bad print/pdf output. r=dholbert

Comment 29

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/f8e228c8856b

Comment 30

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Reproducible on a 2023-05-02 Nightly build on Windows 10.
Verified as fixed on Firefox 114.0b4(build ID: 20230514175823) and Nightly 115.0a1(build ID: 20230515215623) on Windows 10 and macOS 12.