Blacklining an image in PDF won't remove underlying content in version 1.22.X #2404
Labels
Comments
bbustamante
changed the title
|
This is a bug and already under investigation. |
|
Please also refer to discussion #2399. |
JorjMcKie
added a commit
that referenced
this issue
Jun 16, 2023
Detail descriptions: Fixing #2468: MuPDF now correctly provides the OC layer name. In PyMuPDF, a safeguard against invalid lay name strings has been implemented. Fixing: #2365: Combined "fill" and "stroke" paths ("fs") now correctly report dictionary keys from the sub-paths. Fixing #2391: Checkbox "True" values were inconsistent between getting and setting. This value is now always set to "Yes". Fixing #2400: Fixed by an internal MuPDF fix. Fixing #2404: Fixed by an internal MuPDF fix. Fixing #2430: We falsely reduced the reference count of `Py_None` object when creating the dictionary `Font.infos`. This has been corrected. Other changes: * Support for "cloudy" annotation borders * Consistent setting / unsetting of RadioButtons within same RB group. However: the RB group must be a PDF object: radio buttons with JavaScripts that simulate that behaviour are not supported. * Adobe Photoshop images are now supported as input (Pixmaps and Documents). * The /Locked key in OCProperties is now support for getting / setting. * Document method `set_layer_ui_config()` now also supports the OCG name as argument (was just the sequence number previously).
julian-smith-artifex-com
pushed a commit
to ArtifexSoftware/PyMuPDF-julian
that referenced
this issue
Jun 19, 2023
Detail descriptions: Fixing pymupdf#2468: MuPDF now correctly provides the OC layer name. In PyMuPDF, a safeguard against invalid lay name strings has been implemented. Fixing: pymupdf#2365: Combined "fill" and "stroke" paths ("fs") now correctly report dictionary keys from the sub-paths. Fixing pymupdf#2391: Checkbox "True" values were inconsistent between getting and setting. This value is now always set to "Yes". Fixing pymupdf#2400: Fixed by an internal MuPDF fix. Fixing pymupdf#2404: Fixed by an internal MuPDF fix. Fixing pymupdf#2430: We falsely reduced the reference count of `Py_None` object when creating the dictionary `Font.infos`. This has been corrected. Other changes: * Support for "cloudy" annotation borders * Consistent setting / unsetting of RadioButtons within same RB group. However: the RB group must be a PDF object: radio buttons with JavaScripts that simulate that behaviour are not supported. * Adobe Photoshop images are now supported as input (Pixmaps and Documents). * The /Locked key in OCProperties is now support for getting / setting. * Document method `set_layer_ui_config()` now also supports the OCG name as argument (was just the sequence number previously).
julian-smith-artifex-com
pushed a commit
that referenced
this issue
Jun 20, 2023
Detail descriptions: Fixing #2468: MuPDF now correctly provides the OC layer name. In PyMuPDF, a safeguard against invalid lay name strings has been implemented. Fixing: #2365: Combined "fill" and "stroke" paths ("fs") now correctly report dictionary keys from the sub-paths. Fixing #2391: Checkbox "True" values were inconsistent between getting and setting. This value is now always set to "Yes". Fixing #2400: Fixed by an internal MuPDF fix. Fixing #2404: Fixed by an internal MuPDF fix. Fixing #2430: We falsely reduced the reference count of `Py_None` object when creating the dictionary `Font.infos`. This has been corrected. Other changes: * Support for "cloudy" annotation borders * Consistent setting / unsetting of RadioButtons within same RB group. However: the RB group must be a PDF object: radio buttons with JavaScripts that simulate that behaviour are not supported. * Adobe Photoshop images are now supported as input (Pixmaps and Documents). * The /Locked key in OCProperties is now support for getting / setting. * Document method `set_layer_ui_config()` now also supports the OCG name as argument (was just the sequence number previously).
|
Fixed in 1.22.5. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Discussed in #2399
Originally posted by bbustamante May 10, 2023
Hello,
I have just updated my PyMuPDF version from 1.21.1 to 1.22.2. When I blackline a text from an image even wen I edit the result PDF to get de blankline from the file manualy, the text behind it was desaparead (that's, for me, the correct working system). But right now, when I do it the text is still there. This just happend when the text is an image inside de PDF (second line of the example), not wen is a real text (first line of the example).
I include three (plus one) images with the process and the PDF I use:
Te original PDF with two lines. First one is real text while the second one is an image.
The result PDF after blackileing it with PyMuPDF.
The result PDF manually edited to remove the blacklines.
The PDF file I use for the example.
PyMuPDF example.pdf
The result of the example made with PyMuPDF 1.21.1 after editing manually for removing blacklines.
Any idea of what is happening? How could I resolve it?
Thanks.
I have try all the PyMuPDF 1.22.X versions and in all of them happen the same. I have see that between PyMuPDF 1.21.1 and PyMuPDF 1.22.0 the MuPDF version has changed, don't know if this could be affecting to this issue.
Here is an example code of what I'm doing:
test.zip
The text was updated successfully, but these errors were encountered: