STR:

• open https://commons.wikimedia.org/wiki/File:HelloWorld.svg
• print and save as mozilla.pdf
• run qpdf --check mozilla.pdf

Result:

checking mozilla.pdf
PDF Version: 1.5
File is not encrypted
File is not linearized
WARNING: mozilla.pdf: file is damaged
WARNING: mozilla.pdf (object 3 0, offset 15): expected 3 0 obj
WARNING: mozilla.pdf: Attempting to reconstruct cross-reference table
WARNING: mozilla.pdf: object 3 0 not found in file after regenerating cross reference table

The pdf contains an object with ref 27 0 and this one makes ref to 3 0 but 27 0 is not used.
It isn't really a bug since the pdf is readable but it'd be nice to generate a valid pdf.

Do you know if it's a recent regression? We recently updated cairo.

With mozregression I got:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e02533b47a679aeeaa52bb5a88e04cdbbfc251e2&tochange=26b31c2612b4b6ea5b1771b3bdef1031f457a98f

(fun fact: I was testing bug 454059)

Is this reproducible only with an SVG document [edit: a page that includes an SVG image], or can you also reproduce a similar issue with other HTML docs?

Easily reproducible in printing doc containing:

<a href="https://www.mozilla.org">mozilla</a>

The generated pdf contains:

11 0 obj
[
  3 0 R
  4 0 R
]

this object is not used but it contains invalid references.
If I replace the a by a span, there are no issues.

OK, thanks. One other question (while I wait for my build...), does the resulting PDF actually get a link there, and does it work?

Yes everything works fine: the link is ok and I can open in either pdf.js or chrome.

Hmm, so far I haven't been able to reproduce this; qpdf --check doesn't report any issues for me.

Which platform are you testing Firefox on? What version does qpdf report for itself?

qpdf --version returns 10.1.0 and the platform is a debian bullseye.

Here's the generated pdf.

I just built qpdf from https://github.com/qpdf/qpdf and the output is the same:

 ./qpdf --version && ./qpdf --check ~/Téléchargements/mozilla.pdf
qpdf version 10.3.2
Run qpdf --copyright to see copyright and license information.
checking /home/calixte/Téléchargements/mozilla.pdf
PDF Version: 1.5
File is not encrypted
File is not linearized
WARNING: /home/calixte/Téléchargements/mozilla.pdf: file is damaged
WARNING: /home/calixte/Téléchargements/mozilla.pdf (object 3 0, offset 15): expected 3 0 obj
WARNING: /home/calixte/Téléchargements/mozilla.pdf: Attempting to reconstruct cross-reference table
WARNING: /home/calixte/Téléchargements/mozilla.pdf: object 3 0 not found in file after regenerating cross reference table

Thanks. After updating qpdf, I now get the same warnings from it; my Ubuntu had an older version that I guess doesn't have as many checks.

Set release status flags based on info from the regressing bug 454059

I guess this is an upstream cairo issue -- I'm hoping to dig in a bit and try to figure out what it's doing. Fortunately, the usability of the resulting PDF doesn't seem to be affected, but we should still try to fix it.

First thing, though, is that I think we should add a pref to control whether links are generated in the PDF at all (should've done this as part of the original landing). That way we can easily turn off the feature if it proves problematic in any way.

Marking as leave-open, as the above patch doesn't fix the actual issue; it just adds a pref to control whether the feature is active.

https://hg.mozilla.org/mozilla-central/rev/2989b762829c

Filed https://gitlab.freedesktop.org/cairo/cairo/-/issues/487 about the underlying cairo issue.

I've posted a possible fix at https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/185.

Do we want to turn the pref off in 90 (now beta), while we wait on the cairo update (presumably for 91)?

(In reply to Julien Cristau [:jcristau] from comment #20)

Do we want to turn the pref off in 90 (now beta), while we wait on the cairo update (presumably for 91)?

The cairo fix has been merged upstream, so I'd prefer to cherry-pick and uplift that to 90 (it's a trivial patch) if possible, rather than disable the feature. I'm on PTO today but plan to post a patch here tomorrow.

Sounds good, thanks!

See https://gitlab.freedesktop.org/cairo/cairo/-/issues/487 for details. This was merged upstream in
https://gitlab.freedesktop.org/cairo/cairo/-/commit/2edcb1ac2385c670c36d7ae53ae7de1637969ced;

https://hg.mozilla.org/mozilla-central/rev/350741703b20

Calixte, once the new Nightly with this fix is ready, if you could confirm the problem is resolved that would be great - thanks!

WFM, thank you.

Please nominate this for Beta approval when you get a chance.

Comment on attachment 9224907 [details]
Bug 1711064 - Cherry-pick fix from upstream cairo to resolve missing objects in generated PDF's xref table. r=jrmuizel

Beta/Release Uplift Approval Request

• User impact if declined: Some validators may report that PDFs generated by Print / Save as PDF have errors.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Trivial patch cherry-picked from upstream.
• String changes made/needed:

Comment on attachment 9224907 [details]
Bug 1711064 - Cherry-pick fix from upstream cairo to resolve missing objects in generated PDF's xref table. r=jrmuizel

Approved for 90.0b4.

https://hg.mozilla.org/releases/mozilla-beta/rev/836e24f3fe6a