Variable fonts Printing Output doesn't match Print Preview on Ubuntu

VERIFIED FIXED in Firefox 62

Status

()

defect
VERIFIED FIXED
11 months ago
11 months ago

People

(Reporter: laszlo.bialis, Assigned: lsalzman)

Tracking

(Blocks 1 bug)

62 Branch
mozilla62
x86_64
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox62+ verified)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

11 months ago
[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.
Blocks: 1302685
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?
Flags: needinfo?(lsalzman)
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.
(Assignee)

Comment 4

11 months ago
I am still looking into this at present.
(Assignee)

Comment 5

11 months ago
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
Flags: needinfo?(lsalzman)
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+
Attachment #8981245 - Attachment is obsolete: true

Comment 7

11 months ago
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1003bb0905c5
print font variations as paths for PDF/PS output. r=jfkthame

Comment 8

11 months ago
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/6b0ad567bda4
follow-up - check that dlsym succeeded. r=me

Comment 9

11 months ago
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a1a0759ac719
follow-up - check that dlsym succeeded in ApplyVariations. r=me
Depends on: 1466199

Comment 10

11 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/1003bb0905c5
https://hg.mozilla.org/mozilla-central/rev/6b0ad567bda4
https://hg.mozilla.org/mozilla-central/rev/a1a0759ac719
Status: ASSIGNED → RESOLVED
Last Resolved: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
(Reporter)

Comment 11

11 months ago
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
(Reporter)

Comment 12

11 months ago
I've checked using the latest Nightly 62.0a1 Build ID:20180605100102
(Reporter)

Updated

11 months ago
You need to log in before you can comment on or make changes to this bug.