[Version]: 62.0a1 [Build ID]: 20180523221148 [Affected platforms]: Ubuntu 16.04 x64 and x32 [Prerequisites]: Set pref gfx.downloadable_fonts.otl_validation = false [Steps]: 1. Launch Nightly 61.0a1 with a new profile 2. Open https://www.axis-praxis.org/specimens/decovar and https://bug1451327.bmoattachments.org/attachment.cgi?id=8970158 3. Select and check Print Preview 4. Print the page and compare it to the Print Preview [Expected result]: The printed page should look exactly like the Print Preview. [Actual result]: For the first example https://www.axis-praxis.org/specimens/decovar the print doesn't match the Print Preview at all (check picture attached). For the second example, on the Print Preview the title is in Bold, on the Print itself the title is normal font.
Lee, any ideas about this? It looks like variation settings simply aren't making it through to the printed output at all, so we get a glyphs from some default instance, but positioned according to metrics from whatever variation was supposed to be used (and so they'll often have lousy, erratic spacing). At first I assumed this was just a question of hooking up the variations data in the moz2d recording stream on Linux, as it looks like it's not currently handled there. But after trying a patch locally to add variation support there, I'm still seeing the same problem: printed output doesn't apply any variations. So I guess there's some other stage of the process where they're getting dropped, but I'm not sure where. Can you take a look and see if you can figure out what's wrong?
FWIW, here's my current WiP to add variations to the recording. This does NOT fix the bug here, sadly.
Sounds like this would be good to fix for 62, but is not currently considered a blocker for shipping the feature to release. I can track it for 62 for now.
I am still looking into this at present.
This fixes some issues with the original patch: 1) ensures the FT_Face is cloned for different variation settings so we don't accidentally overwrite them 2) ensures gfxFcPlatformFontList, which already implemented the cloning, cleans up the cloned FT_Faces 3) modifies DrawTargetCairo so that when printing to PDF/PS we instead submit the glyphs as paths so that we don't have to implement font subsetting for font variations 4) adds a pref for controlling this behavior
Assignee: nobody → lsalzman
Status: NEW → ASSIGNED
Attachment #8982316 - Flags: review?(jfkthame)
Comment on attachment 8982316 [details] [diff] [review] print font variations as paths for PDF/PS output Review of attachment 8982316 [details] [diff] [review]: ----------------------------------------------------------------- Thanks! ::: gfx/thebes/gfxPrefs.h @@ +724,5 @@ > DECL_GFX_PREF(Live, "mousewheel.transaction.timeout", MouseWheelTransactionTimeoutMs, int32_t, (int32_t)1500); > > DECL_GFX_PREF(Live, "nglayout.debug.widget_update_flashing", WidgetUpdateFlashing, bool, false); > > + DECL_GFX_PREF(Live, "print.font-variations-as-paths", PrintFontVariationsAsPaths, bool, true); Please also add the new pref to all.js, so that it can be found in the about:prefs list.
Attachment #8982316 - Flags: review?(jfkthame) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/1003bb0905c5 print font variations as paths for PDF/PS output. r=jfkthame
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/6b0ad567bda4 follow-up - check that dlsym succeeded. r=me
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/a1a0759ac719 follow-up - check that dlsym succeeded in ApplyVariations. r=me
Checked on Ubuntu 16.04 from 2 different stations and a laptop, printing worked and looked as expected, the same as the print preview.
Status: RESOLVED → VERIFIED
I've checked using the latest Nightly 62.0a1 Build ID:20180605100102
You need to log in before you can comment on or make changes to this bug.