Closed Bug 1576077 Opened 4 months ago Closed 3 months ago

"fake bold" fonts do not print correctly with E10S

Categories

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

68 Branch
Unspecified
Windows
defect

Tracking

()

RESOLVED FIXED
mozilla71
Tracking Status
firefox71 --- fixed

People

(Reporter: v+mozbug, Assigned: lsalzman)

Details

Attachments

(5 files)

Attached file 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.

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.

Component: Untriaged → Layout: Text and Fonts
Product: Firefox → Core

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?

Priority: -- → P3

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.

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?

Flags: needinfo?(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.

Flags: needinfo?(jfkthame)
Status: UNCONFIRMED → NEW
Ever confirmed: true

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?

Flags: needinfo?(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...

Flags: needinfo?(lsalzman)
Assignee: nobody → lsalzman
Status: NEW → ASSIGNED
OS: Unspecified → Windows
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/128540ec53ab
make ScaledFontDWrite remember if it needs synthetic bold. r=jfkthame
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
QA Whiteboard: [qa-71b-p2]
You need to log in before you can comment on or make changes to this bug.