Poor PDF engine for saving PDFs
Categories
(Core :: Printing: Output, defect)
Tracking
()
People
(Reporter: danutpopa831, Unassigned)
References
Details
Attachments
(8 files)
Screenshot 1.png
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:98.0) Gecko/20100101 Firefox/98.0
Steps to reproduce:
Open a test document,like https://en.wikibooks.org/wiki/BASIC_Programming, open the Print menu (click menu-print or press Ctrl+P), select the printer to "Save as PDF" and save as PDF
Actual results:
Poor PDF engine, fonts changed, "invisible shape" and don't add the browser name for saved PDFs (see the test PDF below)
Expected results:
Make the engine better by copying the fonts would like in HTML, don't add a "invisible shape" and should add the browser name for saved PDFs
|
Reporter | |
Comment 1•4 years ago
|
||
The bug also apply for Wikipedia sites
|
|
Reporter | |
Comment 2•4 years ago
|
||
Here is the screenshot "why made the engine poor"
|
|
Reporter | |
Updated•4 years ago
|
|
|
Reporter | |
Comment 3•4 years ago
|
||
The second screenshot why don't put the browser name in metadata
|
||
Comment 4•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Printing: Output' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 5•4 years ago
|
||
Poor PDF engine
No idea what that is supposed to mean. "Poor" can mean anything to anybody.
fonts changed
When a website uses webfonts, do you really expect Firefox to temporarily download all these fonts first? That makes no sense.
Websites are not images or photographs. Websites also consists text that might get rendered completely differently on different devices.
If you want a closer rendering of Wikimedia articles, feel free to use Wikimedia's "Download as PDF" functionality which is server-side rendering.
"invisible shape"
I have no idea what that means.
and don't add the browser name for saved PDFs (see the test PDF below)
You did not describe where exactly you expect some browser name to be added somewhere exactly.
For future reference, please only file one issue per ticket. This ticket mixes random unrelated things and cannot be handled. Thanks.
|
|
Reporter | |
Comment 7•4 years ago
|
||
The PDF version of the C++ book(Wikibooks)
|
|
Reporter | |
Comment 8•4 years ago
|
||
Here is the HTML version of the C++ book(Wikibooks)
|
|
Reporter | |
Comment 9•4 years ago
|
||
Compare the PDF version and the HTML version. The PDF version is more poor than the HTML version because fonts is changed
|
||
Comment 10•4 years ago
|
||
Regarding fonts: The PDF output uses different fonts because the page include CSS rules such as
@media print {
.toc,
body {
padding:10px;
font-family:'Linux Libertine','Georgia','Times',serif
}
that choose entirely different fonts for print output compared to screen display.
So I don't think there is a font-related bug here; rather, the example is working as designed (by the page author), using different print vs screen formatting.
It's unclear to me what "invisible shape" is referring to in the comments above. Is something invisible in the PDF output that should be there? Or something is present that should be invisible? Note that the site's CSS may be deliberately producing different layouts (in addition to the different fonts already mentioned); there's no general expectation that print layout will match screen layout.
|
|
Reporter | |
Comment 11•4 years ago
|
||
Replys to your question:
Is something invisible in the PDF output that should be there?
Yes
Regarding fonts: The PDF output uses different fonts because the page include CSS rules such as
Compare a PDF vs HTML,please
So I don't think there is a font-related bug here; rather, the example is working as designed (by the page author), using different print vs screen formatting.
Yes,i mean what filed a bug?
|
|
Reporter | |
Comment 12•4 years ago
|
||
For me
|
|
||
Comment 13•4 years ago
|
||
(In reply to Stefan Popa from comment #11)
Replys to your question:
Is something invisible in the PDF output that should be there?
Yes
Please describe exactly (maybe mark on a screenshot) what elements you're talking about, to make sure we're understanding the issue.
I can see that the PDF output of the wikibooks page does not include some things, such as the note boxes ("The wikibooks community has accepted...", "The latest reviewed version...", "At present there is an issue...") at the top of the page. But this is because the page is deliberately designed to only show these items on-screen, and omit them when printed.
So if these are the "invisible" things you're describing, that is how the page author has designed things. The page has a different design for print output compared to on-screen viewing.
|
|
Reporter | |
Comment 14•4 years ago
|
||
Please describe exactly (maybe mark on a screenshot) what elements you're talking about, to make sure we're understanding the issue.
The screenshot we talk about "invisible shape" on pages
of the wikibooks page does not include some things, such as the note boxes
Please type clearer
the page is deliberately designed to only show these items on-screen, and omit them when printed.
When printed,the printed output has difient fonts? Or maybe omit messages when printed
|
|
Reporter | |
Comment 15•4 years ago
|
||
The metadata, should put the browser name in metadata of saved PDFs
Only puts "cairo 1.17.4 https://cairographics.org"
Should put instead eg. Firefox 98.0.1
Syntax is Firefox xx.x.x where xx/x is the browser version
I have attached a screenshot to describe briefly.
|
||
Comment 16•4 years ago
•
|
||
(In reply to Stefan Popa from comment #14)
Created attachment 9268423 [details]
The screenshot we talk about "invisible shape"Please describe exactly (maybe mark on a screenshot) what elements you're talking about, to make sure we're understanding the issue.
The screenshot we talk about "invisible shape" on pages
It's still not-at-all clear what the "invisible shapes" are that you're referring to.
It sounds like you're saying there are pieces of the web page that are visible when viewed in the browser but are missing in the printed output -- is that correct? For example, the whole left sidebar.
If that's what you're talking about: then, as Jonathan noted: Firefox is excluding these elements from the printed output because that is what the page's markup instructs us to do. The page has specific markup which forces those elements to be hidden when printed -- specifically, the page here includes this rule in its CSS markup:
@media print {
.noprint,
.mw-cite-backlink,
[...omitting a bunch for brevity...]
li#mobileview,
li#privacy {
display:none
}
The @media print { ... display:none } here is an explicit instruction from the page developer to the browser to not-display those elements in the printed output, if the page is printed.
When printed,the printed output has difient fonts
Jonathan already addressed this in comment 10.
(In reply to Stefan Popa from comment #15)
The metadata, should put the browser name in metadata of saved PDFs
Only puts "cairo 1.17.4 https://cairographics.org"
Should put instead eg. Firefox 98.0.1
Syntax is Firefox xx.x.x where xx/x is the browser version
I have attached a screenshot to describe briefly.
You're seeing "cairo" there because that's the software that we use to produce the PDF (it's our built-in "virtual print-to-pdf" printer driver, essentially).
If you used an actual external print-to-PDF virtual printer (like the Microsoft print-to-PDF printer), then I suspect that would be what would go here as the "producer", even though the print job came from Firefox. So it makes some sense for the PDF to be crediting whatever PDF-printer-driver generated it (whether it's Microsoft or Cairo). But maybe that would be reasonable to change here, since our cairo pdf printer is built-in? I'm not sure what common conventions are for what that field is expected to contain.
|
|
||
Comment 17•4 years ago
|
||
The severity field is not set for this bug.
:alaskanemily, could you have a look please?
For more information, please visit auto_nag documentation.
|
|
||
Comment 18•4 years ago
|
||
Summing things up here -- per comment 16, it seem there were two issues here:
(1) content is missing in the printed output, though as far as we can tell it's just content that the website is explicitly instructing us to hide when printing. So, not-a-bug.
(2) Maybe our generated PDFs should include "Firefox" in the metadata somewhere.
Since we've mostly focused on trying to understand/explain part (1) here (and that seems to be things working-as-intended), I've spun off part 2 to its own bug -- bug 1762258. Let's close this one out, since (aside from the part that's now tracked in bug 1762258) there doesn't seem to be an actual Firefox bug here.
|
|
Reporter | |
Comment 19•4 years ago
|
||
Replys from Daniel Holbert & Stefan Popa:
(In reply to Daniel Holbert [:dholbert] from comment #16)
You're seeing "cairo" there because that's the software that we use to produce the PDF (it's our built-in "virtual print-to-pdf" printer driver, essentially).
What?? 😂😂😂 Is Cairo?? Or Mircosoft??
Jonathan already addressed this in comment 10.
Hello I replyed!
It sounds like you're saying there are pieces of the web page that are visible when viewed in the browser but are missing in the printed output -- is that correct? For example, the whole left sidebar.
Yes or no
If you used an actual external print-to-PDF virtual printer (like the Microsoft print-to-PDF printer), then I suspect that would be what would go here as the "producer", even though the print job came from Firefox. So it makes some sense for the PDF to be crediting whatever PDF-printer-driver generated it (whether it's Microsoft or Cairo). But maybe that would be reasonable to change here, since our cairo pdf printer is built-in? I'm not sure what common conventions are for what that field is expected to contain.
Compare Microsoft vs Cairo!
(In reply to Stefan Popa from comment #15)
The metadata, should put the browser name in metadata of saved PDFs
Only puts "cairo 1.17.4 https://cairographics.org"
Should put instead eg. Firefox 98.0.1
Syntax is Firefox xx.x.x where xx/x is the browser version
I have attached a screenshot to describe briefly.
I sayed in comment #15
The @media print { ... display:none } here is an explicit instruction from the page developer to the browser to not-display those elements in the printed output, if the page is printed.
When printed,the printed output has difient fonts
Yes, I mean CSS and to filter only the parts you want to print
(In reply to Stefan Popa from comment #14)
Created attachment 9268423 [details]
The screenshot we talk about "invisible shape"
Please describe exactly (maybe mark on a screenshot) what elements you're talking about, to make sure we're understanding the issue.
The screenshot we talk about "invisible shape" on pages
It's still not-at-all clear what the "invisible shapes" are that you're referring to.
Is a invisible rectangle on PDF 😂😂😂 Is breifly and good!
If that's what you're talking about: then, as Jonathan noted: Firefox is excluding these elements from the printed output because that is what the page's markup instructs us to do. The page has specific markup which forces those elements to be hidden when printed -- specifically, the page here includes this rule in its CSS markup:
Yes, I mean CSS and to filter only the parts you want to print
(In reply to Daniel Holbert [:dholbert] from comment #18)
Summing things up here -- per comment 16, it seem there were two issues here:
Read the issues please!
(1) content is missing in the printed output, though as far as we can tell it's just content that the website is explicitly instructing us to hide when printing. So, not-a-bug.
Is a invisible rectangle on PDF 😂😂😂 Is breifly and good!
(2) Maybe our generated PDFs should include "Firefox" in the metadata somewhere.
On "Creator" or "Aplication" field should put Firefox 98.0.2
Since we've mostly focused on trying to understand/explain part (1) here (and that seems to be things working-as-intended), I've spun off part 2 to its own bug -- bug 1762258. Let's close this one out, since (aside from the part that's now tracked in bug 1762258) there doesn't seem to be an actual Firefox bug here.
Is focused on printed output,thanks for Daniel Holbert
End of replys!!!!
|
|
Reporter | |
Comment 20•4 years ago
|
||
The bug also apply for Wikipedia sites
Wikimedia: Wikipedia, Wikibooks, Wikiquote, Wiktonary and many more
|
|
||
Comment 21•4 years ago
|
||
(In reply to Stefan Popa from comment #19 and comment #20)
What?? 😂😂😂 Is Cairo??
https://en.wikipedia.org/wiki/Cairo_(graphics)
Wikimedia: Wikipedia, Wikibooks, Wikiquote, Wiktonary and many more
Please read comment 5.
|
|
||
Comment 22•3 years ago
|
||
😂😂😂
Also for Google Forms, missing checkboxes and more inputs. That makes a poor PDF engine in a buggy, annoying browser!
Attached PDF from Google Forms is below
|
|
||
Comment 23•3 years ago
|
||
In preview
|
|
||
Comment 24•3 years ago
|
||
So, we talk about poor PDF engine
Invisible rectangle on PDF, that is funny!!
😂😂😂
Also for Google Forms, missing checkboxes and more inputs. That makes a poor PDF engine in a buggy, annoying browser!
So, about Google Forms, missing checkboxes! In preview, but not on printed PDF!
Firefox is a super buggy browser!!!!
|
|
||
Comment 25•3 years ago
|
||
(In reply to MihaiPopa2 (joltariyde@vusra.com) from comment #24)
Invisible rectangle on PDF, that is funny!!
We've explained this repeatedly. It's not a bug for Firefox to render the website's provided content faithfully.
It seems like you're not understanding this, but I'm not sure what more we can offer.
Also for Google Forms, missing checkboxes and more inputs. That makes a poor PDF engine in a buggy, annoying browser!
So, about Google Forms, missing checkboxes! In preview, but not on printed PDF!
It's hard to reason about this without a live testcase to try viewing directly; but, if the checkboxes are missing in Preview only, my guess would be that the they just have extremely thin borders (maybe 1px wide or something), and those end up rendering with a thickness that rounds down to 0px when we zoom out for print-preview, if your print-preview visualization is sufficiently small.
I can reproduce something like this with e.g. data:text/html,<div style="border: 1px solid black">Hi if I make my Firefox window small enough (i.e. if the print-preview rendering is using a small enough scale factor).
Description
•