poppler issueshttps://gitlab.freedesktop.org/poppler/poppler/-/issues2018-10-27T14:21:29Zhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/467Multiple text blocks are grouped as one2018-10-27T14:21:29ZBugzilla Migration UserMultiple text blocks are grouped as one## Submitted by Jelmer
Assigned to **poppler-bugs**
**[Link to original bug (#94931)](https://bugs.freedesktop.org/show_bug.cgi?id=94931)**
## Description
Created attachment 122930
Example page
We are using poppler for clipping o...## Submitted by Jelmer
Assigned to **poppler-bugs**
**[Link to original bug (#94931)](https://bugs.freedesktop.org/show_bug.cgi?id=94931)**
## Description
Created attachment 122930
Example page
We are using poppler for clipping of magazines and use it a lot.
We found a bug where multiple text blocks are grouped as one. It happens when there is a text block in the middle of two text blocks. Attached you find an example page.
In this example, the middle three blocks, where the first starts with:
`Jeroen Wij wonen op` and ends at the right hand bottom of the right block with `tranen in de ogen`.
The text blocks should be grouped a three:
the left column, the small block in the center and the right column.
**Attachment 122930**, "Example page":
[varagids-16-2016-zonder-spoorboek_7.pdf](/uploads/5a079a4c5e358733e3f1020633481dec/varagids-16-2016-zonder-spoorboek_7.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/468poor type 1c font rendering2018-08-21T11:00:51ZBugzilla Migration Userpoor type 1c font rendering## Submitted by Germán Poo-Caamaño
Assigned to **poppler-bugs**
**[Link to original bug (#100869)](https://bugs.freedesktop.org/show_bug.cgi?id=100869)**
## Description
Created attachment 131121
PDF Test case
This was reported in...## Submitted by Germán Poo-Caamaño
Assigned to **poppler-bugs**
**[Link to original bug (#100869)](https://bugs.freedesktop.org/show_bug.cgi?id=100869)**
## Description
Created attachment 131121
PDF Test case
This was reported in https://bugzilla.gnome.org/show_bug.cgi?id=776924
The following pdf document is being rendered rather ugly in evince:
http://www.scottaaronson.com/papers/pnp.pdf
All fonts are embedded. They're all type 1c fonts.
$ pdffonts pnp.pdf
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
VXEZKP+CMSS17 Type 1C Builtin yes yes no 4 0
YDPTNV+CMR12 Type 1C Builtin yes yes no 5 0
JLCEZQ+CMR17 Type 1C Builtin yes yes no 6 0
NUVJJI+CMSY8 Type 1C Builtin yes yes yes 7 0
VBIHCP+CMBX10 Type 1C Builtin yes yes no 8 0
CXZLTS+CMR10 Type 1C Builtin yes yes yes 9 0
JGIYMZ+CMSS10 Type 1C Builtin yes yes yes 10 0
AGGZPP+CMR7 Type 1C Builtin yes yes no 11 0
RGQKMS+CMSY10 Type 1C Builtin yes yes yes 12 0
BYIFKE+CMBX12 Type 1C Builtin yes yes no 13 0
FNGYIT+CMR8 Type 1C Builtin yes yes yes 15 0
JFBFYB+CMSY6 Type 1C Builtin yes yes yes 32 0
OBXTKK+CMR9 Type 1C Builtin yes yes yes 33 0
GVHKBA+CMTI10 Type 1C Builtin yes yes no 87 0
RVPORJ+CMMI10 Type 1C Builtin yes yes yes 89 0
JKFOWN+CMSS12 Type 1C Builtin yes yes no 93 0
KIISBX+CMR6 Type 1C Builtin yes yes yes 99 0
WWJJES+CMMI9 Type 1C Builtin yes yes yes 100 0
DRXVBH+CMSS9 Type 1C Builtin yes yes no 101 0
IWKPFB+CMMI8 Type 1C Builtin yes yes yes 106 0
IYGFKD+CMMI6 Type 1C Builtin yes yes yes 110 0
SGXEVV+CMTI9 Type 1C Builtin yes yes no 129 0
DNNGNS+CMEX9 Type 1C Builtin yes yes yes 131 0
FPKZIJ+CMSY9 Type 1C Builtin yes yes yes 132 0
DOOAXC+CMSS8 Type 1C Builtin yes yes no 170 0
OLTLXQ+CMCSC10 Type 1C Builtin yes yes no 179 0
JXRWPD+CMEX10 Type 1C Builtin yes yes yes 188 0
KSYIAZ+CMEX7 Type 1C Builtin yes yes no 224 0
UROALT+CMMI5 Type 1C Builtin yes yes no 228 0
SKNWGA+MSBM10 Type 1C Builtin yes yes yes 239 0
PFOPPM+CMSY5 Type 1C Builtin yes yes no 310 0
EFHBMR+CMR5 Type 1C Builtin yes yes no 311 0
PLAHEP+CMEX8 Type 1C Builtin yes yes no 690 0
UEHLMU+MSBM7 Type 1C Builtin yes yes no 852 0
I wonder how the embedded pdf viewer of firefox can do a better job with this document than evince. Most other pdf documents look better in evince.
By ugly the reporter means:
So here are a couple of screenshots. As you can see evince has the lowest font rendering quality, because it's blurry and the stroke width is not concise (especially when it comes to the equal sign in the headline).
The font rendering of the internal pdf viewer of firefox also suffers from being blurry, but at least the stroke width is more concise.
I also added some screenshots taken under macOS. They are not blurry, but the resolution is also much higher. So it's more like a reference.
Comparing evince's font rendering in the pdf with the font rendering in the outline window on the left, you can see that it is very well possible to get a better result with the lower linux resolution.
And it's not like I was searching for a zoom factor where evince has problems. Sure, the quality might improve with other zoom factors, but it also declines with others as well. In the end the zoom factor cannot "fix" the font rendering quality; the font rendering is still clearly better in firefox when "optimizing" the zoom factor in both applications.
**Attachment 131121**, "PDF Test case":
[pnp.pdf](/uploads/c8af86b678707dcbf9604bb838e8bbdd/pnp.pdf)
### See also
* [Bug 776924](https://bugzilla.gnome.org/show_bug.cgi?id=776924)https://gitlab.freedesktop.org/poppler/poppler/-/issues/469Problem converting LAB color space to RGB2018-08-21T11:01:20ZBugzilla Migration UserProblem converting LAB color space to RGB## Submitted by Volmar Oliveira Jr
Assigned to **poppler-bugs**
**[Link to original bug (#92921)](https://bugs.freedesktop.org/show_bug.cgi?id=92921)**
## Description
Created attachment 119603
input and output files
Converting a ...## Submitted by Volmar Oliveira Jr
Assigned to **poppler-bugs**
**[Link to original bug (#92921)](https://bugs.freedesktop.org/show_bug.cgi?id=92921)**
## Description
Created attachment 119603
input and output files
Converting a PDF with embedded images using LAB color space, this is converted to RGB presenting problems as possible to see in the examples.
~~**Attachment 119603**~~, "input and output files":
[files.zip](/uploads/dd316dcdc767a91bcbf4dde71817ce98/files.zip)https://gitlab.freedesktop.org/poppler/poppler/-/issues/470Garbage text in one line in a specific PDF file2018-10-05T23:14:22ZBugzilla Migration UserGarbage text in one line in a specific PDF file## Submitted by Germán Poo-Caamaño
Assigned to **poppler-bugs**
**[Link to original bug (#106817)](https://bugs.freedesktop.org/show_bug.cgi?id=106817)**
## Description
Created attachment 140023
PDF test case
Original report: htt...## Submitted by Germán Poo-Caamaño
Assigned to **poppler-bugs**
**[Link to original bug (#106817)](https://bugs.freedesktop.org/show_bug.cgi?id=106817)**
## Description
Created attachment 140023
PDF test case
Original report: https://gitlab.gnome.org/GNOME/evince/issues/859
"I am using evince 3.26.0.
The following PDF is broken after "Euroopa Majanduspiirkonna" and before ", võrdub hüvitise suurus" when viewed in qpdfview."
The issue is reproducible with pdftoppm 0.64.0.
**Attachment 140023**, "PDF test case":
[borken_pdf.PDF](/uploads/9e906bb11e344a6d058579b4d5135aca/borken_pdf.PDF)https://gitlab.freedesktop.org/poppler/poppler/-/issues/471Image does not show on PDF due to ICC Profile reading error.2020-11-14T01:51:18ZBugzilla Migration UserImage does not show on PDF due to ICC Profile reading error.## Submitted by Jose Aliste
Assigned to **poppler-bugs**
**[Link to original bug (#49590)](https://bugs.freedesktop.org/show_bug.cgi?id=49590)**
## Description
Created attachment 61149
PDF showing the bug
The attached pdf has an ...## Submitted by Jose Aliste
Assigned to **poppler-bugs**
**[Link to original bug (#49590)](https://bugs.freedesktop.org/show_bug.cgi?id=49590)**
## Description
Created attachment 61149
PDF showing the bug
The attached pdf has an image that is not render by poppler. When rendering with the poppler-glib-demo I get:
Syntax Warning: not an ICC profile, invalid signature
Syntax Warning: read ICCBased color space profile error
Forwarded from https://bugzilla.gnome.org/show_bug.cgi?id=675577
**Attachment 61149**, "PDF showing the bug":
[GRM080173_15.pdf](/uploads/1616795b9b3918f41249ad00279a834e/GRM080173_15.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/472Enumerate PDF named destinations2018-10-15T12:16:13ZBugzilla Migration UserEnumerate PDF named destinations## Submitted by Masamichi Hosoda
Assigned to **poppler-bugs**
**[Link to original bug (#97262)](https://bugs.freedesktop.org/show_bug.cgi?id=97262)**
## Description
I'd like to enumerate PDF named destinations in a PDF.
I've trie...## Submitted by Masamichi Hosoda
Assigned to **poppler-bugs**
**[Link to original bug (#97262)](https://bugs.freedesktop.org/show_bug.cgi?id=97262)**
## Description
I'd like to enumerate PDF named destinations in a PDF.
I've tried `poppler_index_iter_get_action ()'.
It can obtain named destinations which are used in the PDF actions.
But, it cannot obtain named destinations which are not used.
I'd like all named destinations.
So I cannot use `poppler_index_iter_get_action ()'.https://gitlab.freedesktop.org/poppler/poppler/-/issues/474'Text at cursor' and 'replace' annotation marks are drawn in yellow instead o...2022-01-09T19:37:27ZBugzilla Migration User'Text at cursor' and 'replace' annotation marks are drawn in yellow instead of blue.## Submitted by Paul Gruzdev
Assigned to **poppler-bugs**
**[Link to original bug (#86921)](https://bugs.freedesktop.org/show_bug.cgi?id=86921)**
## Description
Created attachment 110342
Acrobat X Pro annotations.pdf
Render the a...## Submitted by Paul Gruzdev
Assigned to **poppler-bugs**
**[Link to original bug (#86921)](https://bugs.freedesktop.org/show_bug.cgi?id=86921)**
## Description
Created attachment 110342
Acrobat X Pro annotations.pdf
Render the attached using Splash. Note the yellow instead of blue for 'Text at cursor' mark and 'Replace' mark.
**Attachment 110342**, "Acrobat X Pro annotations.pdf":
[Acrobat_X_Pro_annotations.pdf](/uploads/aaf4908fa62e1c22e42795ee1650d003/Acrobat_X_Pro_annotations.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/477rasterisation issue when using TikZ's doube line2018-08-21T11:02:36ZBugzilla Migration Userrasterisation issue when using TikZ's doube line## Submitted by yas..@..hjz.de
Assigned to **poppler-bugs**
**[Link to original bug (#77904)](https://bugs.freedesktop.org/show_bug.cgi?id=77904)**
## Description
Created attachment 97915
Problematic PDF
Okular (the KDE document ...## Submitted by yas..@..hjz.de
Assigned to **poppler-bugs**
**[Link to original bug (#77904)](https://bugs.freedesktop.org/show_bug.cgi?id=77904)**
## Description
Created attachment 97915
Problematic PDF
Okular (the KDE document viewer) does not correctly rasterise the attached PDF at certain (resolution-dependant) zoom levels. The problem is probably an anti-aliasing issue when two rectangles with slightly different width are drawn on top of each other to produce an equal sign. It seems to be a poppler issue as Evince shows a similar bug, though not as drastic as Okular. I checked a few other viewers, in particular Adobe Acrobat, and none of them showed the issue.
The LaTeX code to produce the PDF can be found here [1]. My Okular bug report can be found here [2]. There you may also find a few screenshots which illustrate the problem. I can confirm the bug on my KUbuntu 14.04 netbook with poppler version 0.24.5. However, the bug isn't new, it is at least 2 years old.
[1] http://tex.stackexchange.com/questions/168071/tikz-double-line-rasterisation-issue
[2] https://bugs.kde.org/show_bug.cgi?id=332900
Steps to Reproduce:
Load the PDF and try different zoom levels. (The 'bad' zoom levels seem to dependent on the screen resolution.) On my netbook (1024x600), the issue appears below 200%.
**Attachment 97915**, "Problematic PDF":
[rast.pdf](/uploads/66537b9901655af6437de44a7676eb1b/rast.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/478pdftocairo -svg renders image mask wrongly2018-08-21T11:02:42ZBugzilla Migration Userpdftocairo -svg renders image mask wrongly## Submitted by Duan Yao
Assigned to **poppler-bugs**
**[Link to original bug (#79910)](https://bugs.freedesktop.org/show_bug.cgi?id=79910)**
## Description
Created attachment 100868
pdftocairo -svg renders the pdf wrongly
pdftoc...## Submitted by Duan Yao
Assigned to **poppler-bugs**
**[Link to original bug (#79910)](https://bugs.freedesktop.org/show_bug.cgi?id=79910)**
## Description
Created attachment 100868
pdftocairo -svg renders the pdf wrongly
pdftocairo -svg renders image mask in the attached pdf wrongly. The light blue area should show some halo effect, but in the output svg, there is no transition of color.
pdftocairo -png renders the pdf correctly.
I build poppler from latest master 1b705331019b155f2138d4b9f5a5bd03ec59193d on ubuntu 14.04. configuration:
Building poppler with support for:
font configuration: fontconfig
splash output: yes
cairo output: yes
qt4 wrapper: no
qt5 wrapper: no
glib wrapper: yes
introspection: no
cpp wrapper: yes
use gtk-doc: no
use libjpeg: yes
use libpng: yes
use libtiff: yes
use zlib: no
use libcurl: no
use libopenjpeg: yes
use cms: yes
with lcms2
command line utils: yes
**Attachment 100868**, "pdftocairo -svg renders the pdf wrongly":
[dili-7a-p64.pdf](/uploads/886c457b4ef3f984451fbcc124dc778e/dili-7a-p64.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/480Spaces are stripped in all PDF's generated with PhantomJS (Node.js)2018-08-21T11:02:50ZBugzilla Migration UserSpaces are stripped in all PDF's generated with PhantomJS (Node.js)## Submitted by cla..@..eat.dk
Assigned to **poppler-bugs**
**[Link to original bug (#103770)](https://bugs.freedesktop.org/show_bug.cgi?id=103770)**
## Description
Created attachment 135502
test pdf
Spaces in all PDF's generated...## Submitted by cla..@..eat.dk
Assigned to **poppler-bugs**
**[Link to original bug (#103770)](https://bugs.freedesktop.org/show_bug.cgi?id=103770)**
## Description
Created attachment 135502
test pdf
Spaces in all PDF's generated with Node.js (PhantomJS) are stripped
pdftohtml -s -i $file $htm_output
poppler-0.61.0
The output for one text box is
`<p>`FrederikThomsen<br/>Att.:FrederikSpangThomsen`</p>`
But should be
`<p>`Frederik Thomsen<br/>Att.: Frederik Spang Thomsen`</p>`
**Attachment 135502**, "test pdf":
[poppler_test.pdf](/uploads/34cdea29f2faed9a0cc4f273f6eab74c/poppler_test.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/481-cropbox for pdftotext2018-10-05T23:12:40ZBugzilla Migration User-cropbox for pdftotext## Submitted by Michael
Assigned to **poppler-bugs**
**[Link to original bug (#33880)](https://bugs.freedesktop.org/show_bug.cgi?id=33880)**
## Description
pdftoppm has a -cropbox command line parameter to restrict output to the C...## Submitted by Michael
Assigned to **poppler-bugs**
**[Link to original bug (#33880)](https://bugs.freedesktop.org/show_bug.cgi?id=33880)**
## Description
pdftoppm has a -cropbox command line parameter to restrict output to the CropBox.
It would be nice to have the same -cropbox parameter for pdftotext, in order to only extract text that is part of the printed/displayed CropBox.https://gitlab.freedesktop.org/poppler/poppler/-/issues/482[PATCH] Feature : extract media in html format2018-08-21T11:02:56ZBugzilla Migration User[PATCH] Feature : extract media in html format## Submitted by Allemand Corentin
Assigned to **poppler-bugs**
**[Link to original bug (#56843)](https://bugs.freedesktop.org/show_bug.cgi?id=56843)**
## Description
Created attachment 69663
Patch for extract media
I added an arg...## Submitted by Allemand Corentin
Assigned to **poppler-bugs**
**[Link to original bug (#56843)](https://bugs.freedesktop.org/show_bug.cgi?id=56843)**
## Description
Created attachment 69663
Patch for extract media
I added an argument on pdftohtml to extract the images separately.
This argument also extracts videos and sounds from RichMedia
~~**Patch 69663**~~, "Patch for extract media":
[Archive.zip](/uploads/35a6a46aab4a4422adec03efb21ba50c/Archive.zip)https://gitlab.freedesktop.org/poppler/poppler/-/issues/483Some forms are not saved2018-10-08T22:07:43ZBugzilla Migration UserSome forms are not saved## Submitted by Marek Kasik `@mkasik`
Assigned to **poppler-bugs**
**[Link to original bug (#93882)](https://bugs.freedesktop.org/show_bug.cgi?id=93882)**
## Description
Created attachment 121323
Mark holes in xref table as free e...## Submitted by Marek Kasik `@mkasik`
Assigned to **poppler-bugs**
**[Link to original bug (#93882)](https://bugs.freedesktop.org/show_bug.cgi?id=93882)**
## Description
Created attachment 121323
Mark holes in xref table as free entries
I've got downstream report with a PDF form which doesn't save entered data. I've looked at this in more detail and it seems that the problem is caused by reconstruction of xref table before saving of the form which causes "reset" of the form.
The reconstruction is performed because there is a call for XRef::getEntry() on entry which does not exist (with i = 7 btw). This entry doesn't exist because there is a hole in the xref table. I was not sure whether the table is correct then but from https://bugs.freedesktop.org/show_bug.cgi?id=48679 it seems that it is (and note 17 on section 3.4.3 in specification of PDF 1.7 says that we should treat such holes as free entries).
Attached is a patch which works for me but I'm not sure whether it doesn't add another bug elsewhere. It marks newly added entries which where not listed in previous sections of xref table as free. It doesn't do this if previous size of the xref table was 0 because this indicates that the PDF is probably linearized and it would mark some entries as free even if those will be populated later.
It doesn't "chain" the free entries but it seems that it work even without that (otherwise we would need to reuse the code from beginning of XRef::writeXRef() which does this).
The original report and the reproducer can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=1301016
**Attachment 121323**, "Mark holes in xref table as free entries":
[0001-Mark-holes-in-xref-table-as-free.patch](/uploads/26495f0d9c43b2636c12f102a50c4dc0/0001-Mark-holes-in-xref-table-as-free.patch)https://gitlab.freedesktop.org/poppler/poppler/-/issues/484[PATCH] Add -noannotate option in pdftocairo to disable annotations2018-10-08T10:30:30ZBugzilla Migration User[PATCH] Add -noannotate option in pdftocairo to disable annotations## Submitted by Stephen E.
Assigned to **poppler-bugs**
**[Link to original bug (#94304)](https://bugs.freedesktop.org/show_bug.cgi?id=94304)**
## Description
Created attachment 121977
Patch to add -noannotate option to pdftocairo...## Submitted by Stephen E.
Assigned to **poppler-bugs**
**[Link to original bug (#94304)](https://bugs.freedesktop.org/show_bug.cgi?id=94304)**
## Description
Created attachment 121977
Patch to add -noannotate option to pdftocairo
I was looking for a way to prevent pdftocairo from drawing PDF form fields when rendering to a bitmap, and came up short. The attached patch adds a -noannotate flag which does this. (Thanks to jcrain from IRC for pointing me toward the appropriate internals!)
**Attachment 121977**, "Patch to add -noannotate option to pdftocairo":
[noannotate.patch](/uploads/c9e16990a1fd5b1f62f35e921f2a07ff/noannotate.patch)https://gitlab.freedesktop.org/poppler/poppler/-/issues/485pdftotext -htmlmeta should quote text content2018-10-08T10:48:02ZBugzilla Migration Userpdftotext -htmlmeta should quote text content## Submitted by Jean-Francois Dockes
Assigned to **poppler-bugs**
**[Link to original bug (#83061)](https://bugs.freedesktop.org/show_bug.cgi?id=83061)**
## Description
Special HTML characters (`<>`&"') inside the main text or PDF...## Submitted by Jean-Francois Dockes
Assigned to **poppler-bugs**
**[Link to original bug (#83061)](https://bugs.freedesktop.org/show_bug.cgi?id=83061)**
## Description
Special HTML characters (`<>`&"') inside the main text or PDF metadata (e.g.: title) are not escaped in the HTML output, possibly resulting in invalid HTML.
This is trivial to reproduce, but, if you need a sample doc, just ask...https://gitlab.freedesktop.org/poppler/poppler/-/issues/486Expose GlobalParams in CPP api2018-10-26T11:08:36ZBugzilla Migration UserExpose GlobalParams in CPP api## Submitted by Jeroen Ooms
Assigned to **poppler-bugs**
**[Link to original bug (#103570)](https://bugs.freedesktop.org/show_bug.cgi?id=103570)**
## Description
Currently it is not possible in the cpp api to set the poppler-data ...## Submitted by Jeroen Ooms
Assigned to **poppler-bugs**
**[Link to original bug (#103570)](https://bugs.freedesktop.org/show_bug.cgi?id=103570)**
## Description
Currently it is not possible in the cpp api to set the poppler-data path at runtime. This would be very useful.https://gitlab.freedesktop.org/poppler/poppler/-/issues/487poppler-glib/cairo does not antialias text in some PDFs, while okular does2018-08-21T11:03:23ZBugzilla Migration Userpoppler-glib/cairo does not antialias text in some PDFs, while okular does## Submitted by Fabian Henze
Assigned to **poppler-bugs**
**[Link to original bug (#50995)](https://bugs.freedesktop.org/show_bug.cgi?id=50995)**
## Description
Hi,
I have found a PDF file, which looks horrible when rendered with ...## Submitted by Fabian Henze
Assigned to **poppler-bugs**
**[Link to original bug (#50995)](https://bugs.freedesktop.org/show_bug.cgi?id=50995)**
## Description
Hi,
I have found a PDF file, which looks horrible when rendered with poppler-glib or pdftocairo. It does render (mostly) fine in okular, so I guess it's either specific to poppler-glib or the cairo backend.
You can reproduce that bug with:
pdftocairo -png -r 90 -f 15 -l 20 exphy.pdf
or with Evince.
I am using archlinux with poppler 0.20.0 and cairo 1.12.2, but it also happens on a gentoo system with 0.18.4 and 1.10.2.
Best regards,
Fabian Henze
P.S.: I also experiences crashes when rendering this PDF file to a cairo PDFSurface, but only if I would use poppler_page_render() instead of render_for_printing().https://gitlab.freedesktop.org/poppler/poppler/-/issues/488pdf fails to load with poppler_document_new_from_stream()2018-08-21T11:03:31ZBugzilla Migration Userpdf fails to load with poppler_document_new_from_stream()## Submitted by Phillip Berndt
Assigned to **poppler-bugs**
**[Link to original bug (#96884)](https://bugs.freedesktop.org/show_bug.cgi?id=96884)**
## Description
The file
https://punpun.xyz/Xl6N.pdf
displays fine with Poppler 0...## Submitted by Phillip Berndt
Assigned to **poppler-bugs**
**[Link to original bug (#96884)](https://bugs.freedesktop.org/show_bug.cgi?id=96884)**
## Description
The file
https://punpun.xyz/Xl6N.pdf
displays fine with Poppler 0.24.5 (from Mint stable / Ubuntu oldstable), but fails to load in the latest version.
This issue was originally reported here: https://github.com/phillipberndt/pqiv/issues/67https://gitlab.freedesktop.org/poppler/poppler/-/issues/489Certain PDFs (converted from eps) mangled by poppler+cairo2018-08-21T11:03:36ZBugzilla Migration UserCertain PDFs (converted from eps) mangled by poppler+cairo## Submitted by Dan Scholnik
Assigned to **poppler-bugs**
**[Link to original bug (#86995)](https://bugs.freedesktop.org/show_bug.cgi?id=86995)**
## Description
Created attachment 110441
Example pdf file that pdftocairo mangles.
...## Submitted by Dan Scholnik
Assigned to **poppler-bugs**
**[Link to original bug (#86995)](https://bugs.freedesktop.org/show_bug.cgi?id=86995)**
## Description
Created attachment 110441
Example pdf file that pdftocairo mangles.
I'm using epstopdf to convert eps files generated by Matlab into pdf files for
inclusion in latex documents. Some of the resulting pdf files display
corrupted in evince or when converted using pdftocairo. The same pdf looks fine in gv and xpdf or when converted using pdftoppm and pdftopng. I have poppler
0.24.3 installed (fedora 20). I'm attaching a tiny example.
**Attachment 110441**, "Example pdf file that pdftocairo mangles.":
[test.pdf](/uploads/22d0d85a995b9eb55d436f62e91c1809/test.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/490Can't visualize large PDF2018-10-27T13:50:05ZBugzilla Migration UserCan't visualize large PDF## Submitted by Tomas
Assigned to **poppler-bugs**
**[Link to original bug (#104088)](https://bugs.freedesktop.org/show_bug.cgi?id=104088)**
## Description
Created attachment 135940
messy call graph of open-ssh
Hi,
In Evince, it...## Submitted by Tomas
Assigned to **poppler-bugs**
**[Link to original bug (#104088)](https://bugs.freedesktop.org/show_bug.cgi?id=104088)**
## Description
Created attachment 135940
messy call graph of open-ssh
Hi,
In Evince, it's not possible to visualize the attached PDF.
I initially reported the bug at Gnome: https://bugzilla.gnome.org/show_bug.cgi?id=791163
However, as suggested by Germán the issue is more probably triggered by Poppler.
Regards
**Attachment 135940**, "messy call graph of open-ssh":
[CG.pdf](/uploads/32ee4dc259215fd2e64a84303f3db76b/CG.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/492Import multiple images instead of one large background image2018-08-21T11:03:53ZBugzilla Migration UserImport multiple images instead of one large background image## Submitted by Nick Ruffilo
Assigned to **poppler-bugs**
**[Link to original bug (#57573)](https://bugs.freedesktop.org/show_bug.cgi?id=57573)**
## Description
Whether the PDF has multiple images (as multiple items) or just one i...## Submitted by Nick Ruffilo
Assigned to **poppler-bugs**
**[Link to original bug (#57573)](https://bugs.freedesktop.org/show_bug.cgi?id=57573)**
## Description
Whether the PDF has multiple images (as multiple items) or just one image, it makes all images one image and sets as background. Is there a way to break this up? If not, I guess this falls under feature requests.https://gitlab.freedesktop.org/poppler/poppler/-/issues/493PDF subset check utility2018-10-08T10:47:53ZBugzilla Migration UserPDF subset check utility## Submitted by Adam Reviczky
Assigned to **poppler-bugs**
**[Link to original bug (#10776)](https://bugs.freedesktop.org/show_bug.cgi?id=10776)**
## Description
It would be nice if we had a small program that checks the PDF for s...## Submitted by Adam Reviczky
Assigned to **poppler-bugs**
**[Link to original bug (#10776)](https://bugs.freedesktop.org/show_bug.cgi?id=10776)**
## Description
It would be nice if we had a small program that checks the PDF for subset standards like PDF/X and PDF/A. Something like a PDF validator if you like.
This info can (should) be also included in pdfinfo.
A free tool for this exist for Windows and Mac:
http://www.pdfxreport.com/download.htmlhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/494API to disable rendering of annotation thumbnails2018-10-05T22:38:58ZBugzilla Migration UserAPI to disable rendering of annotation thumbnails## Submitted by Debarshi Ray `@debarshir`
Assigned to **poppler-bugs**
**[Link to original bug (#90234)](https://bugs.freedesktop.org/show_bug.cgi?id=90234)**
## Description
Use case: https://bugzilla.gnome.org/show_bug.cgi?id=689...## Submitted by Debarshi Ray `@debarshir`
Assigned to **poppler-bugs**
**[Link to original bug (#90234)](https://bugs.freedesktop.org/show_bug.cgi?id=90234)**
## Description
Use case: https://bugzilla.gnome.org/show_bug.cgi?id=689900
The annotation thumbnails obstruct the underlying content, so it can be hard to read a document that has a lot of them. A way to hide or show them will be useful.https://gitlab.freedesktop.org/poppler/poppler/-/issues/495"Standard" character encoding of base 14 font not correctly handled2018-10-27T14:04:26ZBugzilla Migration User"Standard" character encoding of base 14 font not correctly handled## Submitted by David Hedley
Assigned to **poppler-bugs**
**[Link to original bug (#102588)](https://bugs.freedesktop.org/show_bug.cgi?id=102588)**
## Description
Created attachment 134044
Example PDF using standard encoding
The ...## Submitted by David Hedley
Assigned to **poppler-bugs**
**[Link to original bug (#102588)](https://bugs.freedesktop.org/show_bug.cgi?id=102588)**
## Description
Created attachment 134044
Example PDF using standard encoding
The attached PDF contains an embedded base 14 font (Helvetica-Bold) and uses the "Standard" font encoding. The "ring" symbol (Standard encoding octal 312) is being rendered as E circumflex (WinAnsi encoding octal 312).
Poppler should be using StandardEncoding for this font, not WinAnsiEncoding.
**Attachment 134044**, "Example PDF using standard encoding":
[Pages_from_ABR-WU-AKFZ.pdf](/uploads/d0d19560d1141113ba829761822e4edb/Pages_from_ABR-WU-AKFZ.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/496ZapfDingbats substitution by wingding.ttf may not work2018-08-21T11:04:06ZBugzilla Migration UserZapfDingbats substitution by wingding.ttf may not work## Submitted by suzuki toshiya
Assigned to **poppler-bugs**
**[Link to original bug (#48040)](https://bugs.freedesktop.org/show_bug.cgi?id=48040)**
## Description
Created attachment 59208
PDF referring base 14 fonts without embedd...## Submitted by suzuki toshiya
Assigned to **poppler-bugs**
**[Link to original bug (#48040)](https://bugs.freedesktop.org/show_bug.cgi?id=48040)**
## Description
Created attachment 59208
PDF referring base 14 fonts without embedding
Although it is commented as "not sure" in GlobalParamsWin.cc
// TODO: not sure if "wingding.ttf" is right
{"ZapfDingbats", "d050000l.pfb", "wingding.ttf"},
the substitution of ZapfDingbats by Wingding may not work.
Here I upload a small testing PDF that refers base14 fonts
with standard & alternative names. The line for ZapfDingbats
are totally lost. I will try to improve.
**Attachment 59208**, "PDF referring base 14 fonts without embedding":
[base14fonts-noembed.pdf](/uploads/f1d776b3ec8d0c3f4474ba89140a6814/base14fonts-noembed.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/497PDF links -> SVG2018-08-21T11:04:15ZBugzilla Migration UserPDF links -> SVG## Submitted by rdt..@..il.com
Assigned to **poppler-bugs**
**[Link to original bug (#75953)](https://bugs.freedesktop.org/show_bug.cgi?id=75953)**
## Description
I'm using pdf2svg from http://www.cityinthesky.co.uk/opensource/pdf...## Submitted by rdt..@..il.com
Assigned to **poppler-bugs**
**[Link to original bug (#75953)](https://bugs.freedesktop.org/show_bug.cgi?id=75953)**
## Description
I'm using pdf2svg from http://www.cityinthesky.co.uk/opensource/pdf2svg/
toconvert PDF pages to SVG images. The key steps are as follows:
// Open the SVG file
surface = cairo_svg_surface_create(svgFilename, width, height);
drawcontext = cairo_create(surface);
// Render the PDF file into the SVG file
poppler_page_render(page, drawcontext);
cairo_show_page(drawcontext);
For my purposes, this works well, with one exception: clickable
links in the PDF page are not converted into links in the SVG image.
SVG supports simple xlinks and cairo has a function
cairo_surface_set_mime_data with CAIRO_MIME_TYPE_URI as a supported
mime type. I believe links on a PDF page are available using
poppler_page_get_link_mapping.
Seems like this would be a useful enhancement to
poppler_page_render for an svg_surface.https://gitlab.freedesktop.org/poppler/poppler/-/issues/498NULL pointer dereference in GfxState.cc:61272018-08-21T11:04:18ZBugzilla Migration UserNULL pointer dereference in GfxState.cc:6127## Submitted by foca@salesforce.com
Assigned to **poppler-bugs**
**[Link to original bug (#101504)](https://bugs.freedesktop.org/show_bug.cgi?id=101504)**
## Description
Created attachment 132068
Proof of concept
There is a NULL ...## Submitted by foca@salesforce.com
Assigned to **poppler-bugs**
**[Link to original bug (#101504)](https://bugs.freedesktop.org/show_bug.cgi?id=101504)**
## Description
Created attachment 132068
Proof of concept
There is a NULL dereference in GfxState.cc:6127.
The function drawSoftMaskedImage calls getLine() at CairoOutputDev.cc:2710 which returns NULL, and stores that in pix. The value is than passed on to the getGrayLine function which tries to dereference it, resulting in a null dereference.
2708 for (y = 0; y < maskHeight; y++) {
2709 maskDest = (unsigned char *) (maskBuffer + y * row_stride);
2710 pix = maskImgStr->getLine();
2711 maskColorMap->getGrayLine (pix, maskDest, maskWidth);
2712 }
The reason NULL is returned by getLine due to the following
`ImageStream::getLine`
529 if (unlikely(inputLine == NULL)) {
530 return NULL;
531 }
At the point inp is set to whatever pix was( pix=in), in our case pix was NULL. On line 6127 the dereference takes place and poppler crashes trying to dereference a NULL pointer.
6123 default:
6124 inp = in;
6125 for (j = 0; j < length; j++)
6126 for (i = 0; i < nComps; i++) {
6127 *inp = byte_lookup[*inp * nComps + i];
6128 inp++;
6129 }
A solution could be an additional check at CairoOutputDev.cc:2710 to check the line isn't NULL:
2710 pix = maskImgStr->getLine();
2711 if (pix == NULL) continue;
2712 maskColorMap->getGrayLine (pix, maskDest, maskWidth);
PoC is attached.
This vulnerability has been found by Offensive Research at Salesforce.com:
Alberto Garcia (@algillera), Francisco Oca (@francisco_oca) & Suleman Ali (@Salbei_)
**Attachment 132068**, "Proof of concept":
[PoC.pdf](/uploads/20cc7c8d5fa69ca411fac2617955bc0b/PoC.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/499evince and selection on rotated text2021-12-09T06:25:31ZBugzilla Migration Userevince and selection on rotated text## Submitted by Pedro Villavicencio
Assigned to **poppler-bugs**
**[Link to original bug (#16619)](https://bugs.freedesktop.org/show_bug.cgi?id=16619)**
## Description
this report has been filed here:
https://bugs.edge.launchpad....## Submitted by Pedro Villavicencio
Assigned to **poppler-bugs**
**[Link to original bug (#16619)](https://bugs.freedesktop.org/show_bug.cgi?id=16619)**
## Description
this report has been filed here:
https://bugs.edge.launchpad.net/ubuntu/+source/poppler/+bug/245620
"When selecting rotated text in evince, it doesn't work correctly (see attached screenshot)."
http://launchpadlibrarian.net/15829551/Capture-1.png
http://launchpadlibrarian.net/15829586/m1.pdf
Thanks,https://gitlab.freedesktop.org/poppler/poppler/-/issues/500poppler slows down search within some pages of this document2018-08-21T11:04:26ZBugzilla Migration Userpoppler slows down search within some pages of this document## Submitted by Pablo Rodríguez `@ousia`
Assigned to **poppler-bugs**
**[Link to original bug (#28508)](https://bugs.freedesktop.org/show_bug.cgi?id=28508)**
## Description
Making a whole search on http://www.pragma-ade.nl/general...## Submitted by Pablo Rodríguez `@ousia`
Assigned to **poppler-bugs**
**[Link to original bug (#28508)](https://bugs.freedesktop.org/show_bug.cgi?id=28508)**
## Description
Making a whole search on http://www.pragma-ade.nl/general/manuals/mk.pdf, such as searching for "Wiedervereinigung" with evince, I have realized that in some pages (that I guess contain more vector graphics or whatever it might be) searching is much slower.
I cannot code, but I guess that poppler might be busy due to other actions than searching. Those actions make sense after finding, not while searching.
I'm not sure whether this would be glib-specific, but this is only the frontend I can check right now.
Thanks for your help,
Pablohttps://gitlab.freedesktop.org/poppler/poppler/-/issues/501Horizontal lines appear on blue background on pdf2018-08-21T11:04:29ZBugzilla Migration UserHorizontal lines appear on blue background on pdf## Submitted by Pedro Villavicencio
Assigned to **poppler-bugs**
**[Link to original bug (#19760)](https://bugs.freedesktop.org/show_bug.cgi?id=19760)**
## Description
this report has been filed here:
https://bugs.edge.launchpad....## Submitted by Pedro Villavicencio
Assigned to **poppler-bugs**
**[Link to original bug (#19760)](https://bugs.freedesktop.org/show_bug.cgi?id=19760)**
## Description
this report has been filed here:
https://bugs.edge.launchpad.net/poppler/+bug/318130
"We have a pdf file exported from Open Office Impress. The background is blue and there are horizontal lines through the image. The lines vary somewhat in colour, going from white to the blue.
If the slide show is made in OO Impress, all is well (showing that this isn't a hardware problem). Likewise if the same exported pdf file is shown on Windows XP, all is well."
PDF:
http://launchpadlibrarian.net/21362015/seminar1.pdfhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/502Poppler is not localizable2018-08-21T11:04:34ZBugzilla Migration UserPoppler is not localizable## Submitted by Gabor Kelemen
Assigned to **poppler-bugs**
**[Link to original bug (#18648)](https://bugs.freedesktop.org/show_bug.cgi?id=18648)**
## Description
Created attachment 20488
Screenshot with untranslated string
Evince...## Submitted by Gabor Kelemen
Assigned to **poppler-bugs**
**[Link to original bug (#18648)](https://bugs.freedesktop.org/show_bug.cgi?id=18648)**
## Description
Created attachment 20488
Screenshot with untranslated string
Evince shows untranslated error messages, coming from poppler, so I think it's time to add localization support to poppler. Or to ask every software author using poppler to not to show any "low-level" error messages :).
**Attachment 20488**, "Screenshot with untranslated string":
![Document_Viewer](/uploads/2258c8da524d4d22fe89c8545af34888/Document_Viewer.png)https://gitlab.freedesktop.org/poppler/poppler/-/issues/503"Unsupported TilingType:3" Avoiding out-of-memory errors2018-08-21T11:04:37ZBugzilla Migration User"Unsupported TilingType:3" Avoiding out-of-memory errors## Submitted by zakiyama01
Assigned to **poppler-bugs**
**[Link to original bug (#102401)](https://bugs.freedesktop.org/show_bug.cgi?id=102401)**
## Description
Creating images from PDF
Certain pattern filling (TilingType = 3) wa...## Submitted by zakiyama01
Assigned to **poppler-bugs**
**[Link to original bug (#102401)](https://bugs.freedesktop.org/show_bug.cgi?id=102401)**
## Description
Creating images from PDF
Certain pattern filling (TilingType = 3) was not rendered properly.
#/usr/bin/pdftocairo -r 174 -scale-to 3000 -cropbox -jpeg pdftocairo.outofmemory.pdf image
SAMPLE PDF
[pdftocairo.outofmemory.pdf](https://github.com/zakiyama01/poppler/files/1251045/pdftocairo.outofmemory.pdf)
And if you set it to a larger image size, you will get out of memory error, rendering will finish with the painting. (Sample PDF is only paint of problem so we can not confirm the stopped image)
#/usr/bin/pdftocairo -r 174 -scale-to 5000 -cropbox -jpeg pdftocairo.outofmemory.pdf image
Internal Error: cairo context error: out of memory`<0a>`
cairo error: out of memory
cairo error: out of memory
I tried poppler-0.57.0. The same symptoms from before.
Because I am in trouble as it is, solve out of memory? Avoidance? I am fixing it.
see patch.
https://github.com/zakiyama01/poppler/commit/b35eba51683fd634142b4607496ac1ea37c2311e
thank youhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/505Evince garbles text selection2018-08-21T11:04:44ZBugzilla Migration UserEvince garbles text selection## Submitted by Jason Crain
Assigned to **poppler-bugs**
**[Link to original bug (#94902)](https://bugs.freedesktop.org/show_bug.cgi?id=94902)**
## Description
Created attachment 122875
evince-selection-bug.pdf
Forwarding from ht...## Submitted by Jason Crain
Assigned to **poppler-bugs**
**[Link to original bug (#94902)](https://bugs.freedesktop.org/show_bug.cgi?id=94902)**
## Description
Created attachment 122875
evince-selection-bug.pdf
Forwarding from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817239
----------
Sascha Brawer wrote:
Package: evince
Version: 3.14.1-2
Severity: normal
When selecting the text of the attched PDF in evince 3.14.1,
some characters appear garbled. The _unselected_ rendering is fine,
the garbling only happens upon text selection.
----------
I can confirm this on current cairo and evince master. In the attached PDF, selecting certain characters makes them disappear or turn into squares.
**Attachment 122875**, "evince-selection-bug.pdf":
[evince-selection-bug.pdf](/uploads/35d8bd9597b3da0092504bc20e928a1e/evince-selection-bug.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/506Pdftoppm Fontconfig Error Causes Compressed Text2018-10-11T20:19:14ZBugzilla Migration UserPdftoppm Fontconfig Error Causes Compressed Text## Submitted by Cory
Assigned to **poppler-bugs**
**[Link to original bug (#78626)](https://bugs.freedesktop.org/show_bug.cgi?id=78626)**
## Description
Created attachment 98938
rendered text
On Ubuntu and OS X, using Poppler 0.2...## Submitted by Cory
Assigned to **poppler-bugs**
**[Link to original bug (#78626)](https://bugs.freedesktop.org/show_bug.cgi?id=78626)**
## Description
Created attachment 98938
rendered text
On Ubuntu and OS X, using Poppler 0.26.0
The pdf text displays properly with Acrobat, but the following error happens when I use pdftoppm and then the text is really hard to read.
Fontconfig error: "/usr/local/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70: non-double matrix element
Fontconfig error: "/usr/local/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70: non-double matrix element
Fontconfig warning: "/usr/local/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 78: saw unknown, expected number
My command is:
pdftoppm some_text_compresses.pdf -r 150 /tmp/rastered
Attached is a screenshot of the result.
The text renders properly with ghostscript.
The PDF is sensitive, so I will need to e-mail it to a developer directly.
Thank you so much for all of your help!
**Attachment 98938**, "rendered text":
![rendered_text](/uploads/24df6b15a8da9f151c642106e4190ec2/rendered_text.png)https://gitlab.freedesktop.org/poppler/poppler/-/issues/507Poppler extremely slow to render this PDF file [1]2018-10-05T22:38:18ZBugzilla Migration UserPoppler extremely slow to render this PDF file [1]## Submitted by S.
Assigned to **poppler-bugs**
**[Link to original bug (#91249)](https://bugs.freedesktop.org/show_bug.cgi?id=91249)**
## Description
Hello,
Certain PDFs opened in Evince or Atril using the Poppler backend are ex...## Submitted by S.
Assigned to **poppler-bugs**
**[Link to original bug (#91249)](https://bugs.freedesktop.org/show_bug.cgi?id=91249)**
## Description
Hello,
Certain PDFs opened in Evince or Atril using the Poppler backend are extremely slow to render, to the point of being unusable. This is on a very fast Thinkpad laptop with a quad-core processor and an SSD. The same PDFs render instantly using a Windows PDF reader (http://www.tracker-software.com/product/pdf-xchange-viewer) (running under Wine!!).
This file is only about 2MB, but it takes many seconds to render each page:
https://ia600705.us.archive.org/26/items/kindergartencatho11albe/kindergartencatho11albe.pdf
On the other hand, some long, complex PDFs with images render quickly with Poppler, like this one:
http://www.pwc.com/gx/en/paying-taxes/pdf/pwc-paying-taxes-2015-high-resolution.pdf
Thanks for looking into this.https://gitlab.freedesktop.org/poppler/poppler/-/issues/508Differing number of items returned from get_text{,layout}2018-08-21T11:05:01ZBugzilla Migration UserDiffering number of items returned from get_text{,layout}## Submitted by Peter Waller
Assigned to **poppler-bugs**
**[Link to original bug (#73885)](https://bugs.freedesktop.org/show_bug.cgi?id=73885)**
## Description
Created attachment 92530
Single page PDF document describing the issu...## Submitted by Peter Waller
Assigned to **poppler-bugs**
**[Link to original bug (#73885)](https://bugs.freedesktop.org/show_bug.cgi?id=73885)**
## Description
Created attachment 92530
Single page PDF document describing the issue
As reported here, I've found a PDF which returns a differing number of rectangles from poppler_get_page_layout as from poppler_get_text. I've reproduced this with the glib demo app on the master branch at c8a845cf7c7752d3b7dad06013d3154812c66c92.
http://lists.freedesktop.org/archives/poppler/2014-January/010793.html
I've attached a page which reproduces the issue.
**Attachment 92530**, "Single page PDF document describing the issue":
[2014-01-17-broken.pdf](/uploads/6be3c7dbe5cf6cf93596d10c33bca27e/2014-01-17-broken.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/510pdfimages 0.62 extract image at low resolution than embedded in PDF2018-10-11T20:17:54ZBugzilla Migration Userpdfimages 0.62 extract image at low resolution than embedded in PDF## Submitted by Valerio Messina
Assigned to **poppler-bugs**
**[Link to original bug (#104684)](https://bugs.freedesktop.org/show_bug.cgi?id=104684)**
## Description
Created attachment 136828
sample PDF with 4 pages
using pdfimag...## Submitted by Valerio Messina
Assigned to **poppler-bugs**
**[Link to original bug (#104684)](https://bugs.freedesktop.org/show_bug.cgi?id=104684)**
## Description
Created attachment 136828
sample PDF with 4 pages
using pdfimages and extracting the images from the attached 4 pages PDF, generate tens of small useless files and 4 real images, but also those images really at very low resolution, so text is unreadable.
$ pdfimages -all FPGA_CQFP352adapter_Aldec_orig.pdf FPGA_CQFP352adapter_Aldec
platform:
Linux64 and Win64
**Attachment 136828**, "sample PDF with 4 pages":
[FPGA_CQFP352adapter_Aldec_orig.pdf](/uploads/e864ea34e5141e468188394fe7866310/FPGA_CQFP352adapter_Aldec_orig.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/511Huge simple PDF displayed blank in poppler-glib-demo2018-08-21T11:05:17ZBugzilla Migration UserHuge simple PDF displayed blank in poppler-glib-demo## Submitted by Maxim Iorsh
Assigned to **poppler-bugs**
**[Link to original bug (#56858)](https://bugs.freedesktop.org/show_bug.cgi?id=56858)**
## Description
A very large PDF produced by a Xerox wide scanner is displayed blank.
...## Submitted by Maxim Iorsh
Assigned to **poppler-bugs**
**[Link to original bug (#56858)](https://bugs.freedesktop.org/show_bug.cgi?id=56858)**
## Description
A very large PDF produced by a Xerox wide scanner is displayed blank.
File location: https://docs.google.com/file/d/14hFFrjSSbiEcfML1sgOttcT865GC7tHqv27wiuEfQ-KlvuRfU67Dkj9E9JaM/edit
Basically it contains nothing but a 21590 x 161385 b/w bitmap
Note that Acrobat Reader fails to display it too. Okular displays properly, but slowly. PDF-XChange Viewer for Windows displays properly and very fast.https://gitlab.freedesktop.org/poppler/poppler/-/issues/512Bounding boxes of text selection marks are much too large in some cases.2018-08-21T11:05:30ZBugzilla Migration UserBounding boxes of text selection marks are much too large in some cases.## Submitted by tho..@..ner.at
Assigned to **poppler-bugs**
**[Link to original bug (#40556)](https://bugs.freedesktop.org/show_bug.cgi?id=40556)**
## Description
Created attachment 50817
This is the sample pdf illustrating the bu...## Submitted by tho..@..ner.at
Assigned to **poppler-bugs**
**[Link to original bug (#40556)](https://bugs.freedesktop.org/show_bug.cgi?id=40556)**
## Description
Created attachment 50817
This is the sample pdf illustrating the bug
When I select text on the first page of the sample document, everything is ok and looks as expected. But text on the second page has way too large bounding boxes associated for the selection marks when selecting it (tested in evince and okular). In acroread, selection looks as expected.
I created the document with LaTeX by including the second page via \includepdf.
**Attachment 50817**, "This is the sample pdf illustrating the bug":
[test.pdf](/uploads/20442195bcb7a58ed15e8ff6d2cbf02c/test.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/514Vector graphics in pdf file are displayed with wrong linewidth2018-08-21T11:05:37ZBugzilla Migration UserVector graphics in pdf file are displayed with wrong linewidth## Submitted by Germán Poo-Caamaño
Assigned to **poppler-bugs**
**[Link to original bug (#97995)](https://bugs.freedesktop.org/show_bug.cgi?id=97995)**
## Description
As reported in https://bugzilla.gnome.org/show_bug.cgi?id=74525...## Submitted by Germán Poo-Caamaño
Assigned to **poppler-bugs**
**[Link to original bug (#97995)](https://bugs.freedesktop.org/show_bug.cgi?id=97995)**
## Description
As reported in https://bugzilla.gnome.org/show_bug.cgi?id=745258
"You can open these two files with Evince
https://sites.google.com/site/espinozahg/notes/linux/linewidth-0.1.pdf
https://sites.google.com/site/espinozahg/notes/linux/linewidth-0.3.pdf
Evince displays both images very similarly and with a quite thick linewidth.
Okular displays them much better and you can notice the difference in linewidth.
Printing to paper works correctly in Evince."https://gitlab.freedesktop.org/poppler/poppler/-/issues/515Disable bilinear filtering of images at native resolution -- Patch supplied2018-08-21T11:05:46ZBugzilla Migration UserDisable bilinear filtering of images at native resolution -- Patch supplied## Submitted by Charles Hyder
Assigned to **poppler-bugs**
**[Link to original bug (#68360)](https://bugs.freedesktop.org/show_bug.cgi?id=68360)**
## Description
Here's a PDF file that contains scanned (raster) b/w image @ 400dpi,...## Submitted by Charles Hyder
Assigned to **poppler-bugs**
**[Link to original bug (#68360)](https://bugs.freedesktop.org/show_bug.cgi?id=68360)**
## Description
Here's a PDF file that contains scanned (raster) b/w image @ 400dpi, together with the result of its rendering with pdftoppm from two poppler releases: 0.20.5 & 0.24.0:
http://ge.tt/56fxgSp/v/0?c
The latter (newer version) produces a fuzzy image. In fact, I've also tried version 0.22.x and it also gives fuzzy results. The effect is not specific to the PDF file: it is reproduced on any PDF file that contains raster b/w images.
Meanwhile, pdfimages (ImageOutputDev) works just fine. So I figure it must be the SplashOutputDevhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/517Poppler does not draw caret annotations if they don't have an /AP dictionary2018-08-21T11:07:07ZBugzilla Migration UserPoppler does not draw caret annotations if they don't have an /AP dictionary## Submitted by Germán Poo-Caamaño
Assigned to **poppler-bugs**
**[Link to original bug (#74028)](https://bugs.freedesktop.org/show_bug.cgi?id=74028)**
## Description
Created attachment 92736
PDF test case with caret annotations
...## Submitted by Germán Poo-Caamaño
Assigned to **poppler-bugs**
**[Link to original bug (#74028)](https://bugs.freedesktop.org/show_bug.cgi?id=74028)**
## Description
Created attachment 92736
PDF test case with caret annotations
This is part of a report in https://bugzilla.gnome.org/show_bug.cgi?id=626982
In the attached page, there are plenty of caret annotations, which are
rendered in Acroread with the symbol up tack ⊥ (u+22a5) or short up tack
(u+2ae0). However, in poppler there is nothing rendered.
**Attachment 92736**, "PDF test case with caret annotations":
[page-36.pdf](/uploads/cb75de8a25ee952d2281bc49d8e4dbc3/page-36.pdf)
### See also
* [Bug 626982](https://bugzilla.gnome.org/show_bug.cgi?id=626982)https://gitlab.freedesktop.org/poppler/poppler/-/issues/518Quality of convertion pdf to html2018-08-21T11:07:12ZBugzilla Migration UserQuality of convertion pdf to html## Submitted by isaric
Assigned to **poppler-bugs**
**[Link to original bug (#43297)](https://bugs.freedesktop.org/show_bug.cgi?id=43297)**
## Description
I am French, sorry for my translation.
I use poppler-utils 0.16.7-2ubuntu2 ...## Submitted by isaric
Assigned to **poppler-bugs**
**[Link to original bug (#43297)](https://bugs.freedesktop.org/show_bug.cgi?id=43297)**
## Description
I am French, sorry for my translation.
I use poppler-utils 0.16.7-2ubuntu2 (oneiric)
I use "pdftohtml -c *.pdf"
for exemple isaric.cof.free.fr/PDFtoHTML/5-1d-a-afk-1-15-18-55-62.pdf
give http://isaric.cof.free.fr/PDFtoHTML/5-1d-a-afk_ind.html with shifts on the level of spaces
The columns don't use the same ones spaces.
in advance thankshttps://gitlab.freedesktop.org/poppler/poppler/-/issues/520pdftohtml: RTL text generated backwards2018-08-21T11:07:20ZBugzilla Migration Userpdftohtml: RTL text generated backwards## Submitted by Nezmer
Assigned to **poppler-bugs**
**[Link to original bug (#28076)](https://bugs.freedesktop.org/show_bug.cgi?id=28076)**
## Description
"pdftohtml" seems to generate RTL text backwards. It's like (abc) is genera...## Submitted by Nezmer
Assigned to **poppler-bugs**
**[Link to original bug (#28076)](https://bugs.freedesktop.org/show_bug.cgi?id=28076)**
## Description
"pdftohtml" seems to generate RTL text backwards. It's like (abc) is generated (cba). You can read the generated text from LTR but that's not convenient ;)
"pdftotext" is behaving correctly.https://gitlab.freedesktop.org/poppler/poppler/-/issues/521Need option to "preserve blacks"2018-10-07T00:27:05ZBugzilla Migration UserNeed option to "preserve blacks"## Submitted by Jorge Hernández Valiñani
Assigned to **poppler-bugs**
**[Link to original bug (#57244)](https://bugs.freedesktop.org/show_bug.cgi?id=57244)**
## Description
Created attachment 70211
PDF with text in solid black
CM...## Submitted by Jorge Hernández Valiñani
Assigned to **poppler-bugs**
**[Link to original bug (#57244)](https://bugs.freedesktop.org/show_bug.cgi?id=57244)**
## Description
Created attachment 70211
PDF with text in solid black
CMYK solid black (i.e. C=0, M=0, Y=0, K=100%), or some other kinds of solid blacks (separation, index/DeviceN with K-only CMYK black, etc) convert to dark-gray-ish RGB instead of pure RGB black.
While not a bug, as that original black in the original color space (determined by the source —default or declared— ICC profile, I guess) may indeed not map to pure black, such conversions are usually inappropriate even if arguably accurate, since many (most?) times one would want to display those blacks as pure RGB black, no matter how that original black actually looked on paper.
Pretty much all documents with text will produce this unintended dark-gray color when viewed on screen, since most of times that text will be solid black.
Many software capable of converting PDFs from one color space to another usually have an option to "preserve blacks" (i.e. add an exception to how color management should deal with solid blacks and grayscale objects). Acrobat X has it in its dialog for Tools > Print production > Color conversion (although I cannot even get Acrobat to do what I expect by this option with the embedded file); GhostScript's source code has seemingly portions for that at http://svn.ghostscript.com/ghostscript/trunk/gs/lcms2/src/cmscnvrt.c (which I cannot tell how relevant it actually is: I stumbled into it when googling "PDF preserve black" and cannot read C). There are countless articles on the web on why "preserving blacks" is an important feature when converting color spaces.
Here I attach a PDF created with Adobe Illustrator CS5.5 with solid black CMYK text, which produces this dark-gray RGB when converted with `pdftocairo` and `pdftoppm`.
**Attachment 70211**, "PDF with text in solid black":
[preserve_black.pdf](/uploads/c8400fc9bd23e3832ca780831d1c1186/preserve_black.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/523Unicode strings saved as literal strings2018-10-07T00:25:40ZBugzilla Migration UserUnicode strings saved as literal strings## Submitted by Marek Kasik `@mkasik`
Assigned to **poppler-bugs**
**[Link to original bug (#91058)](https://bugs.freedesktop.org/show_bug.cgi?id=91058)**
## Description
Created attachment 116655
Testing form
When saving the atta...## Submitted by Marek Kasik `@mkasik`
Assigned to **poppler-bugs**
**[Link to original bug (#91058)](https://bugs.freedesktop.org/show_bug.cgi?id=91058)**
## Description
Created attachment 116655
Testing form
When saving the attached PDF form, the string entered into the text field is saved as a literal string and not as a hexadecimal string which causes problems when viewing it in acroread.
I believe that such strings should be saved as hexadecimal strings.
I used "šč" string for testing.
**Attachment 116655**, "Testing form":
[form.pdf](/uploads/3c0343f645746b8698037cff39e931bf/form.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/524does not display pdf file correctly2018-08-21T11:07:52ZBugzilla Migration Userdoes not display pdf file correctly## Submitted by Martin Juergens
Assigned to **poppler-bugs**
**[Link to original bug (#17422)](https://bugs.freedesktop.org/show_bug.cgi?id=17422)**
## Description
Created attachment 18658
pdf file
the attached pdf document is no...## Submitted by Martin Juergens
Assigned to **poppler-bugs**
**[Link to original bug (#17422)](https://bugs.freedesktop.org/show_bug.cgi?id=17422)**
## Description
Created attachment 18658
pdf file
the attached pdf document is not rendered correctly.
**Attachment 18658**, "pdf file":
[attachment.cgi](/uploads/1dfa7b548a15e6d5c4e408528669b5d5/attachment.cgi)https://gitlab.freedesktop.org/poppler/poppler/-/issues/526exported images do not have metadata2018-10-11T08:54:33ZBugzilla Migration Userexported images do not have metadata## Submitted by pdknsk
Assigned to **poppler-bugs**
**[Link to original bug (#96939)](https://bugs.freedesktop.org/show_bug.cgi?id=96939)**
## Description
In particular ICC profiles and XMP. While XMP isn't essential, ICC profiles...## Submitted by pdknsk
Assigned to **poppler-bugs**
**[Link to original bug (#96939)](https://bugs.freedesktop.org/show_bug.cgi?id=96939)**
## Description
In particular ICC profiles and XMP. While XMP isn't essential, ICC profiles are for color accuracy.
For JPEGs, it's relatively easy to patch a JFIF header into the file with the ICC profile.
https://www.w3.org/Graphics/JPEG/jfif3.pdf
http://www.color.org/newiccspec.pdf (87)
Of course this doesn't solve the problem for other image types.
At the very least, a warning should be printed to alert the user about this.https://gitlab.freedesktop.org/poppler/poppler/-/issues/527windows build of pdftohtml generating malformed first page2018-08-21T11:08:02ZBugzilla Migration Userwindows build of pdftohtml generating malformed first page## Submitted by Craig Whitcombe
Assigned to **poppler-bugs**
**[Link to original bug (#39896)](https://bugs.freedesktop.org/show_bug.cgi?id=39896)**
## Description
You dont provide a prebuild windows installer so I have used the o...## Submitted by Craig Whitcombe
Assigned to **poppler-bugs**
**[Link to original bug (#39896)](https://bugs.freedesktop.org/show_bug.cgi?id=39896)**
## Description
You dont provide a prebuild windows installer so I have used the one available from here:
http://www.compgeom.com/~piyush/scripts/scripts.html
When I generate a complex document the first page looks garbled because the first page is treated as both an image and text.
This results in text overlaying the same text in the image. As it is off by a couple of pixels the result is not readable.
Unfortunately I do not have a demo document at this timehttps://gitlab.freedesktop.org/poppler/poppler/-/issues/528Bad quality font rendering in main PDF document body2020-06-21T17:33:44ZBugzilla Migration UserBad quality font rendering in main PDF document body## Submitted by Andrey Borzenkov `@bor`
Assigned to **poppler-bugs**
**[Link to original bug (#24815)](https://bugs.freedesktop.org/show_bug.cgi?id=24815)**
## Description
I was told to report it here by KDE developers. KDE bug: h...## Submitted by Andrey Borzenkov `@bor`
Assigned to **poppler-bugs**
**[Link to original bug (#24815)](https://bugs.freedesktop.org/show_bug.cgi?id=24815)**
## Description
I was told to report it here by KDE developers. KDE bug: http://bugs.kde.org/show_bug.cgi?id=212298. Poppler version: poppler-0.12.1-2mdv2010.0. Screenshot: https://bugs.kde.org/attachment.cgi?id=37952
Look at attached screen shot. The main document text appears very blurry
comparing with anything else on the screen. Actually it literally strains my
eyes to read it.
I am happy to provide any additional information; I'm just not exactly sure
which one.https://gitlab.freedesktop.org/poppler/poppler/-/issues/529rendering graphics as black boxes2018-08-21T11:08:10ZBugzilla Migration Userrendering graphics as black boxes## Submitted by Pedro Villavicencio
Assigned to **poppler-bugs**
**[Link to original bug (#39601)](https://bugs.freedesktop.org/show_bug.cgi?id=39601)**
## Description
this report has been filed here:
https://bugs.launchpad.net/u...## Submitted by Pedro Villavicencio
Assigned to **poppler-bugs**
**[Link to original bug (#39601)](https://bugs.freedesktop.org/show_bug.cgi?id=39601)**
## Description
this report has been filed here:
https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/817064
"for several days now evince displays PDF files generated by printing with firefox to cupspdf incorrectly. It renders embedded graphics as black boxes (example attached).
I still can print and display these files with okular correctly, so I guess it is a problem of evince. (I first opened a bug for ghostscript but then realized that my printer's queue and okular process it correctly.)" BTW acroread is not showing the graphics either but it works fine with xpdf. Thanks!.
pdf:
https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/817064/+attachment/2236614/+files/job_622-Doctoral_degrees__The_disposable_academic___The_Economist.pdfhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/530Poppler doesn't render PDFs that check Adobe Reader is there using JavaScript2023-10-09T18:12:13ZBugzilla Migration UserPoppler doesn't render PDFs that check Adobe Reader is there using JavaScript## Submitted by Keenan Pepper
Assigned to **poppler-bugs**
**[Link to original bug (#14265)](https://bugs.freedesktop.org/show_bug.cgi?id=14265)**
## Description
Instead of the actual document text, Poppler renders this as a singl...## Submitted by Keenan Pepper
Assigned to **poppler-bugs**
**[Link to original bug (#14265)](https://bugs.freedesktop.org/show_bug.cgi?id=14265)**
## Description
Instead of the actual document text, Poppler renders this as a single page that
says:
"To view the full contents of this document, you need a later version of the
PDF viewer. You can upgrade
to the latest version of Adobe Reader from
www.adobe.com/products/acrobat/readstep2.html
For further support, go to www.adobe.com/support/products/acrreader.html"
I think Poppler can do better.
Steps to reproduce:
1. Open http://undergradresearch.fsu.edu/Gfx/summer_award.pdf with Evince
Actual results:
Evince displays some lame error message embedded in the PDF.
Expected results:
Evince should display a "best effort" rendering of the actual text I want to
read.
Does this happen every time?
Yes.
Other information:
This seemed similar to some other reported bugs in Evince, but in all the ones I looked at, highlighting the text made it visible. In this case, highlighting does nothing.
### Depends on
* [Bug 14433](https://bugs.freedesktop.org/show_bug.cgi?id=14433)https://gitlab.freedesktop.org/poppler/poppler/-/issues/532Bitmap not shown2018-08-31T19:33:12ZBugzilla Migration UserBitmap not shown## Submitted by oli..@..den.de
Assigned to **poppler-bugs**
**[Link to original bug (#107112)](https://bugs.freedesktop.org/show_bug.cgi?id=107112)**
## Description
Created attachment 140460
Problematic page rendered with the spla...## Submitted by oli..@..den.de
Assigned to **poppler-bugs**
**[Link to original bug (#107112)](https://bugs.freedesktop.org/show_bug.cgi?id=107112)**
## Description
Created attachment 140460
Problematic page rendered with the splash backend
Consider the file http://www.mdpi.com/2072-4292/10/5/804/pdf
The bitmaps in Figure 7 on page ??? are not shown with the splash backend.
To reproduce:
./test-render-to-file-qt5 ~/tmp/remotesensing-10-00804-v2.pdf
and then have a look at test-render-to-file11.ppm (attached as test-render-to-file11-splash.ppm).
For comparison, call
./test-render-to-file-qt5 ~/tmp/remotesensing-10-00804-v2.pdf -arthur
and then have a look at test-render-to-file11.ppm again (attached as test-render-to-file11-arthur.ppm).
BTW, the test program prints 'Bogus memory allocation size' several times when handling the pages with the problematic images.
**Attachment 140460**, "Problematic page rendered with the splash backend":
[test-render-to-file11-splash.ppm](/uploads/f70ebf505492ee987c4403a2bce694a7/test-render-to-file11-splash.ppm)https://gitlab.freedesktop.org/poppler/poppler/-/issues/533Infinite loop in TextOutputDev2018-08-21T11:08:48ZBugzilla Migration UserInfinite loop in TextOutputDev## Submitted by Adrian Johnson `@ajohnson`
Assigned to **poppler-bugs**
**[Link to original bug (#30892)](https://bugs.freedesktop.org/show_bug.cgi?id=30892)**
## Description
The attached PDF appears to have an infinite loop in Te...## Submitted by Adrian Johnson `@ajohnson`
Assigned to **poppler-bugs**
**[Link to original bug (#30892)](https://bugs.freedesktop.org/show_bug.cgi?id=30892)**
## Description
The attached PDF appears to have an infinite loop in TextOutputDev when using the cairo backend. A git bisect shows the commit that introduced this bug to be:
commit 5b0f2355d55a5104820fd0bf16b4e76b25959de4
Author: Carlos Garcia Campos <carlosgc@gnome.org>
Date: Sun Dec 14 11:49:00 2008 +0100
[glib] Use TextPage instead of TextOutputDev when cairo is enabledhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/534pdftotext - processing small pdf takes long time and creates cpu peaks2018-10-05T22:23:07ZBugzilla Migration Userpdftotext - processing small pdf takes long time and creates cpu peaks## Submitted by David Przybilla
Assigned to **poppler-bugs**
**[Link to original bug (#92724)](https://bugs.freedesktop.org/show_bug.cgi?id=92724)**
## Description
The following PDF is only 5 pages long, 4.8M.
However calling pdft...## Submitted by David Przybilla
Assigned to **poppler-bugs**
**[Link to original bug (#92724)](https://bugs.freedesktop.org/show_bug.cgi?id=92724)**
## Description
The following PDF is only 5 pages long, 4.8M.
However calling pdftotext on it takes approximately 3min and cpu goes to 100%.
Other Longer PDFs take only a few seconds and cpu usage is not mental, so this behaviour looks weird.
Here are some extra details:
pdftotext version 0.37.0 ( compiled from the latest stable release)
compiled with the following options:
/configure --disable-libopenjpeg --disable-poppler-qt4 --disable-gtk-test --disable-cairo-output --disable-splash-output --with-prefix=/usr/local
OS: Ubuntu 14.04 LTS, OSXhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/537pdftops create hugh file from simple BIRT PDF/chart2018-10-26T15:24:46ZBugzilla Migration Userpdftops create hugh file from simple BIRT PDF/chart## Submitted by Yair Lenga
Assigned to **poppler-bugs**
**[Link to original bug (#21723)](https://bugs.freedesktop.org/show_bug.cgi?id=21723)**
## Description
Created attachment 25833
Sample Chart created with BIRT 2_3_1.
When ru...## Submitted by Yair Lenga
Assigned to **poppler-bugs**
**[Link to original bug (#21723)](https://bugs.freedesktop.org/show_bug.cgi?id=21723)**
## Description
Created attachment 25833
Sample Chart created with BIRT 2_3_1.
When running pdftops on the attached small PDF file (4K), the result Postscript file is 560K. Trying to manipulate the program with command line arguments (level3, ...), did not yield any improvement.
With XPDF 3.0, the PS file size is <20K.
It seems that the code attempt to convert the small chart into high res image, resulting in loss of precision, large file, and long printing/viewing time.
The PDF file was generated with BIRT - Ecplise Reporting platform.
I'm build/run poppler or RedHat 4
**Attachment 25833**, "Sample Chart created with BIRT 2_3_1.":
[bad.pdf](/uploads/8d4fb8611ce40f250e0b90832735dcbc/bad.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/541"8" shown instead of "x" inside checkbox when converting LibreOffice-generate...2021-05-22T20:58:12ZBugzilla Migration User"8" shown instead of "x" inside checkbox when converting LibreOffice-generated form to PostScript## Submitted by Michael Weghorn
Assigned to **poppler-bugs**
**[Link to original bug (#107303)](https://bugs.freedesktop.org/show_bug.cgi?id=107303)**
## Description
Created attachment 140724
Sample form generated by LibreOffice
...## Submitted by Michael Weghorn
Assigned to **poppler-bugs**
**[Link to original bug (#107303)](https://bugs.freedesktop.org/show_bug.cgi?id=107303)**
## Description
Created attachment 140724
Sample form generated by LibreOffice
Converting a LibreOffice-generated PDF form with a ticked checkbox to PostScript leads to an "8" being shown inside the check box rather than the expected "x" sign.
Steps to reproduce:
1) Open attached PDF form "simple_form.pdf" in Okular
2) tick the checkbox
3) print (either to a real printer or use "Print to File (PDF)")
4) Look at the output/printout
Result:
An "8" is shown inside of the checkbox that has been ticked.
Expected result:
The same checkmark ("x") as displayed in Okular is shown inside the checkbox on the printout.
This can also be reproduced by directly calling 'pdftops' on a PDF form saved after ticking the checkbox:
$ pdftops simple_form_CHECKBOX_TICKED_CLEANED.pdf
Syntax Error: Unknown font tag 'ZaDb'
Syntax Error: Unknown font tag 'ZaDb'
(In addition to ticking the checkbox, the document has been run through 'mutool clean' to make analysis easier.)
**Attachment 140724**, "Sample form generated by LibreOffice":
[simple_form.pdf](/uploads/0dcb7e1b803e6d4429d083695109d896/simple_form.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/544[PATCH] Form and annotation borders are not drawn when field /S is not presen...2018-10-07T00:20:25ZBugzilla Migration User[PATCH] Form and annotation borders are not drawn when field /S is not present in /BS## Submitted by Andrew Chen
Assigned to **poppler-bugs**
**[Link to original bug (#102640)](https://bugs.freedesktop.org/show_bug.cgi?id=102640)**
## Description
Border width should not be forced to 0 when /W and/or /S are not pre...## Submitted by Andrew Chen
Assigned to **poppler-bugs**
**[Link to original bug (#102640)](https://bugs.freedesktop.org/show_bug.cgi?id=102640)**
## Description
Border width should not be forced to 0 when /W and/or /S are not present in /BS
Commit 289679405 introduced the behavior: "Avoid drawing borders unless /W and /S are specified in /BS" as a work around for acroread 8. This is not compliant with the pdf specs, and the latest versions of Adobe Acrobat (2017) don't requires both fields to be present, and does not emit the /S field when not necessary.
User visible impact: form and annotation borders are not generated properly when saving pdfs after editing.https://gitlab.freedesktop.org/poppler/poppler/-/issues/546Certificate chain from PDF digital signature back to trusted root certificate...2020-07-29T10:37:56ZBugzilla Migration UserCertificate chain from PDF digital signature back to trusted root certificate not verified?## Submitted by Sebastian Rasmussen
Assigned to **poppler-bugs**
**[Link to original bug (#99365)](https://bugs.freedesktop.org/show_bug.cgi?id=99365)**
## Description
I believe that the full certificate chain back to a trusted ro...## Submitted by Sebastian Rasmussen
Assigned to **poppler-bugs**
**[Link to original bug (#99365)](https://bugs.freedesktop.org/show_bug.cgi?id=99365)**
## Description
I believe that the full certificate chain back to a trusted root certificate is not verified when attempting to verify digital signatures in PDFs.
SignatureHandler::init_nss() initializes NSS to point to my root
certficate database in my firefox profile or if not available
(it is available) /etc/pki/nssdb (which is unpopoulated on my machine).
I believe that the idea is that this database of root certificates
will be used when verifying the chain of certificates in digital signatures.
I downloaded http://blogs.adobe.com/security/SampleSignedPDFDocument.pdf
and then ran pdfsig (compiled from git HEAD currently at c301f6c6) like so:
./pdfsig-original ./SampleSignedPDFDocument.pdf
Digital Signature Info of:./SampleSignedPDFDocument.pdf
Signature #1:
- Signer Certificate Common Name: John B Harris
- Signing Time: Jul 16 2009 16:47:47
- Signature Validation: Signature is Valid.
- Certificate Validation: Certificate has Expired
The mesage "Signature is Valid" implies that the chain of certificates
has all been checked. However if I replace the call to NSS_Init() with
a call that explicitlydisables any preinitialized database like so:
diff --git a/poppler/SignatureHandler.cc b/poppler/SignatureHandler.cc
index 15c9321c..4be4a140 100644
--- a/poppler/SignatureHandler.cc
+++ b/poppler/SignatureHandler.cc
@@ -91,16 +91,9 @@ GooString *SignatureHandler::getDefaultFirefoxCertDB_Linux()
*/
void SignatureHandler::init_nss()
{
- GooString *certDBPath = getDefaultFirefoxCertDB_Linux();
- if (certDBPath == NULL) {
- NSS_Init("sql:/etc/pki/nssdb");
- } else {
- NSS_Init(certDBPath->getCString());
- }
+ NSS_NoDB_Init("");
//Make sure NSS root certificates module is loaded
SECMOD_AddNewModule("Root Certs", "libnssckbi.so", 0, 0);
-
- delete certDBPath;
}
And then recompile and rerun pdfsig I get the same message as above:
./pdfsig-changed ./SampleSignedPDFDocument.pdf
Digital Signature Info of: ./SampleSignedPDFDocument.pdf
Signature #1:
- Signer Certificate Common Name: John B Harris
- Signing Time: Jul 16 2009 16:47:47
- Signature Validation: Signature is Valid.
- Certificate Validation: Certificate has Expired
Which again seems to claim that the chain of certificates is valid.
How can that be when there are no trusted root certificates in the database?
This appears to be corroborated by the comment preceeding the function
NSS_CMSSignerInfo_Verify() which SignatureHandler later calls to do the
verification:
"Just verifies the signature. The assumption is that verification of
the certificate is done already", see
https://hg.mozilla.org/projects/nss/file/tip/lib/smime/cmssiginfo.c#l310
I believe that the intent with the poppler code is to verify
the entire certificate chain (why else bother to add the firefox
root certificate database?), but I don't think that is what is happening.
Unfortunately I'm not yet well versed in this code to figure out
how to fix this, hence there is no patch attached fixing this issue.
Maybe the decision is to be happy that the certificate is self-consistent
and that the digest is matching, etc. but to ignore that the _chain_ of
certificates is never checked, however in that case I'd suggest mentioning
this clearly, e.g. "Signature is Valid (chain back to root certificate not checked)".
Oh, and of course any UI that uses SignatureHandler is equally affected
as pdfsig, but I find reporting issued using command-line tools easier. :)https://gitlab.freedesktop.org/poppler/poppler/-/issues/548pdftocairo - Flag to disable text drawing2018-10-08T10:29:02ZBugzilla Migration Userpdftocairo - Flag to disable text drawing## Submitted by Ryan Fox
Assigned to **poppler-bugs**
**[Link to original bug (#65877)](https://bugs.freedesktop.org/show_bug.cgi?id=65877)**
## Description
Created attachment 80975
Patch to add a flag to disable text drawing. Bas...## Submitted by Ryan Fox
Assigned to **poppler-bugs**
**[Link to original bug (#65877)](https://bugs.freedesktop.org/show_bug.cgi?id=65877)**
## Description
Created attachment 80975
Patch to add a flag to disable text drawing. Based on the code in the 0.23.2 release.
I needed to hack pdftocairo to allow me to disable the text drawing, and I thought it could be something other people might benefit from, so I'm presenting a tiny patch to add a flag for it.
Background: Cairo's SVG backend doesn't draw text as text; it creates shapes for each letter. (See [bug 38516](https://bugs.freedesktop.org/show_bug.cgi?id=38516)) I'm using the output from pdftocairo for the structure of a PDF, rather than the visual representation, so the actual text is important to me, as well as all of the shapes. I can get sufficient text information from `pdftohtml -xml` for this. To prevent losing non-letter glyphs, I need to prevent the drawing of the text rather than just discarding all of the glyphs.
**Attachment 80975**, "Patch to add a flag to disable text drawing. Based on the code in the 0.23.2 release.":
[notext.patch](/uploads/eb059e151a453c366c6ee6294dc84b77/notext.patch)https://gitlab.freedesktop.org/poppler/poppler/-/issues/553"UTF-16" not native byte order on OS X iconv (re ustrings to_utf8)2018-10-26T11:11:40ZBugzilla Migration User"UTF-16" not native byte order on OS X iconv (re ustrings to_utf8)## Submitted by Franz Brauße
Assigned to **poppler-bugs**
**[Link to original bug (#96313)](https://bugs.freedesktop.org/show_bug.cgi?id=96313)**
## Description
Hi.
ustring::to_utf8() creates a
MiniIconv ic("UTF-8", "UTF-16");...## Submitted by Franz Brauße
Assigned to **poppler-bugs**
**[Link to original bug (#96313)](https://bugs.freedesktop.org/show_bug.cgi?id=96313)**
## Description
Hi.
ustring::to_utf8() creates a
MiniIconv ic("UTF-8", "UTF-16");
assuming that iconv(3) uses the native byte order for "UTF-16". On OS X w/ Intel CPUs (I installed poppler through MacPorts, but this issue is unrelated, see below) this fails, as a quick
$ echo -n 7 | iconv -t utf-16 | hexdump -C
00000000 fe ff 00 37 |...7|
reveals: it's UTF-16BE.
This breaks page-labels for me, which instead of "78" (UTF-8) return the (hex) values
e3 9c 80 e3 a0 80
which is 0x3700 0x3800.
A fix might be to not "decode" GooString's UTF-16BE to native byte order in
detail::unicode_GooString_to_ustring(GooString *str)
or use a source encoding based on the BYTE_ORDER macro instead of just "UTF-16BE" or to check the BOM-character output by iconv(3) (which e.g.
ustring::from_utf8(const char *str, int len)
currently skips).https://gitlab.freedesktop.org/poppler/poppler/-/issues/554gfile win32 unicode fixes and refactoring2018-10-23T12:08:46ZBugzilla Migration Usergfile win32 unicode fixes and refactoring## Submitted by Adrian Johnson `@ajohnson`
Assigned to **poppler-bugs**
**[Link to original bug (#104045)](https://bugs.freedesktop.org/show_bug.cgi?id=104045)**
## Description
The aim of the following patches is to:
- Improve wi...## Submitted by Adrian Johnson `@ajohnson`
Assigned to **poppler-bugs**
**[Link to original bug (#104045)](https://bugs.freedesktop.org/show_bug.cgi?id=104045)**
## Description
The aim of the following patches is to:
- Improve win32 unicode support in goo/gfile.cc.
- Eliminate duplicated functions that differ only by char*/wchar_t*. All internal functions should use char* and the win32 wchar_t conversion should be performed at the point where the win32 API is invoked.
- Eliminate unused code.
- Eventually get windows.h out of the header files. It slows down the compile and pollutes the namespace.
- Plus some other mingw fixes and build cleanups I found while working on this.https://gitlab.freedesktop.org/poppler/poppler/-/issues/555pdftoppm writes to standard output2018-10-06T23:50:36ZBugzilla Migration Userpdftoppm writes to standard output## Submitted by Christopher Yeleighton
Assigned to **poppler-bugs**
**[Link to original bug (#35221)](https://bugs.freedesktop.org/show_bug.cgi?id=35221)**
## Description
When invoked as { pdftoppm x.pdf; }, pdftoppm writes PPM to...## Submitted by Christopher Yeleighton
Assigned to **poppler-bugs**
**[Link to original bug (#35221)](https://bugs.freedesktop.org/show_bug.cgi?id=35221)**
## Description
When invoked as { pdftoppm x.pdf; }, pdftoppm writes PPM to standard output. This behavior is undocumented.https://gitlab.freedesktop.org/poppler/poppler/-/issues/556-xml outputs malformed xml2018-08-21T11:11:02ZBugzilla Migration User-xml outputs malformed xml## Submitted by dan..@..il.com
Assigned to **poppler-bugs**
**[Link to original bug (#98305)](https://bugs.freedesktop.org/show_bug.cgi?id=98305)**
## Description
Overview:
The following pdf causes pdftohtml to output malform...## Submitted by dan..@..il.com
Assigned to **poppler-bugs**
**[Link to original bug (#98305)](https://bugs.freedesktop.org/show_bug.cgi?id=98305)**
## Description
Overview:
The following pdf causes pdftohtml to output malformed xml:
http://www.atmel.com/images/Atmel-8284-8-bit-AVR-microcontroller-ATmega169A_PA_329A_PA_3290A_PA_649A_P_6490A_P_datasheet.pdf
The resulting xml file has multiple similar errors, the first one on line 71641:
`<text top="180" left="71" width="101" height="15" font="11">``<b>`Sp<a href="Atmel-8284-8-bit-AVR-microcontroller-ATmega169A_PA_329A_PA_3290A_PA_649A_P_6490A_P_datasheet.html#876">eed [MHz] `</b>`(3)`</a>``</text>`
(the closing b and a tags are not in the correct order)
Steps to Reproduce:
1) wget http://www.atmel.com/images/Atmel-8284-8-bit-AVR-microcontroller-ATmega169A_PA_329A_PA_3290A_PA_649A_P_6490A_P_datasheet.pdf
2) pdftohtml -q -i -xml Atmel-8284-8-bit-AVR-microcontroller-ATmega169A_PA_329A_PA_3290A_PA_649A_P_6490A_P_datasheet.pdf output.xml
Actual Results:
malformed xml
Expected Results:
well-formed xml. And I'm not quite sure if the link is placed on the correct piece of text. In the pdf only the text "(3)" is clickable and none of it is bold.
Build Date & Hardware:
Built on 2016-10-18 from source (0.48.0) on Ubunty 14.04 LTS
Additional Builds and Platforms:
Also occurred in the version of pdftohtml that was installed using apt-get (0.28 if I recall correctly)
Cheers,
Danielhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/557Option thinlinemode shape for pdftoppm doesn't work correct for fill operations2018-10-11T08:21:18ZBugzilla Migration UserOption thinlinemode shape for pdftoppm doesn't work correct for fill operations## Submitted by Thomas Freitag
Assigned to **poppler-bugs**
**[Link to original bug (#94152)](https://bugs.freedesktop.org/show_bug.cgi?id=94152)**
## Description
Created attachment 121754
splashThinLineShape also for fill operati...## Submitted by Thomas Freitag
Assigned to **poppler-bugs**
**[Link to original bug (#94152)](https://bugs.freedesktop.org/show_bug.cgi?id=94152)**
## Description
Created attachment 121754
splashThinLineShape also for fill operations
This is a followup for [bug 94052](https://bugs.freedesktop.org/show_bug.cgi?id=94052)!
Looking at [bug 94052](https://bugs.freedesktop.org/show_bug.cgi?id=94052) I encountered that the thinlinemode shape doesn't work correctly for the PDF of [bug 94052](https://bugs.freedesktop.org/show_bug.cgi?id=94052): Instead of a gray grid the background is completely removed and shown as white if using this option.
The difference between the PDF of [bug 94052](https://bugs.freedesktop.org/show_bug.cgi?id=94052) and the one of [bug 37347](https://bugs.freedesktop.org/show_bug.cgi?id=37347) is that in the PDF of [bug 37347](https://bugs.freedesktop.org/show_bug.cgi?id=37347) the lines are drawn with a stroke, where as in the one of [bug 94052](https://bugs.freedesktop.org/show_bug.cgi?id=94052) the lines are drawn with a fill command.
So I extend in this patch the implementation of the "shape" mode so that it works with fills, too.
**Patch 121754**, "splashThinLineShape also for fill operations":
[94052.patch](/uploads/8450021efdf72f06d70342738823ea9f/94052.patch)https://gitlab.freedesktop.org/poppler/poppler/-/issues/559no alpha channel in images extracted with pdfimages tool2018-08-21T11:11:14ZBugzilla Migration Userno alpha channel in images extracted with pdfimages tool## Submitted by quu..@..il.com
Assigned to **poppler-bugs**
**[Link to original bug (#28963)](https://bugs.freedesktop.org/show_bug.cgi?id=28963)**
## Description
Images are output in PPM, which does not support an alpha channel. ...## Submitted by quu..@..il.com
Assigned to **poppler-bugs**
**[Link to original bug (#28963)](https://bugs.freedesktop.org/show_bug.cgi?id=28963)**
## Description
Images are output in PPM, which does not support an alpha channel. I suggest switching this to the similar binary format PAM which supports an optional alpha channel or the more standard PNG format.https://gitlab.freedesktop.org/poppler/poppler/-/issues/562HTML text shifts relatively it underline2018-08-21T11:11:25ZBugzilla Migration UserHTML text shifts relatively it underline## Submitted by sve..@..il.com
Assigned to **poppler-bugs**
**[Link to original bug (#90097)](https://bugs.freedesktop.org/show_bug.cgi?id=90097)**
## Description## Submitted by sve..@..il.com
Assigned to **poppler-bugs**
**[Link to original bug (#90097)](https://bugs.freedesktop.org/show_bug.cgi?id=90097)**
## Descriptionhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/563Render a single annotation with Qt5 frontend2018-10-08T21:10:13ZBugzilla Migration UserRender a single annotation with Qt5 frontend## Submitted by Tobias Deiminger
Assigned to **poppler-bugs**
**[Link to original bug (#105796)](https://bugs.freedesktop.org/show_bug.cgi?id=105796)**
## Description
This is the Qt double of [bug 83642](https://bugs.freedesktop.o...## Submitted by Tobias Deiminger
Assigned to **poppler-bugs**
**[Link to original bug (#105796)](https://bugs.freedesktop.org/show_bug.cgi?id=105796)**
## Description
This is the Qt double of [bug 83642](https://bugs.freedesktop.org/show_bug.cgi?id=83642). It adds Annotation::renderToImage() and similar methods.
The patch series has following use cases in mind:
-show realistic preview of icons in readers
-WYSIWYG editing of free text annotations, e.g. typewriter
-paint annotations while dragging them around (render page is expensive)
-extract single annotations from PDF with a command line tool
-enable composition of annotations in readers; quite tricky, due to blend mode, z-order and the ilk
Example usage:
...
/* Generate image where annotation #0 is painted at offset (0,0) on transparent background. */
Poppler::Annotation* annot = pdfPage->annotations()[0];
QImage img = annot->renderToImage(myDpiX, myDpiY);
...
I'd recommend to fix [bug 105692](https://bugs.freedesktop.org/show_bug.cgi?id=105692) along with these patches, to get the size right in all circumstances.https://gitlab.freedesktop.org/poppler/poppler/-/issues/564no pages in (probably corrupted) document2018-08-21T11:11:43ZBugzilla Migration Userno pages in (probably corrupted) document## Submitted by Hib Eris
Assigned to **poppler-bugs**
**[Link to original bug (#44488)](https://bugs.freedesktop.org/show_bug.cgi?id=44488)**
## Description
Created attachment 55161
PDF document showing no pages in poppler
Forwar...## Submitted by Hib Eris
Assigned to **poppler-bugs**
**[Link to original bug (#44488)](https://bugs.freedesktop.org/show_bug.cgi?id=44488)**
## Description
Created attachment 55161
PDF document showing no pages in poppler
Forwarding a bug from Evince' mailing-list:
On Sun, Dec 25, 2011 at 12:59 PM, <Software@quantentunnel.de> wrote:
>
> I use Document Viewer 2.32.0 with poppler/cairo (0.16.4) on Ubuntu 11.04 and
> gnome 2.32.1. The attached pdf document (downloaded from
> http://www.ubs.com/ch/de/swissbank/private/families_couples.html, then click
> 'UBS Family' in upper right corner of web page) does not open correctly,
> instead evince says "Das Dokument enthält keine Seiten" (= the document does
> not contain pages). The same document opens correctly with Adobe Acrobat
> Reader 9 for Linux, version 9.4.2 02/11/2011.
**Attachment 55161**, "PDF document showing no pages in poppler":
[164787_20090324_Brosch_Family_Jan09_D_ohne_20Talon.pdf](/uploads/85a40db24a395ff17d7a0b56cc7a1513/164787_20090324_Brosch_Family_Jan09_D_ohne_20Talon.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/566Add option to omit DOCTYPE for XML output2019-03-28T13:05:51ZBugzilla Migration UserAdd option to omit DOCTYPE for XML output## Submitted by Gerrit Imsieke
Assigned to **poppler-bugs**
**[Link to original bug (#103823)](https://bugs.freedesktop.org/show_bug.cgi?id=103823)**
## Description
Currently (I’m using 0.57.0 on Cygwin), with the -xml option, the...## Submitted by Gerrit Imsieke
Assigned to **poppler-bugs**
**[Link to original bug (#103823)](https://bugs.freedesktop.org/show_bug.cgi?id=103823)**
## Description
Currently (I’m using 0.57.0 on Cygwin), with the -xml option, there is always a DOCTYPE declaration with no public identifier and the system identifier 'pdf2xml.dtd'.
The issue is that I can’t use an XML catalog to direct pdf2xml.dtd to a (possibly empty) DTD. This is an issue with relative paths as system identifiers. It is described on http://www.sagehill.net/docbookxsl/WriteCatalog.html#RelativeSysId
As a consequence, I need to remove the DOCTYPE line manually or with xmllint in order to be able to process the output with Java-based tools such as oXygen, Saxon, or XML Calabash.
Please add either a public identifier (any non-empty string will do) that can be diverted by means of an XML catalog, or add a command-line option not to issue a DOCTYPE declaration at all.https://gitlab.freedesktop.org/poppler/poppler/-/issues/568Syntax Error: Unknown character collection 'DYNA-HK1'2018-08-21T11:12:55ZBugzilla Migration UserSyntax Error: Unknown character collection 'DYNA-HK1'## Submitted by Martin Hong
Assigned to **poppler-bugs**
**[Link to original bug (#93290)](https://bugs.freedesktop.org/show_bug.cgi?id=93290)**
## Description
Overview: I tried to convert a sample pdf which is exported from Mac O...## Submitted by Martin Hong
Assigned to **poppler-bugs**
**[Link to original bug (#93290)](https://bugs.freedesktop.org/show_bug.cgi?id=93290)**
## Description
Overview: I tried to convert a sample pdf which is exported from Mac OS X's Keynote.app and contains some Chinese characters through `pdftoppm` command, but it complains with an error:
Syntax Error: Unknown character collection 'DYNA-HK1'
Steps to Reproduce:
1. Open Keynote.app, click "New Document", and then select a random theme to start;
2. Input some Chinese characters on slides;
3. Click "File" menu item and then select "Export to ..." and select "PDF";
4. Export a PDF file;
5. Use `pdftoppm` to convert exported PDF file.
Actual Results:
it complains with an error: "Syntax Error: Unknown character collection 'DYNA-HK1'"
Expected Results:
Convert sample PDF file into images without any complain.
Build Date & Hardware:
2015-12-05 on Mac OS 10.11.1 with Keynote.app v6.6.1
Additional Information:
The below lists some details:
————————
$ pdftoppm -v
pdftoppm version 0.37.0
Copyright 2005-2015 The Poppler Developers - http://poppler.freedesktop.org
Copyright 1996-2011 Glyph & Cog, LLC
————————
$ pdftoppm -png ~/Desktop/test.pdf tmp
Syntax Error: Unknown character collection 'DYNA-HK1’
the `test.pdf` is exported from Mac OS’ Keynote.app and contains some Chinese characters. If I try to export a pdf which doesn’t contain any Chinese characters, it will work. Additionally, I also tried to use pdftotext to print text in `test.pdf`, it can print text normally.
You can also download the test pdf from here: http://7xj84e.com1.z0.glb.clouddn.com/test.pdf .
I also tried to convert the test pdf through ImageMagick's convert command, it worked as expected as poppler did not.https://gitlab.freedesktop.org/poppler/poppler/-/issues/570Extend support for free text annotations.2022-08-10T22:28:14ZBugzilla Migration UserExtend support for free text annotations.## Submitted by Anuj Khare
Assigned to **poppler-bugs**
**[Link to original bug (#81665)](https://bugs.freedesktop.org/show_bug.cgi?id=81665)**
## Description
Created attachment 103325
1/4. glib: Add PopplerAnnotAppearance boxed t...## Submitted by Anuj Khare
Assigned to **poppler-bugs**
**[Link to original bug (#81665)](https://bugs.freedesktop.org/show_bug.cgi?id=81665)**
## Description
Created attachment 103325
1/4. glib: Add PopplerAnnotAppearance boxed type
I have attached patches that allow adding new freetext annotations, and implement the intent, callout line, and quadding properties.
The PopplerAnnotAppearance type is used to store the font name, color and size of the free text annotation.
~~**Patch 103325**~~, "1/4. glib: Add PopplerAnnotAppearance boxed type":
[1.patch](/uploads/843c4580b5c48af47f73eec78f317780/1.patch)https://gitlab.freedesktop.org/poppler/poppler/-/issues/571Text not rendered in poppler-glib2018-08-21T11:13:21ZBugzilla Migration UserText not rendered in poppler-glib## Submitted by Germán Poo-Caamaño
Assigned to **poppler-bugs**
**[Link to original bug (#76042)](https://bugs.freedesktop.org/show_bug.cgi?id=76042)**
## Description
Created attachment 95622
PDF Test Case
This was reported in GN...## Submitted by Germán Poo-Caamaño
Assigned to **poppler-bugs**
**[Link to original bug (#76042)](https://bugs.freedesktop.org/show_bug.cgi?id=76042)**
## Description
Created attachment 95622
PDF Test Case
This was reported in GNOME's bugzilla.
The attached PDF does not render any text, but the background and images.
The text can be selected, copied and pasted without major issues.
qt4, either with arthur and splash backend, renders the document fine. So,
I assume it could be an issue with cairo-backend.
poppler 7a2db6 and cairo 2a7f13.
**Attachment 95622**, "PDF Test Case":
[colfax1.pdf](/uploads/de1280e415f8005012246530ddb71388/colfax1.pdf)
### See also
* [Bug 726128](https://bugzilla.gnome.org/show_bug.cgi?id=726128)https://gitlab.freedesktop.org/poppler/poppler/-/issues/572regression causes correctly rendered PDF to print incorrectly with spirals in...2018-08-21T11:13:27ZBugzilla Migration Userregression causes correctly rendered PDF to print incorrectly with spirals instead of some spaces## Submitted by wxl
Assigned to **poppler-bugs**
**[Link to original bug (#70466)](https://bugs.freedesktop.org/show_bug.cgi?id=70466)**
## Description
Created attachment 87632
pdf that prints with weird spirals instead of some sp...## Submitted by wxl
Assigned to **poppler-bugs**
**[Link to original bug (#70466)](https://bugs.freedesktop.org/show_bug.cgi?id=70466)**
## Description
Created attachment 87632
pdf that prints with weird spirals instead of some spaces
this has been escalated from the KDE bugtracker. originally thought to be an issue with Okular, it has become apparent the issue lies in poppler itself. the original bug report can be seen here:
https://bugs.kde.org/show_bug.cgi?id=325908
long story short:
The attached PDF, when printing, on some lines, spaces are replaced with a spiral character I can't identify. An example is the second line of the guarantee on page 8.
This is with KDE 4.10.5 (Kubuntu 13.04) and Okular 0.16.5 (GPL Ghostscript 9.07 (2013-02-14)).
No problem with Adobe Reader, lp, or KDE 4.8.5/Kubuntu 12.04.3/Okular 0.14.3 (GPL Ghostscript 9.05 (2012-02-08)).
pdftops has no problem, but gs .ps results in a segfault when it hits the aforementioned line.
**Attachment 87632**, "pdf that prints with weird spirals instead of some spaces":
[Front___Rear_Rack_w-Sat_Mk_II_Imposed.pdf](/uploads/9537e10393ae2f8816fdc18f54589256/Front___Rear_Rack_w-Sat_Mk_II_Imposed.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/574Loading image from a big pdf display blank image2018-08-21T11:13:52ZBugzilla Migration UserLoading image from a big pdf display blank image## Submitted by Munish Kumar
Assigned to **poppler-bugs**
**[Link to original bug (#106202)](https://bugs.freedesktop.org/show_bug.cgi?id=106202)**
## Description
Created attachment 139045
The pdf file I am facing the issue
I am ...## Submitted by Munish Kumar
Assigned to **poppler-bugs**
**[Link to original bug (#106202)](https://bugs.freedesktop.org/show_bug.cgi?id=106202)**
## Description
Created attachment 139045
The pdf file I am facing the issue
I am using poppler to load jpeg images from a pdf. When the size of loaded images cross the limit of cairo i.e `32767` it show blank jpeg image. My pdftocairo version is 0.56.0. here is an file
**Attachment 139045**, "The pdf file I am facing the issue":
[SP4_MD_HC_AB_FP_02_008_Bwin__2_.pdf](/uploads/021e9b4338a3eed357807b81f0e8373a/SP4_MD_HC_AB_FP_02_008_Bwin__2_.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/576Garbled rendering of pdfs2018-08-21T11:14:05ZBugzilla Migration UserGarbled rendering of pdfs## Submitted by Shridhar Daithankar
Assigned to **poppler-bugs**
**[Link to original bug (#91891)](https://bugs.freedesktop.org/show_bug.cgi?id=91891)**
## Description
Some pdfs have very garbled rendering e.g. http://darknedgy.ne...## Submitted by Shridhar Daithankar
Assigned to **poppler-bugs**
**[Link to original bug (#91891)](https://bugs.freedesktop.org/show_bug.cgi?id=91891)**
## Description
Some pdfs have very garbled rendering e.g. http://darknedgy.net/files/systembsd.pdf. Other pdf readers such as mupdf can render them correctly.
I am using poppler 0.33.0, okular 15.08.0(0.23.0) from archlinux packages.https://gitlab.freedesktop.org/poppler/poppler/-/issues/577pdftohtml produces wrongly nested tags2018-08-21T11:14:20ZBugzilla Migration Userpdftohtml produces wrongly nested tags## Submitted by pas..@..h.name
Assigned to **poppler-bugs**
**[Link to original bug (#89239)](https://bugs.freedesktop.org/show_bug.cgi?id=89239)**
## Description
Created attachment 113678
Source PDF
When converting the attached ...## Submitted by pas..@..h.name
Assigned to **poppler-bugs**
**[Link to original bug (#89239)](https://bugs.freedesktop.org/show_bug.cgi?id=89239)**
## Description
Created attachment 113678
Source PDF
When converting the attached PDF to XML using version 0.29.0
$ pdftohtml -xml in.pdf out.xml
It produces invalidly nested tags in the index portion near the end:
$ xmllint out.xml
out.xml:16770: parser error : Opening and ending tag mismatch: a line 16770 and b
font="11">`<b>`Abrüstung<a href="out.xml#314"> `</b>``<i>`314, `</i>``</a>`
Looking at the source document (page 320/327) the closing `</b>` should occur before the opening `<a>`, the numbers are linked and not bold.
Oddly the error doesn't occur for all entries.
~~**Attachment 113678**~~, "Source PDF":
[gruene_Wahlprogramm-barrierefrei.pdf](/uploads/8194e2624d0a1e4269b1df4f15ef76ef/gruene_Wahlprogramm-barrierefrei.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/578Barcode from attached PDF is not printed corectly2018-10-27T14:47:19ZBugzilla Migration UserBarcode from attached PDF is not printed corectly## Submitted by karaluh
Assigned to **poppler-bugs**
**[Link to original bug (#57007)](https://bugs.freedesktop.org/show_bug.cgi?id=57007)**
## Description
Created attachment 69935
Testcase
As in summary, compare the two attached...## Submitted by karaluh
Assigned to **poppler-bugs**
**[Link to original bug (#57007)](https://bugs.freedesktop.org/show_bug.cgi?id=57007)**
## Description
Created attachment 69935
Testcase
As in summary, compare the two attached PDFs. Original bug report here:
https://bugs.kde.org/show_bug.cgi?id=309729
**Attachment 69935**, "Testcase":
[74587.pdf.zip](/uploads/7ec414d4056d12599a6c825aca2405b1/74587.pdf.zip)https://gitlab.freedesktop.org/poppler/poppler/-/issues/579GNOME (evince) Bug 792943 - A single character is drawn incorrectly2018-08-22T03:39:27ZBugzilla Migration UserGNOME (evince) Bug 792943 - A single character is drawn incorrectly## Submitted by Vladimir G. Ivanovic
Assigned to **poppler-bugs**
**[Link to original bug (#105789)](https://bugs.freedesktop.org/show_bug.cgi?id=105789)**
## Description
Created attachment 138396
A PDF of a PPTX file
On p.52 of ...## Submitted by Vladimir G. Ivanovic
Assigned to **poppler-bugs**
**[Link to original bug (#105789)](https://bugs.freedesktop.org/show_bug.cgi?id=105789)**
## Description
Created attachment 138396
A PDF of a PPTX file
On p.52 of the attached PDF, the title is drawn incorrectly at some magnifications larger than 100%, the exact magnification depends on which program/library is being used (acroread, xpdf, epfdview, evince, …).
One of the reviewers of GNOME bug (https://bugzilla.gnome.org/show_bug.cgi?id=792943#c7) commented that the characters are being drawn twice, but that you might still want to Do the Right Thing (tm) and draw the characters so they overlay each other exactly … when you have the spare time, of course ;-)
**Attachment 138396**, "A PDF of a PPTX file":
[Schips-Burst_Tries.pdf](/uploads/bbd925d6257162eba79e1f29c8f2871c/Schips-Burst_Tries.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/581Web browsers displays artifacts for svg images generated from pdf documents2018-08-21T11:14:55ZBugzilla Migration UserWeb browsers displays artifacts for svg images generated from pdf documents## Submitted by Alex
Assigned to **poppler-bugs**
**[Link to original bug (#103296)](https://bugs.freedesktop.org/show_bug.cgi?id=103296)**
## Description
Created attachment 134865
original pdf file
After converting some pdf docu...## Submitted by Alex
Assigned to **poppler-bugs**
**[Link to original bug (#103296)](https://bugs.freedesktop.org/show_bug.cgi?id=103296)**
## Description
Created attachment 134865
original pdf file
After converting some pdf documents to svg images by pdftocairo all web browsers (at least Firefox 56.0, Safari 11.0, Chrome 61.0.3163.100 in MAC OSX) show artifacts on images.
To reproduce the issue make the following steps:
- convert the attached pdf to SVG:
pdftocairo -svg -f 1 -l 1 err-doc-5.pdf err-doc-5.svg
- open the SVG image by any mentioned web browser and check how it looks. It expects no any artifacts on the image but it contains black rectangles. Researching the SVG content showed that these elements have the following structure:
<path xmlns="http://www.w3.org/2000/svg" style=" stroke:none;fill-rule:evenodd;fill:rgb(0%,0%,0%);fill-opacity:1;" d="M 394.175781 101.183594 L 570.613281 102.773438 L 571.117188 40 L 394.679688 38.410156 Z M 394.175781 101.183594 "/>
This issue has been tested with latest poppler versions 0.60 and 0.60.1. Previous versions of pdftocairo also contain this problem.
PS: here is the environment info on my Ubuntu 14.04 after running "cmake .."
-- checking for module 'nss>=3.19'
-- package 'nss>=3.19' not found
-- Could NOT find NSS3 (missing: NSS3_LIBRARIES NSS3_CFLAGS)
-- Found Qt-Version 4.8.6 (using /usr/bin/qmake)
-- checking for modules 'glib-2.0>=2.41;gobject-2.0>=2.41;gio-2.0>=2.41'
-- package 'glib-2.0>=2.41' not found
-- package 'gobject-2.0>=2.41' not found
-- package 'gio-2.0>=2.41' not found
-- Could NOT find GLib (missing: GLIB2_LIBRARIES GLIB2_CFLAGS)
-- checking for module 'libopenjp2'
-- package 'libopenjp2' not found
-- Found lcms version 2.05, /usr/lib/x86_64-linux-gnu/liblcms2.so
-- Could NOT find CURL (missing: CURL_LIBRARY CURL_INCLUDE_DIR)
Building Poppler with support for:
font configuration: fontconfig
splash output: yes
cairo output: yes
qt4 wrapper: yes
qt5 wrapper: yes
glib wrapper: no
introspection: no
gtk-doc: no
cpp wrapper: yes
use libjpeg: yes
use libpng: yes
use libtiff: yes
use zlib compress: yes
use zlib uncompress: no
use nss3: no
use curl: no
use libopenjpeg: yes
with openjpeg1
use cms: yes
with lcms2
command line utils: yes
test data dir: /home/alex/poppler/../test
-- Configuring done
**Attachment 134865**, "original pdf file":
[err-doc-5.pdf](/uploads/234fdd9630fcd6c4ba8f68a8f85c7ad5/err-doc-5.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/583Object generation numbers aren't updated (except in the xref table)2018-08-21T11:15:01ZBugzilla Migration UserObject generation numbers aren't updated (except in the xref table)## Submitted by Jakub Alba
Assigned to **poppler-bugs**
**[Link to original bug (#97092)](https://bugs.freedesktop.org/show_bug.cgi?id=97092)**
## Description
If you update an object, its generation number will only be incremented...## Submitted by Jakub Alba
Assigned to **poppler-bugs**
**[Link to original bug (#97092)](https://bugs.freedesktop.org/show_bug.cgi?id=97092)**
## Description
If you update an object, its generation number will only be incremented in the cross-reference table, but e.g. not in the object header or, if it is the "Info" dictionary, in the "Info" entry of the trailer dictionary.
To reproduce this bug, update an object (e.g. modify a single annotation in evince) and use "tail" unix utility with the "-n" option big enough (e.g. 100) to see the object header of the updated object. No matter how many times you update the object, the generation number is still the same. The generation number in the cross-reference table will be updated though.https://gitlab.freedesktop.org/poppler/poppler/-/issues/586Contents of PDF Annotations (Pop-up notes) not output by pdftotext2018-10-06T23:44:47ZBugzilla Migration UserContents of PDF Annotations (Pop-up notes) not output by pdftotext## Submitted by Jeffrey Ratcliffe
Assigned to **poppler-bugs**
**[Link to original bug (#10300)](https://bugs.freedesktop.org/show_bug.cgi?id=10300)**
## Description
PDF can contain annotations (pop-up notes). It would be highly u...## Submitted by Jeffrey Ratcliffe
Assigned to **poppler-bugs**
**[Link to original bug (#10300)](https://bugs.freedesktop.org/show_bug.cgi?id=10300)**
## Description
PDF can contain annotations (pop-up notes). It would be highly useful if their contents were output by pdftotext to allow them to be indexed by
Beagle.
I am the author of gscan2pdf (http://gscan2pdf.sourceforge.net/), an
application to make it easy to scan to a PDF. Having added OCR functionality,
the most obvious way of using the OCR output in the PDF is in an annotation -
thereby having the original scan, and idealy searchable text.https://gitlab.freedesktop.org/poppler/poppler/-/issues/587[pdftotext] rotated text layout breaks output text2018-08-21T11:15:22ZBugzilla Migration User[pdftotext] rotated text layout breaks output text## Submitted by Dm
Assigned to **poppler-bugs**
**[Link to original bug (#92888)](https://bugs.freedesktop.org/show_bug.cgi?id=92888)**
## Description
Created attachment 119537
PDF with watermark
I try to extract text from pdf wi...## Submitted by Dm
Assigned to **poppler-bugs**
**[Link to original bug (#92888)](https://bugs.freedesktop.org/show_bug.cgi?id=92888)**
## Description
Created attachment 119537
PDF with watermark
I try to extract text from pdf with rotated text layout (like watermark). Text from this layout is splitted into parts and that parts break main text.
Example output from the attached pdf:
rm
ar
k
Verdana
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed
...
**Attachment 119537**, "PDF with watermark":
[pdf-example-watermarks.original.pdf](/uploads/3eb6dd8d8cb6d565e71570e4f278878f/pdf-example-watermarks.original.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/588Fail to display pdf2018-10-06T23:47:34ZBugzilla Migration UserFail to display pdf## Submitted by Robert
Assigned to **poppler-bugs**
**[Link to original bug (#105536)](https://bugs.freedesktop.org/show_bug.cgi?id=105536)**
## Description
Evince is having quite some issues regarding displaying fonts in some PDF...## Submitted by Robert
Assigned to **poppler-bugs**
**[Link to original bug (#105536)](https://bugs.freedesktop.org/show_bug.cgi?id=105536)**
## Description
Evince is having quite some issues regarding displaying fonts in some PDFs. I created a bug report here: https://bugzilla.gnome.org/show_bug.cgi?id=794315
but got instructed that this is actually a poppler issue.https://gitlab.freedesktop.org/poppler/poppler/-/issues/589horizontal white lines on the background image2018-08-21T11:15:39ZBugzilla Migration Userhorizontal white lines on the background image## Submitted by Thibaud Lutellier
Assigned to **poppler-bugs**
**[Link to original bug (#97485)](https://bugs.freedesktop.org/show_bug.cgi?id=97485)**
## Description
Created attachment 126040
PDF that triggers the problem (see fir...## Submitted by Thibaud Lutellier
Assigned to **poppler-bugs**
**[Link to original bug (#97485)](https://bugs.freedesktop.org/show_bug.cgi?id=97485)**
## Description
Created attachment 126040
PDF that triggers the problem (see first page)
Summary:
There are some white horizontal lines on the background of the 1st page of the attached PDF file. This is visible with Evince, but not with Okular.
I also get the white lines with pdftocairo (version 0.44.0)
Steps to Reproduce:
Open the file with Evince and look at the first page, or:
1) pdftocairo -singlefile -png 014231.pdf
2) eog 014231.png
Actual Results:
014231.png contains some horizontal white lines.
Expected Results:
The background image should not contains any white lines.
**Attachment 126040**, "PDF that triggers the problem (see first page)":
[014231.pdf](/uploads/43a253fa0fed788c5dadafda16f8b7bc/014231.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/590A picture in the pdf file appears with white lines2018-08-21T11:15:46ZBugzilla Migration UserA picture in the pdf file appears with white lines## Submitted by Germán Poo-Caamaño
Assigned to **poppler-bugs**
**[Link to original bug (#98001)](https://bugs.freedesktop.org/show_bug.cgi?id=98001)**
## Description
As reported in https://bugzilla.gnome.org/show_bug.cgi?id=74541...## Submitted by Germán Poo-Caamaño
Assigned to **poppler-bugs**
**[Link to original bug (#98001)](https://bugs.freedesktop.org/show_bug.cgi?id=98001)**
## Description
As reported in https://bugzilla.gnome.org/show_bug.cgi?id=745411
"
The pdf file was created by an old version of Publisher. It includes pictures and text.
When this file is viewed by acrobat under windows 7, it's OK.
When viewed with Evince 3.14.1 and Gnome 3.14.2 white lines appear on the pictures (and not on the text)."https://gitlab.freedesktop.org/poppler/poppler/-/issues/592PDF shows top ~5% of lines missing2018-08-21T11:15:59ZBugzilla Migration UserPDF shows top ~5% of lines missing## Submitted by Germán Poo-Caamaño
Assigned to **poppler-bugs**
**[Link to original bug (#100866)](https://bugs.freedesktop.org/show_bug.cgi?id=100866)**
## Description
Created attachment 131116
Output of pdftocairo
This bug was ...## Submitted by Germán Poo-Caamaño
Assigned to **poppler-bugs**
**[Link to original bug (#100866)](https://bugs.freedesktop.org/show_bug.cgi?id=100866)**
## Description
Created attachment 131116
Output of pdftocairo
This bug was reported originally in Launchpad and GNOME's bugzilla. In Launchpad was marked as regression.
The problem is reproducible with pdftocairo, but not with pdftoppm.
**Attachment 131116**, "Output of pdftocairo":
![test-01](/uploads/975e7be607a207cff9c1274a8ef68437/test-01.png)
### See also
* [Bug 741704](https://bugzilla.gnome.org/show_bug.cgi?id=741704)
* https://launchpad.net/bugs/1150112https://gitlab.freedesktop.org/poppler/poppler/-/issues/593Incorrect radial shading in cairo output2018-08-21T11:16:04ZBugzilla Migration UserIncorrect radial shading in cairo output## Submitted by Adrian Johnson `@ajohnson`
Assigned to **poppler-bugs**
**[Link to original bug (#40164)](https://bugs.freedesktop.org/show_bug.cgi?id=40164)**
## Description
Created attachment 50304
test case
The attached PDF fi...## Submitted by Adrian Johnson `@ajohnson`
Assigned to **poppler-bugs**
**[Link to original bug (#40164)](https://bugs.freedesktop.org/show_bug.cgi?id=40164)**
## Description
Created attachment 50304
test case
The attached PDF file demonstrates incorrect radial shading colors in the cairo backend. Splash renders this pdf correctly.
**Attachment 50304**, "test case":
[radial.pdf](/uploads/ffa07ba8002b2940eb6e7e8881ced085/radial.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/596PDF reflow2022-06-01T21:02:10ZBugzilla Migration UserPDF reflow## Submitted by D W
Assigned to **poppler-bugs**
**[Link to original bug (#20652)](https://bugs.freedesktop.org/show_bug.cgi?id=20652)**
## Description
I am using pdftohtml to reformat e-books in PDF format for easier reading on h...## Submitted by D W
Assigned to **poppler-bugs**
**[Link to original bug (#20652)](https://bugs.freedesktop.org/show_bug.cgi?id=20652)**
## Description
I am using pdftohtml to reformat e-books in PDF format for easier reading on handheld devices.
The handheld Adobe reader software supports a "reflow" mode in which the PDF text is adjusted to the screen size, just like normal HTML text. In this mode, paragraphs are preserved as paragraphs and the lines wrap at the width of the screen, so it is not necessary to scroll the document or have lines broken in their original spots in the document. Reading documents in reflow mode is a huge improvement, especially on small screens, and it would be an very useful addition to pdftohtml.
I have been testing a patch someone else wrote and posted at
http://lists.freedesktop.org/archives/poppler/2008-September/004126.html
I have been testing it and it works pretty well, although it's not perfect, perhaps it could be applied a first step?https://gitlab.freedesktop.org/poppler/poppler/-/issues/600pdfimages extracts lots of same images with the same object number.2018-10-11T08:57:16ZBugzilla Migration Userpdfimages extracts lots of same images with the same object number.## Submitted by 石印
Assigned to **poppler-bugs**
**[Link to original bug (#99883)](https://bugs.freedesktop.org/show_bug.cgi?id=99883)**
## Description
Created attachment 129787
problem file
I have a pdf file, pdfimages list a lot...## Submitted by 石印
Assigned to **poppler-bugs**
**[Link to original bug (#99883)](https://bugs.freedesktop.org/show_bug.cgi?id=99883)**
## Description
Created attachment 129787
problem file
I have a pdf file, pdfimages list a lot of images with the object number. These images are the same. There are only about a thousand pictures with diffrent object number, but pdfimages list more than 256,000 items. Finally, pdfimages extract all pictures listed and most of them are the same. The total size of all pictures is really huge. I upload the pdf, and my simple patch below ( may not good, but work :D ).
From 237f4e0887eff2f22d5542dfed33fa94a8c7b0ff Mon Sep 17 00:00:00 2001
From: Ryan <ryanorz@126.com>
Date: Tue, 21 Feb 2017 16:11:53 +0800
Subject: [PATCH] Fix(poppler-utils): pdfimages extract too many same pictures
with the same object number.
---
utils/ImageOutputDev.cc | 8 ++++++++
utils/ImageOutputDev.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/utils/ImageOutputDev.cc b/utils/ImageOutputDev.cc
index 5de51ad..26bf95b 100644
--- a/utils/ImageOutputDev.cc
+++ b/utils/ImageOutputDev.cc
@@ -442,6 +442,14 @@ void ImageOutputDev::writeImageFile(ImgWriter *writer, ImageFormat format, const
void ImageOutputDev::writeImage(GfxState *state, Object *ref, Stream *str,
int width, int height,
GfxImageColorMap *colorMap, GBool inlineImg) {
+ if (ref->isRef()) {
+ const Ref imageRef = ref->getRef();
+ if (refNums.find(imageRef.num) != refNums.end())
+ return;
+ else
+ refNums.insert(imageRef.num);
+ }
+
ImageFormat format;
if (dumpJPEG && str->getKind() == strDCT &&
diff --git a/utils/ImageOutputDev.h b/utils/ImageOutputDev.h
index a694bbc..89c67ac 100644
--- a/utils/ImageOutputDev.h
+++ b/utils/ImageOutputDev.h
@@ -35,6 +35,7 @@
#endif
#include <stdio.h>
+#include `<set>`
#include "goo/gtypes.h"
#include "goo/ImgWriter.h"
#include "OutputDev.h"
@@ -173,6 +174,7 @@ private:
int pageNum; // current page number
int imgNum; // current image number
GBool ok; // set up ok?
+ std::set`<int>` refNums;
};
#endif
--
2.10.2
**Attachment 129787**, "problem file":
[Linuxå__æ__å__å__æ__é___ä__æ__ç__v3.0_.pdf](/uploads/6679256d9842f8e250fbf39d91064ce1/Linuxå__æ__å__å__æ__é___ä__æ__ç__v3.0_.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/601Character names with glyph variants2018-10-27T15:16:37ZBugzilla Migration UserCharacter names with glyph variants## Submitted by Ed Catmur
Assigned to **poppler-bugs**
**[Link to original bug (#9128)](https://bugs.freedesktop.org/show_bug.cgi?id=9128)**
## Description
We should be able to handle character names that name glyph variants (e.g....## Submitted by Ed Catmur
Assigned to **poppler-bugs**
**[Link to original bug (#9128)](https://bugs.freedesktop.org/show_bug.cgi?id=9128)**
## Description
We should be able to handle character names that name glyph variants (e.g.
P.swash for swash capital P, 7.oldstyle for text figures). These should be
handled as the base character when converting to Unicode.
See [bug 8986](https://bugs.freedesktop.org/show_bug.cgi?id=8986) for patch.https://gitlab.freedesktop.org/poppler/poppler/-/issues/602pdftops incorrectly renders Bézier curves when part of closed paths2018-10-26T15:23:38ZBugzilla Migration Userpdftops incorrectly renders Bézier curves when part of closed paths## Submitted by cfr
Assigned to **poppler-bugs**
**[Link to original bug (#87254)](https://bugs.freedesktop.org/show_bug.cgi?id=87254)**
## Description
Created attachment 110766
Original PDF with curves which are part of closed pa...## Submitted by cfr
Assigned to **poppler-bugs**
**[Link to original bug (#87254)](https://bugs.freedesktop.org/show_bug.cgi?id=87254)**
## Description
Created attachment 110766
Original PDF with curves which are part of closed paths (top 3) or not (bottom 2)
When Bézier curves are part of closed paths, pdftops renders them as rectangles.
Attached: original PDF which includes sample curves. Top three are part of closed paths. Bottom two are part of open paths. When pdftops is applied to this file, the top three paths are rendered as rectangles, while the bottom two render fine.
If I can attach a second file in a moment, I will also attach the PS output.
The problem can be demonstrated by viewing the resulting postscript in Okular (with the ghostscript backend), Evince, gv and when printing.
For comparison, pdf2ps (ghostscript) renders the curves correctly.
[Initial description of the problem as a query about a LaTeX package at http://tex.stackexchange.com/questions/217562/why-do-tikz-b%C3%A9zier-curves-print-as-rectangles-when-part-of-a-closed-path.]
**Attachment 110766**, "Original PDF with curves which are part of closed paths (top 3) or not (bottom 2)":
[poss-bug-orig.pdf](/uploads/6b555fee653c3c7d8f663662664ed80c/poss-bug-orig.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/603pdfseparate+pdftoppm renders different than original file2018-10-26T15:23:58ZBugzilla Migration Userpdfseparate+pdftoppm renders different than original file## Submitted by Albert Astals Cid
Assigned to **poppler-bugs**
**[Link to original bug (#87637)](https://bugs.freedesktop.org/show_bug.cgi?id=87637)**
## Description
Created attachment 111220
The said file
With the attached file,...## Submitted by Albert Astals Cid
Assigned to **poppler-bugs**
**[Link to original bug (#87637)](https://bugs.freedesktop.org/show_bug.cgi?id=87637)**
## Description
Created attachment 111220
The said file
With the attached file, if you split it with pdfseparate, the file that represents the third page will have an extra square on the top right part of the page when rendered with pdftoppm that is not there if you render the third page of the original file.
~~**Attachment 111220**~~, "The said file":
[bug161327-2.pdf](/uploads/a3b050de8cd6b85a448bf7d5708949f0/bug161327-2.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/604pdftops loses grid lines CancelOk2018-10-26T15:22:06ZBugzilla Migration Userpdftops loses grid lines CancelOk## Submitted by komputes
Assigned to **poppler-bugs**
**[Link to original bug (#29060)](https://bugs.freedesktop.org/show_bug.cgi?id=29060)**
## Description
The following bug is being reported upstream on behalf of the OP.
Origina...## Submitted by komputes
Assigned to **poppler-bugs**
**[Link to original bug (#29060)](https://bugs.freedesktop.org/show_bug.cgi?id=29060)**
## Description
The following bug is being reported upstream on behalf of the OP.
Originally posted here: https://bugs.launchpad.net/bugs/604724
We discovered that cups in lucid does not correctly print certain PDFs when printing from the command line with lpr or as a shared printer from preview in OS X. The same file prints correctly with cups on hardy. This issue occurs with a variety of different printers.
I tracked down the problem to /usr/bin/pdftops by running the pdf through the filters that cups does according to the log. /usr/bin/pdftops is called by the cpdftocps filter.
This pdftops is installed from poppler-utils:
$dpkg-query -S /usr/bin/pdftops
poppler-utils: /usr/bin/pdftops
After running the pdf through each step of the filter, I opened it with evince. After running through pdftops, evince showed exactly what I see when I print the file.
Interestingly, if I print from evince or acroread, all the lines are printed correctly. I think they are converting the file to postscript themselves before sending it to cups.
I will attach the file that shows this behavior.
The pdftops provided by the cups package does not exhibit this problem.
$ dpkg-query -S /usr/lib/cups/filter/pdftops
cups: /usr/lib/cups/filter/pdftops
ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: poppler-utils 0.12.4-0ubuntu5
ProcVersionSignature: Ubuntu 2.6.32-23.37-generic 2.6.32.15+drm33.5
Uname: Linux 2.6.32-23-generic x86_64
Architecture: amd64
Date: Mon Jul 12 12:33:43 2010
ProcEnviron:
LANGUAGE=
PATH=(custom, user)
LANG=en_US.utf8
SHELL=/bin/bash
SourcePackage: popplerhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/605Emit more font information when pdftohtml is run with -xml2018-10-08T10:29:17ZBugzilla Migration UserEmit more font information when pdftohtml is run with -xml## Submitted by ulatekh
Assigned to **poppler-bugs**
**[Link to original bug (#107318)](https://bugs.freedesktop.org/show_bug.cgi?id=107318)**
## Description
Created attachment 140750
Patch to add functionality
I'm about to use p...## Submitted by ulatekh
Assigned to **poppler-bugs**
**[Link to original bug (#107318)](https://bugs.freedesktop.org/show_bug.cgi?id=107318)**
## Description
Created attachment 140750
Patch to add functionality
I'm about to use pdftohtml to extract information from PDFs and organize the results into a database, so I had a chance to dig through the code.
The patch merely emits more information in the `<fontspec>` elements when pdftohtml is run with -xml. The PDFs I'm trying to analyze appear to be pretty consistent with their font usage, to the point where I can use them to infer the text's meaning. But I needed more information in the `<fontspec>` to do that, and this patch does that for me.
**Patch 140750**, "Patch to add functionality":
[0003-Emit-more-font-information-when-pdftohtml-is-run-wit.patch](/uploads/e83dddb5b7bcc5b092b27490b87fe8e4/0003-Emit-more-font-information-when-pdftohtml-is-run-wit.patch)https://gitlab.freedesktop.org/poppler/poppler/-/issues/606Rendered output is currently restricted to 8 bit/channel2018-08-21T11:17:49ZBugzilla Migration UserRendered output is currently restricted to 8 bit/channel## Submitted by Hal Engel
Assigned to **poppler-bugs**
**[Link to original bug (#34055)](https://bugs.freedesktop.org/show_bug.cgi?id=34055)**
## Description
All color transforms currently restrict output to 8 bits/channel because...## Submitted by Hal Engel
Assigned to **poppler-bugs**
**[Link to original bug (#34055)](https://bugs.freedesktop.org/show_bug.cgi?id=34055)**
## Description
All color transforms currently restrict output to 8 bits/channel because this is hard coded. This is probably acceptable for monitor output although with display port we are starting to see monitors that support higher bit depths (10 and 12 bits/channel currently but display port allows for up to 16 bits/channel).
The CUPS pdftoraster filter will need the ability to set the bit depth to either 8 or 16 bits/channel but a more general solution would allow the calling app to set any output format that is supported by the CMS including floating point formats. So this will likely require adding the ability to set this to the poppler API.https://gitlab.freedesktop.org/poppler/poppler/-/issues/608pdfimages adds a superfluous 0.5 to image ppi shown using -list (patch provided)2018-10-11T08:20:10ZBugzilla Migration Userpdfimages adds a superfluous 0.5 to image ppi shown using -list (patch provided)## Submitted by fre..@..et.com
Assigned to **poppler-bugs**
**[Link to original bug (#104861)](https://bugs.freedesktop.org/show_bug.cgi?id=104861)**
## Description
Adding 0.5 to a double before formatting with "%5.0f" results in ...## Submitted by fre..@..et.com
Assigned to **poppler-bugs**
**[Link to original bug (#104861)](https://bugs.freedesktop.org/show_bug.cgi?id=104861)**
## Description
Adding 0.5 to a double before formatting with "%5.0f" results in a rounding error. Presumably it was originally done before truncating to int.
--- utils/ImageOutputDev.cc.old 2018-01-30 16:38:42.179170000 +0200
+++ utils/ImageOutputDev.cc 2018-01-30 16:39:13.506750000 +0200
@@ -234,13 +234,13 @@
double *mat = state->getCTM();
double width2 = mat[0] + mat[2];
double height2 = mat[1] + mat[3];
- double xppi = fabs(width*72.0/width2) + 0.5;
- double yppi = fabs(height*72.0/height2) + 0.5;
+ double xppi = fabs(width*72.0/width2);
+ double yppi = fabs(height*72.0/height2);
if (xppi < 1.0)
printf("%5.3f ", xppi);
else
printf("%5.0f ", xppi);
if (yppi < 1.0)
printf("%5.3f ", yppi);
else
printf("%5.0f ", yppi);https://gitlab.freedesktop.org/poppler/poppler/-/issues/609Incorrect rendering on Evince2018-10-06T23:42:54ZBugzilla Migration UserIncorrect rendering on Evince## Submitted by Rodrigo E. De León Plicet
Assigned to **poppler-bugs**
**[Link to original bug (#26392)](https://bugs.freedesktop.org/show_bug.cgi?id=26392)**
## Description
Created attachment 33008
Original ODT and PDF; screensho...## Submitted by Rodrigo E. De León Plicet
Assigned to **poppler-bugs**
**[Link to original bug (#26392)](https://bugs.freedesktop.org/show_bug.cgi?id=26392)**
## Description
Created attachment 33008
Original ODT and PDF; screenshots showing rendering on OO.o, evince and acroread
On the attached ZIP file, you'll find:
- The original ODT.
- OO.o-exported PDF
- Screenshots showing:
- How the ODT renders on-screen (OO.o)
- How the PDF renders on-screen (evince, acroread)
- OO.o and acroread render the doc as it should be, evince doesn't.
**Attachment 33008**, "Original ODT and PDF; screenshots showing rendering on OO.o, evince and acroread":
[poppler-bug.zip](/uploads/da8f05528b33bab01fddcd6d81aa5246/poppler-bug.zip)https://gitlab.freedesktop.org/poppler/poppler/-/issues/610Two adjacent filled rectangles of the same colour have a line between at cert...2018-10-06T23:43:08ZBugzilla Migration UserTwo adjacent filled rectangles of the same colour have a line between at certain zoom levels## Submitted by Deri James
Assigned to **poppler-bugs**
**[Link to original bug (#26261)](https://bugs.freedesktop.org/show_bug.cgi?id=26261)**
## Description
Created attachment 32838
PDF showing adjacent squares
The attached pdf...## Submitted by Deri James
Assigned to **poppler-bugs**
**[Link to original bug (#26261)](https://bugs.freedesktop.org/show_bug.cgi?id=26261)**
## Description
Created attachment 32838
PDF showing adjacent squares
The attached pdf illustrates the problem. View it with okular or evince and you will see a line appear between the squares at certain zoom levels (i.e. 60% in okular).
There are 3 examples in the PDF:
A) Two filled squares on a black background (the line is dark red)
B) Two filled squares on white background (the line is pink)
It seems the line is produced by antialiasing not taking into account adjacent objects, just the background.
C) These two squares are produced using both fill & stroke (with a stroke width of zero). The separating line does not appear (at any zoom level) and the amount of antialiasing is 50% of what it was.
**Attachment 32838**, "PDF showing adjacent squares":
[poppler-bug-u2.pdf](/uploads/b2818b093a01e5763671273867f8a8b1/poppler-bug-u2.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/612get_text_layout introspection mismatch2018-08-21T11:18:10ZBugzilla Migration Userget_text_layout introspection mismatch## Submitted by Marcus Brinkmann
Assigned to **poppler-bugs**
**[Link to original bug (#77790)](https://bugs.freedesktop.org/show_bug.cgi?id=77790)**
## Description
Hi,
$ cat girtest.js
const pop = imports.gi.Poppler;
const doc =...## Submitted by Marcus Brinkmann
Assigned to **poppler-bugs**
**[Link to original bug (#77790)](https://bugs.freedesktop.org/show_bug.cgi?id=77790)**
## Description
Hi,
$ cat girtest.js
const pop = imports.gi.Poppler;
const doc = pop.Document.new_from_file("file:///path/to/test.pdf", '')
const page=doc.get_page(0)
log(page.get_text_layout())
$ gjs girtest.js
Segmentation fault (core dumped)
Backtrace follows below. What actually happens is that gir expects get_text_layout to return an array of PopplerRectangle* (an array of pointers to allocated PopplerRectangle objects), while it actually returns an array of PopplerRectangle (one continuous malloc region with all rectangles side-by-side).
The confusion occurs naturally in C, as the type "Foo*" can be a pointer to a single Foo object, or an array of Foo objects.
From a cursory glance at gir, it seems the actual data layout currently implemented is not supported by gir, and that the PopplerRectangles have to be allocated separately. This would be an API change.
If one tries to trick gir and change the header file to a PopplerRectangle* (instead of the **), one gets:
$ gjs girtest.js
(gjs:20441): Gjs-WARNING **: JS ERROR: Error: Unsupported type array for (out caller-allocates)
@girtest.js:4
JS_EvaluateScript() failed
Here is the backtrace:
```
(gdb) bt
#0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:37
#1 0x00007ffff69393a7 in g_slice_copy (mem_size=32, mem_block=0x40519322d0e56042) at gslice.c:1056
#2 0x00007ffff6c166d3 in g_boxed_copy (boxed_type=8036912, src_boxed=0x40519322d0e56042) at gboxed.c:352
#3 0x00007ffff7d9cf54 in gjs_boxed_from_c_struct (context=0x636ff0, info=<optimized out>, gboxed=0x40519322d0e56042, flags=<optimized out>) at gi/boxed.cpp:1236
#4 0x00007ffff7d99d43 in gjs_value_from_g_argument (context=context@entry=0x636ff0, value_p=value_p@entry=0x7fffffffc500, type_info=type_info@entry=0x72aa30,
arg=arg@entry=0x7fffffffc510, copy_structs=copy_structs@entry=1) at gi/arg.cpp:2642
#5 0x00007ffff7d9a1fb in gjs_array_from_carray_internal (context=context@entry=0x636ff0, value_p=value_p@entry=0x7fffffffc5c8, param_info=param_info@entry=0x72aa30,
length=length@entry=483, array=<optimized out>) at gi/arg.cpp:2143
#6 0x00007ffff7d9a695 in gjs_value_from_explicit_array (context=0x636ff0, value_p=0x7fffffffc5c8, type_info=<optimized out>, arg=0x7fffffffc618, length=483)
at gi/arg.cpp:2195
#7 0x00007ffff7d9fe03 in gjs_invoke_c_function (context=context@entry=0x636ff0, function=function@entry=0x6d0de0, obj=obj@entry=0x7fffee735cd0, js_argc=js_argc@entry=0,
js_argv=js_argv@entry=0x68e508, js_rval=js_rval@entry=0x7fffffffc970, r_value=r_value@entry=0x0) at gi/function.cpp:1140
```