1576077 - "fake bold" fonts do not print correctly with E10S

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect, P3)

Description

[Glenn Linderman]

Attachment: printing-bold.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Made web page using fonts without a bold family member. Used <b> for some of the text in those fonts.

Actual results:

Looked bold on screen, looked bold in print preview. Real print was not bold.

Expected results:

Real print should be bold.

OK, so then, in desperation, turned off E10S using
set MOZ_FORCE_DISABLE_E10S=1

Then real print IS bold. So something about E10S has broken the ability to print fake-bold fonts in bold. I can't see that anyone else has expected, documented, or reported this consequence of E10S.

I'm curious how fake bold is done: is the algorithm documented precisely somewhere? The results are pleasing for the fonts I'm using on Windows, such that I haven't made bold versions of the fonts in use... but maybe I should somehow apply the fake bold algorithm and make such fonts, if that is possible, and I can figure out how.

Comment 1

[Glenn Linderman]

Attachment: Bold does NOT work with E10S Enabled

Comment 2

[Glenn Linderman]

Attachment: Bold works with E10S Force-Disabled

Comment 3

[Glenn Linderman]

Attachment: pinyin font used in testing

Comment 4

[Glenn Linderman]

The other font used for testing is too big to attach: SimSun (Founder Extended) but is available from http://archive1.village.virginia.edu/spw4s/fonts/ among other places.

Comment 5

[Cameron McCormack (:heycam)]

On Windows, we rely on the platform text APIs to handle the bold synthesis for us, and I'm not sure what the exact algorithm is.

It's surprising that e10s has an effect here. Maybe we end up using a different text backend while printing?

Comment 6

[Glenn Linderman]

I found e10s to be a surprising cause too... I wouldn't have expected Firefox to use a different backend while printing without e10s or with e10s.

I would rather expect that the printing backend was depending on some "global" (some process context) being set by the front end, and "accidentally" being used by the printing, and now that they are in separate processes, that global isn't getting set the right way.

Comment 7

[Cameron McCormack (:heycam)]

Jonathan, is it plausible that when we generate the PDF (using Skia, right?) that it somehow doesn't handle synthetic bold correctly? And that e10s-or-not could affect that?

Comment 8

[Jonathan Kew [:jfkthame]]

IIRC, when e10s is enabled, printing relies on generating a moz2d recording in the content process and then passing that recording over to the parent process to print it. I wonder if the "fake-boldness" is not being captured appropriately in that recording.

Comment 9

[Cameron McCormack (:heycam)]

I haven't tested, but in NativeFontResourceDWrite::CreateUnscaledFont, which I think is what we end up in when replaying the recorded commands, we use DWRITE_FONT_SIMULATIONS_NONE:

https://searchfox.org/mozilla-central/rev/a777ff11b6d700a698c61e5bd17e73b044304494/gfx/2d/NativeFontResourceDWrite.cpp#264

and we don't serialize the value of UnscaledFontDWrite::mSimulations in RecordUnscaledFont.

I'm not really familiar with this Moz2D recording code though. Lee, does this sound right? Where's the right place to be serializing the value of UnscaledFontDWrite::mSimulations from?

Comment 10

[Lee Salzman [:lsalzman]]

(In reply to Cameron McCormack (:heycam) from comment #9)

I haven't tested, but in NativeFontResourceDWrite::CreateUnscaledFont, which I think is what we end up in when replaying the recorded commands, we use DWRITE_FONT_SIMULATIONS_NONE:

https://searchfox.org/mozilla-central/rev/a777ff11b6d700a698c61e5bd17e73b044304494/gfx/2d/NativeFontResourceDWrite.cpp#264

and we don't serialize the value of UnscaledFontDWrite::mSimulations in RecordUnscaledFont.

I'm not really familiar with this Moz2D recording code though. Lee, does this sound right? Where's the right place to be serializing the value of UnscaledFontDWrite::mSimulations from?

This is a bit complicated as it needs to support some WebRender stuff too. I probably need to make UnscaledFontDWrite support both regular and bold fonts, rather than trying to serialize the simulations. Otherwise the management just becomes hellish...

Comment 11

[Lee Salzman [:lsalzman]]

Attachment: Bug 1576077 - make ScaledFontDWrite remember if it needs synthetic bold. r?jfkthame

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/128540ec53ab
make ScaledFontDWrite remember if it needs synthetic bold. r=jfkthame

Comment 13

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/128540ec53ab