To test I need to physically install a printer, right? the option "print to pdf file" is not enough I believe..
For printing I could explore the "fallback image" method you mentioned but if you can point me to some commit where something similar was implemented that would help to get the idea and borrow some code.
Xpdf, Google PDFium and even Acrobat Reader 2023 show the border, so I would say Firefox PDF.js it's the exception here.
Given the above (especially the Acrobat Reader case), I would say we can close this issue as NOTABUG.
Adrian's comment on the patch:
The problem is CairoOutputDev::beginTransparencyGroup does not handle non-isolated groups. Here is a patch that makes non-isolated groups work. The problem is this fix does not work for printing surfaces. I need to think about how to handling printing. Unfortunately cairo does not provide API to specify non-isolated groups so I may end up having to use fallback images to support printing.
More details on this other comment:
#992 (comment 1087726)
Nelson Benítez León (cd63aab8) at 24 Mar 21:06
[Draft] Adrian's patch to fix non-isolated transparency groups
... and 35 more commits
This issue is related to #992 because I just tested the patch @ajohnson posted there and the output improves a lot.
There seems to be some small alignment error which manifests in those white lines between painted objects. I wonder if that white lines and the one in #975 are produced by the same bug.
The original file is too heavy (31 MB) to work with, so I used qpdf
to extract page 102 (which contains one buggy image) to its own pdf file so it's more easy to debug it, also a 'plain' version obtained with qpdf --qdf --object-streams=disable
so it can be opened in a text editor.
@nbenitez have you checked that this doesn't break what 29f32a47 wants to do?
I didn't check because it should not affect, but I went now and checked the two reproducer files in !1186 (merged) and with this MR they both display as expected (green/green and green/red squares are shown).
Thanks for the heads up on this regression, I'm currently bisecting to find the blamed commit.
Yes I'm afraid it will affect other files. I'm in favor of doing the minimal change to fix this bug, especially when pdf.js have done the same fix.
I'm in favor of doing the clip rework (as specification seems to mandate) when we would find a buggy pdf file which requires such a clip fix (as that would confirm the clip rework is indeed needed).
Nelson Benítez León (f8542ea2) at 16 Mar 18:43
Fix text search across lines between paragraphs
This commit fixes the "across lines" text
search feature of TextPage::findText()
when
the match happens from the last line of a
paragraph to the first line of next paragraph.
Includes tests for this bug.
Fixes #1475
Fixes https://gitlab.gnome.org/GNOME/evince/-/issues/2001
Nelson Benítez León (7d8f2331) at 16 Mar 15:41
Fix text search across lines between paragraphs
... and 35 more commits
Searching for two words only works in single lines with some pdf files
I found that while searching for two (or more) words Evince will not show results where the first word is at the and of a line and the second is at the beginning at a new line.
This surely happens with files exported from LibreOffice, but these files can be correctly searched in Okular and Qoppa PDF Studio.
I attached an example pdf. Try searching in it for:
take steps
refused protection
The problem is the search code which Poppler's glib uses TextTextPage::findText()
currently does not support matching across two lines when the second line falls in the next paragraph. And pdf files exported from Libreoffice docs with line spacing > 1.5 are interpreted by Poppler as each line being a paragraph itself (due to line spacing).
Regardless of Poppler's paragraph detecting code could be improved, an obvious fix is to make TextTextPage::findText()
to also work from last line of a paragraph to first line of next paragraph, that's what the MR submitted does.
From what I understand GfxState already carries clip information that gets saved and restored (clipXMin, clipYMin, clipXMax, clipYMax), the clip
variable in Gfx.cc apparently is to flag the execution of the clip after the next paint operation.
The fix (which mimics pdf.js fix but adapted to Poppler's code) is minimal and just resets the clip
when executing a restore operator (Q
).
I'm hesitant to change the fix to a broader one (like saving and restoring the clip as the spec seems to mandate) especially since for such change we don't currently have a filed issue with a pdf reproducer file to test against.
That should be a different bug, as the chinese reproducer file displays fine for me in flatpak xournalpp (see screenshot).
So it seems the bug being Windows only.
@ossiviljakainen Thanks for making a file with personal data removed, unfortunately you removed the bug in the process, i.e. the file you posted is displayed fine by Poppler.
I've been working on this bug (using the reproducer file you posted to Evince issue, the one with personal data) for a couple weekends and could pinpoint the bug. So I source edited the PDF file you posted here (thanks to qpdf --qdf --object-streams=disable
) to reintroduce the bug. Here it is:
I had a fix for this but then I found out this is a duplicate of https://github.com/mozilla/pdf.js/pull/6414 which has a cleaner fix, so I'm sending !1509 with that fix instead.
The mozilla bug also has a minimal reproducer:
https://github.com/mozilla/pdf.js/blob/master/test/pdfs/issue6413.pdf
According to the specification, see NOTE 2 in
https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.pdf#G7.3882161
it appears that the clipping path should be reset when the restore (Q) operator is encountered.
Fixes #739