1757132 - [macOS] v-font website cannot be printed to PDF

Status: NEW

(Core :: Printing: Output, defect)

Description

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Attachment: br console error.png

Affected versions

• Firefox 98.0b9
• Firefox 99.0a1

Affected platforms

• macOS 11.6.4

Steps to reproduce

1. Launch Firefox and access v-fonts.com
2. Print preview the page and select save to PDF as destination
3. Print the page

Expected result

• The page is printed without issues

Actual result

• An error is thrown and the PDF is not saved

Regression range

• Will see for a regression

Additional notes

• The issue can be seen in the following attachment
• Windows and Ubuntu are not affected.
• The browser console error can be seen in the attachment.

Comment 1

[Jonathan Kew [:jfkthame]]

This appears to be specifically related to the "Wavefont" example; if I disable that font via devtools, the rest of the v-fonts.com site gets saved to PDF successfully.

Comment 2

[Jonathan Kew [:jfkthame]]

As a guess: perhaps this is triggered by the lack of any space in the Wavefont font. (The old Apple truetype spec appeared to require space to be supported in some way; not all software necessarily depends on this, but there may be an assumption somewhere that is failing because of it.)

Comment 3

[Jonathan Kew [:jfkthame]]

Interestingly, this doesn't affect Safari: it works OK to create a PDF that includes the Wavefont sample.

Comment 4

[Simona Badau, Desktop QA]

Narrowed regression window to:

Last good revision: 15ffd69c83be752a28fc40a5db6b6859452fa41f (2019-09-25)
First bad revision: 1d189ae70326e415f8590e3aeee24885fb8418bc (2019-09-26)

Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=15ffd69c83be752a28fc40a5db6b6859452fa41f&tochange=1d189ae70326e415f8590e3aeee24885fb8418bc

Comment 5

[Jonathan Kew [:jfkthame]]

(In reply to Jonathan Kew (:jfkthame) from comment #2)

As a guess: perhaps this is triggered by the lack of any space in the Wavefont font. (The old Apple truetype spec appeared to require space to be supported in some way; not all software necessarily depends on this, but there may be an assumption somewhere that is failing because of it.)

Adding space to the cmap of the font doesn't seem to make any difference. But also, on inspection it turns out this is a CFF2 font, not TrueType with variations, so the old TT spec requirements wouldn't be relevant.

So this was affected by bug 1577799 because one of the changes in the OTS 8.0.0 release was:

• Support CFF2 table, including variations support.

Prior to that, the Wavefont resource was simply dropped as unsupported, and a fallback rendered.

Comment 6

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

:csasca, since this bug is a regression, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.

Comment 7

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

:RyanVM, since you are the author of the regressor, bug 1577799, could you take a look?
For more information, please visit auto_nag documentation.

Comment 8

[Marco Castelluccio [:marco]]

The bot should be smart enough not to re-needinfo here, so removing "[no-nag]".

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Jonathan, is there anything actionable for us to do here?

Comment 10

[Jonathan Kew [:jfkthame]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #9)

Jonathan, is there anything actionable for us to do here?

In principle, yes -- given that Safari successfully generates a PDF with the "problem" font here, we should try to figure out why it's failing for us.

It'd be interesting to know if all CFF2 fonts fail similarly, or if it is something specific to this one font.

The problem might well lie somewhere in the cairo-quartz layer that interfaces between gecko and coregraphics PDF output, in which case we can potentially debug and fix it (or at least file an actionable issue upstream). But it'll take some debugging effort to figure out which component is actually at fault here.