Low res / fuzzy print on Zebra label printer after cairo update in version 90 (when printing a particular PDF label)
Categories
(Core :: Printing: Setup, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox-esr91 | --- | verified |
firefox90 | --- | wontfix |
firefox91 | --- | verified |
firefox92 | --- | verified |
People
(Reporter: Orduluerkin, Assigned: jfkthame)
References
(Regressed 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(6 files)
1.97 MB,
image/jpeg
|
Details | |
84.83 KB,
application/pdf
|
Details | |
102.85 KB,
text/plain
|
Details | |
162.85 KB,
text/plain
|
Details | |
162.21 KB,
image/jpeg
|
Details | |
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-release+
RyanVM
:
approval-mozilla-esr91+
|
Details | Review |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
Steps to reproduce:
Updated to Firefox 90
Actual results:
Print resolution significantly decreased on Zebra ZD410 thermal label printer
Expected results:
IDK what causes but if I decrease 89.0.2 works fine.
Reporter | ||
Comment 1•3 years ago
|
||
The file I used
Comment 2•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Printing: Setup' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 3•3 years ago
|
||
Is there any chance you could use mozregression to figure out what broke this for you? I don't think we have the relevant hardware :/
Reporter | ||
Comment 4•3 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #3) > Is there any chance you could use [mozregression](https://mozilla.github.io/mozregression/) to figure out what broke this for you? I don't think we have the relevant hardware :/
Reporter | ||
Comment 5•3 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)
Is there any chance you could use mozregression to figure out what broke this for you? I don't think we have the relevant hardware :/
I shared logs but unfortunately non of them print good quality one like 89 or other browsers.
Comment 6•3 years ago
|
||
What did you try exactly? You need to put a good version (i.e., 88 for example) and a bad one (90) and it should find the changeset that broke it, but it seems from the logs that you were bisecting a fix?
Reporter | ||
Comment 7•3 years ago
|
||
I selected 90 release as last known bad build and 89 as good. and tried every run :( also checked search for fix.
Comment 8•3 years ago
|
||
Right, you're not searching for a fix, but a regression, so "search for fix" needs to be unchecked.
Reporter | ||
Comment 9•3 years ago
|
||
Reporter | ||
Comment 10•3 years ago
|
||
Reporter | ||
Comment 11•3 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)
Right, you're not searching for a fix, but a regression, so "search for fix" needs to be unchecked.
Okay, when I did without that option I get the result above. Could you take a look?
BTW 90.0.1 has the same issue for me.
Comment 12•3 years ago
|
||
Thanks! So this seems due to a Cairo update in bug 739096... Jonathan any ideas?
Updated•3 years ago
|
Reporter | ||
Comment 13•3 years ago
|
||
Thanks, we're looking forward to the fix
Comment 14•3 years ago
|
||
Set release status flags based on info from the regressing bug 739096
Assignee | ||
Comment 15•3 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #12)
Thanks! So this seems due to a Cairo update in bug 739096... Jonathan any ideas?
I suspect this means the cairo_win32_printing_surface backend is failing in some way and falling back to a raster-based codepath. I'll see if I can reproduce and figure out where this might be happening.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 17•3 years ago
|
||
Confirming based on the mozregression investigation and discussion in previous comments.
We don't have a barcode label printer to test it but it may be possible to test it with a regular printer.
Otherwise, the reporter might help us verify the fix when the case.
Comment 18•3 years ago
|
||
Reproduction should be possible with other types of thermal printers, such as a shipping label printer, if you have one of those. This bug impacting my Rollo shipping label printer is what led to the duplicate bug 1722842 being filed (whose mozregression came up with the same results as this bug). Other than the different paper sizes and drivers, it has the same characteristics (300 dpi monochrome thermal printer) and is similarly impacted to the Zebra in this bug report.
Reporter | ||
Comment 19•3 years ago
|
||
Of course, I can help to test. Just say the steps to try and I can share the results.
Comment 20•3 years ago
|
||
(In reply to Jonathan Kew (:jfkthame) from comment #15)
I'll see if I can reproduce and figure out where this might be happening.
Ticking needinfo to be sure this is on your queue. (And/or, if it doesn't repro on your printer, maybe jwatt can try his receipt printer...)
emilio notes that this would be useful to look at in rr, if we can determine that it reproduces on linux as well (TBD, once we have a local reproduction).
Assignee | ||
Comment 21•3 years ago
|
||
I can reproduce a similar deterioration in the output quality on my laser printer when printing that PDF -- it's not as bad as the reporter's photo shows for the thermal printer output, but definitely a visible regression.
Not on Linux, though. There, the reverse is true: I get substantially better output from FF90 than from 89.0.2. So the cairo update appears to have improved things for Linux, while degrading the output on Windows. (And so there's no rr for us here...sigh.) I'm pretty sure this'll be an issue specific to the cairo-win32 backend.
Updated•3 years ago
|
Comment 22•3 years ago
|
||
Some shot-in-the-dark googling turned up https://github.com/qzind/tray/issues/503 which is "PDF to Zebra printer is blurry and/or poor quality". (Not sure if there's any sort of shared cause between that and this; could just be a coincidence.)
Assignee | ||
Comment 23•3 years ago
|
||
I've identified a cairo bug that appears to be the cause of this; will file an upstream issue and patch tomorrow.
Assignee | ||
Comment 24•3 years ago
|
||
Updated•3 years ago
|
Assignee | ||
Comment 25•3 years ago
|
||
The poor output here is happening because during replay of the recording for the page, the _cairo_surface_is_recording
test here returns false for what is in fact a recording surface used as the pattern; and this results in painting the pattern as an image rather than a recording.
(There are several other places in cairo where _cairo_surface_is_recording
is used, so presumably all of them may be similarly affected and end up taking inferior fallback codepaths, but this one in the win32 print backend is the specific culprit here.)
Assignee | ||
Comment 26•3 years ago
|
||
Comment on attachment 9234396 [details]
Bug 1721127 - Apply win32 printing surface fix from https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/228. r?jrmuizel
Beta/Release Uplift Approval Request
- User impact if declined: Poor quality of printed output for some documents.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: On Windows, print the reporter's attached PDF; output should be sharp, not blurry/low-res.
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Simple fix for an internal cairo error (reported upstream for review/CI testing).
- String changes made/needed:
Assignee | ||
Updated•3 years ago
|
Comment 27•3 years ago
|
||
Comment on attachment 9234396 [details]
Bug 1721127 - Apply win32 printing surface fix from https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/228. r?jrmuizel
91 is on release now (RC week), moving the request over.
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 28•3 years ago
|
||
Assignee | ||
Comment 29•3 years ago
|
||
After discussion with cairo developers, the patch has been fixed/improved and is now merged upstream, so I'm pushing the final updated version here as well.
Comment 30•3 years ago
|
||
Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/927baf5c28de Apply win32 printing surface fix from https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/228. r=jrmuizel
Comment 31•3 years ago
|
||
Comment on attachment 9234396 [details]
Bug 1721127 - Apply win32 printing surface fix from https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/228. r?jrmuizel
Approved for 91.0/91.0esr RC2.
Comment 32•3 years ago
|
||
bugherder uplift |
Comment 33•3 years ago
|
||
bugherder uplift |
Comment 34•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Comment 35•3 years ago
|
||
I've reproduced this issue on Windows 10x64, using an affected Nightly version (2021-07-19).
Verified fixed with Firefox 91.0esr (20210804201221), Firefox 91.0 (20210804193234) and Firefox 92.0a1 (20210805163446) on Windows 10x64.
I could not reproduce this issue on macOS 10.15 or Ubuntu 20.04.
Assignee | ||
Comment 36•3 years ago
|
||
Thanks for testing. Yes, this was specifically a Windows-only issue.
Comment 38•3 years ago
|
||
Having filed the duplicate bug 1722842, I tested the release version of Firefox 91, and can confirm that it resolved the bug for me with my Rollo thermal printer, which I was experiencing on Firefox 90.
Description
•