poppler issueshttps://gitlab.freedesktop.org/poppler/poppler/-/issues2019-10-14T20:55:25Zhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/290printing entries from the Viewer Preferences dictionary2019-10-14T20:55:25ZBugzilla Migration Userprinting entries from the Viewer Preferences dictionary## Submitted by Pablo Rodríguez `@ousia`
Assigned to **poppler-bugs**
**[Link to original bug (#92779)](https://bugs.freedesktop.org/show_bug.cgi?id=92779)**
## Description
Pages 364 and 365 from the PDF specification
(https://www...## Submitted by Pablo Rodríguez `@ousia`
Assigned to **poppler-bugs**
**[Link to original bug (#92779)](https://bugs.freedesktop.org/show_bug.cgi?id=92779)**
## Description
Pages 364 and 365 from the PDF specification
(https://wwwimages2.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf#page=364)
contain some entries in the viewer dictonary that set up printing
options from the PDF file itself.
The main entries and their values are:
/PrintScaling /AppDefault or /None.
/Duplex /Simplex (required when printer’s default is double-sided
/DuplexFlipShortEdge (double-sided for landscape)
/DuplexFlipLongEdge (double-sided for portrait)
/PickTrayByPDFSize boolean (evince implements it as "Select page size using document page size)
/NumCopies integer (the specification points the number allowed in the printing dialog, but Adobe allows up to 5).
evince enables all these features in the printing dialog. But it cannot read them from the PDF file.
Could you implement them in poppler?https://gitlab.freedesktop.org/poppler/poppler/-/issues/289Configurable background color for converted PDFs using pdftohtml2018-10-07T00:34:41ZBugzilla Migration UserConfigurable background color for converted PDFs using pdftohtml## Submitted by Jeremy Maness
Assigned to **poppler-bugs**
**[Link to original bug (#20379)](https://bugs.freedesktop.org/show_bug.cgi?id=20379)**
## Description
Currently, the background color for converted PDFs using pdftohtml i...## Submitted by Jeremy Maness
Assigned to **poppler-bugs**
**[Link to original bug (#20379)](https://bugs.freedesktop.org/show_bug.cgi?id=20379)**
## Description
Currently, the background color for converted PDFs using pdftohtml is always #A0A0A0.
See:
- when using the frames option (see http://cgit.freedesktop.org/poppler/poppler/tree/utils/HtmlOutputDev.cc line 713)
- when using the noframes option (see http://cgit.freedesktop.org/poppler/poppler/tree/utils/HtmlOutputDev.cc line 1019)
Will you please make the background color configurable or possibly link the HTML document to a CSS stylesheet?https://gitlab.freedesktop.org/poppler/poppler/-/issues/288Evince ignores font hinting settings2018-08-21T10:36:53ZBugzilla Migration UserEvince ignores font hinting settings## Submitted by Sebastien Bacher
Assigned to **poppler-bugs**
**[Link to original bug (#10218)](https://bugs.freedesktop.org/show_bug.cgi?id=10218)**
## Description
That bug has been opened on https://launchpad.net/ubuntu/+source/...## Submitted by Sebastien Bacher
Assigned to **poppler-bugs**
**[Link to original bug (#10218)](https://bugs.freedesktop.org/show_bug.cgi?id=10218)**
## Description
That bug has been opened on https://launchpad.net/ubuntu/+source/evince/+bug/87230
"Binary package hint: evince
I specifically set my system to disable font hinting because I prefer the appearance.
However, Evince still insists on using hinting when rendering. As a result, I get particularly bad (worse than normal) text rendering with all documents. See attached screenshot for example.
Zooming in and out causes apparent font weight to increase and decrease by massive amounts. Worse still is that italicized text at the same zoom level appears thinner for Times New Roman. See screenshot for example. Notice also under point 4 the italic "zero" has its diagonal bar in the "z" missing. This is just another issue with font hinting, but illustrates the problem well.
...
http://librarian.launchpad.net/6512242/hinting.png
Screenshot"https://gitlab.freedesktop.org/poppler/poppler/-/issues/287Evince shows strange characters instead latin letters2018-10-26T15:20:32ZBugzilla Migration UserEvince shows strange characters instead latin letters## Submitted by Filipy
Assigned to **poppler-bugs**
**[Link to original bug (#94285)](https://bugs.freedesktop.org/show_bug.cgi?id=94285)**
## Description
Created attachment 121954
How the same file is shown on Evince (left) and F...## Submitted by Filipy
Assigned to **poppler-bugs**
**[Link to original bug (#94285)](https://bugs.freedesktop.org/show_bug.cgi?id=94285)**
## Description
Created attachment 121954
How the same file is shown on Evince (left) and Firefox (right)
Hello there,
I first reported it to Evince developers, but they said it is a Poppler specific problem and must be reported here.
So, I received by email a link to download the file wich is a pass to a rock show.
I opened it with Evince and couldn't read the content, the text was shown as strange characters. Since I don't have another PDF reader, I tried open it with Firefox (built-in PDF reader) and it shows the text correct.
The PDF file can be downloaded here: http://www.rockbones.com.br/?download_ticket=1416&order_key=1454909264&download_ticket_nonce=de41ca04e0
I'm on Arch Linux, with Evince version 3.18.2 and poppler 0.40.0.
Regards.
**Attachment 121954**, "How the same file is shown on Evince (left) and Firefox (right)":
![rockpass](/uploads/aacfcb85c59b94a8a27b83835ff0586e/rockpass.png)https://gitlab.freedesktop.org/poppler/poppler/-/issues/286white lines an colored background (in exported pdf from OO with image „Verank...2018-08-21T10:36:40ZBugzilla Migration Userwhite lines an colored background (in exported pdf from OO with image „Verankerung am Absatz“)## Submitted by Werner Meyer
Assigned to **poppler-bugs**
**[Link to original bug (#32974)](https://bugs.freedesktop.org/show_bug.cgi?id=32974)**
## Description
See
http://www.openoffice.org/issues/show_bug.cgi?id=116069
okular ...## Submitted by Werner Meyer
Assigned to **poppler-bugs**
**[Link to original bug (#32974)](https://bugs.freedesktop.org/show_bug.cgi?id=32974)**
## Description
See
http://www.openoffice.org/issues/show_bug.cgi?id=116069
okular says it's a poppler-bug.
Reproducible: Always
(using okular in gnome in opensuse)https://gitlab.freedesktop.org/poppler/poppler/-/issues/285splash slower than cairo at rendering a pdf2018-08-31T14:06:25ZBugzilla Migration Usersplash slower than cairo at rendering a pdf## Submitted by Kevin
Assigned to **poppler-bugs**
**[Link to original bug (#105827)](https://bugs.freedesktop.org/show_bug.cgi?id=105827)**
## Description
Okular renders some pdfs much slower than Evince, even though both use Pop...## Submitted by Kevin
Assigned to **poppler-bugs**
**[Link to original bug (#105827)](https://bugs.freedesktop.org/show_bug.cgi?id=105827)**
## Description
Okular renders some pdfs much slower than Evince, even though both use Poppler for the pdf backend. Apparently, this is because Evince uses the cairo backend of Poppler, while Okular must use splash.
For example, the second page of this pdf
https://arxiv.org/pdf/1701.07837v2
takes over 3 seconds for Okular to render. However, Evince renders it almost instantly.
Or when quickly scrolling through a large pdf, Evince seems to render the pages almost instantly, while Okular renders slower than I can (quickly) scroll. Here is an example large pdf:
https://arxiv.org/pdf/1508.02595v4
I'm using Okular 1.3.3, Evince 3.26.0, and poppler 0.61.1 on Archlinux (with an Intel i7-3720QM @ 2.6GHz).
I initially submitted this bug at
https://bugs.kde.org/show_bug.cgi?id=391972
bug was asked to submit it here instead. I apologize if this bug is considered to be a duplicate of some similar bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=23991
https://bugs.freedesktop.org/show_bug.cgi?id=78728
https://bugs.freedesktop.org/show_bug.cgi?id=81211https://gitlab.freedesktop.org/poppler/poppler/-/issues/284Letters in auto-font-size PDF form fields get cut off2018-08-21T10:36:27ZBugzilla Migration UserLetters in auto-font-size PDF form fields get cut off## Submitted by Jose Aliste
Assigned to **poppler-bugs**
**[Link to original bug (#60836)](https://bugs.freedesktop.org/show_bug.cgi?id=60836)**
## Description
Created attachment 74805
test case
From GNOME's bugzilla.
"When fil...## Submitted by Jose Aliste
Assigned to **poppler-bugs**
**[Link to original bug (#60836)](https://bugs.freedesktop.org/show_bug.cgi?id=60836)**
## Description
Created attachment 74805
test case
From GNOME's bugzilla.
"When filling a PDF form with fields that are set to auto-size the fonts to make
them fit the box evince cuts the letters by the base-line. This makes letters
like y, g and j get cut off. The proper behaviour should be to resize the font
in a manner that lets both ends of the most protuding letters fit at all times.
View the attached screenshot and pdf."
**Attachment 74805**, "test case":
[auto-font-size.zip](/uploads/cfcc9ecf06f7053df7182aea91dd63d8/auto-font-size.zip)https://gitlab.freedesktop.org/poppler/poppler/-/issues/283poppler: file parsing infinite loop encountered with docs containing image ma...2018-10-05T23:24:01ZBugzilla Migration Userpoppler: file parsing infinite loop encountered with docs containing image masks (sample attached)## Submitted by Ed Porras
Assigned to **poppler-bugs**
**[Link to original bug (#63088)](https://bugs.freedesktop.org/show_bug.cgi?id=63088)**
## Description
Created attachment 77390
Sample document containing Image Mask causing p...## Submitted by Ed Porras
Assigned to **poppler-bugs**
**[Link to original bug (#63088)](https://bugs.freedesktop.org/show_bug.cgi?id=63088)**
## Description
Created attachment 77390
Sample document containing Image Mask causing poppler to get stuck in an infinite loop
We are working on an internal tool that uses poppler for PDF processing and have encountered a handful of documents that cause the poppler core to enter an infinite loop. I've looked at a couple of them and it looks to be something related to the parsing of image masks. This is happening both under linux and OS X, linked against poppler 0.22.2.
I've confirmed the bug is in poppler and not our application as it is also seen with pdftohtml. Enabling PrintCommands produces output that doesn't take long for it to show the problem:
…
re 661.08 456.362 609.48 -104.88
f
cs /Cs6
scn 1 1 1
gs /GS1
gfx state dict: << /SA false /SM 0.02 /Type /ExtGState >>
re 0 1 1 -1
f
scn 0.8 0.8 0.8
q
cm 1 0 0 -1 0 1
Do /Im1
Q
cs /Cs6
scn 1 1 1
gs /GS1
gfx state dict: << /SA false /SM 0.02 /Type /ExtGState >>
re 0 1 1 -1
f
scn 0.8 0.8 0.8
q
cm 1 0 0 -1 0 1
Do /Im1
Q
cs /Cs6
scn 1 1 1
gs /GS1
gfx state dict: << /SA false /SM 0.02 /Type /ExtGState >>
…
If I had to guess, an offset is not getting applied resulting in the same object getting returned. I realize there is a repeated graphic on the page but by the time I killed pdftohtml (< 30s from starting it), there were around 140k instances of the PNG written to disk and I'm pretty sure that can't be right :)
I've extracted a single page of one that shows the issue and have attached it. Please note that running it on the file will quickly create thousands of small 8x8 PNGs about 100 bytes in size.
There are two similar issues reported but they date back to 2010 and are marked resolved so I'm not confident it is the same problem:
https://bugs.freedesktop.org/show_bug.cgi?id=28784
https://bugs.freedesktop.org/show_bug.cgi?id=28172
In the meantime, I'm trying to trace through the code to try and get an understanding but I'm very unfamiliar with the Parser/Lexer portion of the poppler core. Hope you can help and let me know if there's any other way I can assist.
Thank you.
**Attachment 77390**, "Sample document containing Image Mask causing poppler to get stuck in an infinite loop":
[02fa51062afad2f4ddaf38141ef6aa70_1.pdf](/uploads/52ed68f456a587217524902b4d3dbbe5/02fa51062afad2f4ddaf38141ef6aa70_1.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/282Sharper scaling at lower zoom level2018-08-21T10:36:12ZBugzilla Migration UserSharper scaling at lower zoom level## Submitted by Marcin
Assigned to **poppler-bugs**
**[Link to original bug (#29727)](https://bugs.freedesktop.org/show_bug.cgi?id=29727)**
## Description
At lower zoom the downscale image is too blurred especially with
black-whit...## Submitted by Marcin
Assigned to **poppler-bugs**
**[Link to original bug (#29727)](https://bugs.freedesktop.org/show_bug.cgi?id=29727)**
## Description
At lower zoom the downscale image is too blurred especially with
black-white text scans. To see the difference I attach a patch
that change the filter at downscale to NEAREST.https://gitlab.freedesktop.org/poppler/poppler/-/issues/279Horizontal lines are displayed and printed too thin2018-08-21T10:35:57ZBugzilla Migration UserHorizontal lines are displayed and printed too thin## Submitted by Pedro Villavicencio
Assigned to **poppler-bugs**
**[Link to original bug (#20714)](https://bugs.freedesktop.org/show_bug.cgi?id=20714)**
## Description
this report has been filed here:
https://bugs.edge.launchpad....## Submitted by Pedro Villavicencio
Assigned to **poppler-bugs**
**[Link to original bug (#20714)](https://bugs.freedesktop.org/show_bug.cgi?id=20714)**
## Description
this report has been filed here:
https://bugs.edge.launchpad.net/ubuntu/+source/poppler/+bug/247113
"If you create sheet music with Lilypond the vertical bars are too thick in Evince. Especially the bars are much more thicker when you print it and thats what you normally do with sheet music. If you print the same PDF (created by Lilypond) with Acrobat Reader the bars are correct.
I added a sample Lilypond file and the corresponding PDF file. To reproduce it, print it with Acrobat Reader and then with Evince and you will see the difference. I have also added a screenshot with both applications zoomed in. The difference in the screenshots are marginal, but the difference in the hardcopy are huge."
http://launchpadlibrarian.net/15924702/sample.ly
http://launchpadlibrarian.net/15924704/sample.pdf
screenshot:
http://launchpadlibrarian.net/15924716/comparison.png
thanks in advance,https://gitlab.freedesktop.org/poppler/poppler/-/issues/277Pdf text buffer rendered in the wrong order2018-08-21T10:35:45ZBugzilla Migration UserPdf text buffer rendered in the wrong order## Submitted by Max Nicosia
Assigned to **poppler-bugs**
**[Link to original bug (#29374)](https://bugs.freedesktop.org/show_bug.cgi?id=29374)**
## Description
The text although display in the right order, cannot be selected in th...## Submitted by Max Nicosia
Assigned to **poppler-bugs**
**[Link to original bug (#29374)](https://bugs.freedesktop.org/show_bug.cgi?id=29374)**
## Description
The text although display in the right order, cannot be selected in the correct order.
In the following pdf:
www.cs.st-andrews.ac.uk/~mirco/papers/simplex10.pdf
On the second page, the selection (under Evince) goes in the following order:
upper left -> upper right -> lower left -> lover right
Now, this might not seem a serious problem, but it hinders the use of Orca with Evince to read pdfs, since the text is read in the wrong order.
There is also another example here: (not quite the same)
www.cs.st-andrews.ac.uk/~mirco/papers/wosn10.pdf
On the first page, the names of the authors are read and can be selected as if they would be in columns, but the text is put on the buffer in lines.
I could provide further info if necessary.
Cheers
Mhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/276[PATCH] add text hinting setting to the qt demos2018-08-21T10:35:42ZBugzilla Migration User[PATCH] add text hinting setting to the qt demos## Submitted by Philipp Knechtges
Assigned to **poppler-bugs**
**[Link to original bug (#91915)](https://bugs.freedesktop.org/show_bug.cgi?id=91915)**
## Description
Created attachment 118133
patch
Allows to select the different ...## Submitted by Philipp Knechtges
Assigned to **poppler-bugs**
**[Link to original bug (#91915)](https://bugs.freedesktop.org/show_bug.cgi?id=91915)**
## Description
Created attachment 118133
patch
Allows to select the different text hinting options in the qt{4,5} demos.
Interestingly, the output from qt4 does not necessarily match the qt5 output. Text hinting with qt5 seems to be more subtle without antialiasing.
~~**Attachment 118133**~~, "patch":
[0001-qt-4-5-demos-add-text-hinting-setting.patch](/uploads/a32ed05ac17fc22685e0447c5a199250/0001-qt-4-5-demos-add-text-hinting-setting.patch)https://gitlab.freedesktop.org/poppler/poppler/-/issues/275[TAGGEDPDF] Provide accessors for form field of structure elements2018-08-21T10:35:35ZBugzilla Migration User[TAGGEDPDF] Provide accessors for form field of structure elements## Submitted by Alejandro Piñeiro `@apinheiro`
Assigned to **poppler-bugs**
**[Link to original bug (#80154)](https://bugs.freedesktop.org/show_bug.cgi?id=80154)**
## Description
[Bug 64821](https://bugs.freedesktop.org/show_bug.c...## Submitted by Alejandro Piñeiro `@apinheiro`
Assigned to **poppler-bugs**
**[Link to original bug (#80154)](https://bugs.freedesktop.org/show_bug.cgi?id=80154)**
## Description
[Bug 64821](https://bugs.freedesktop.org/show_bug.cgi?id=64821) was closed with the patches related to form field accessors not committed. At [bug 64821](https://bugs.freedesktop.org/show_bug.cgi?id=64821) comment 81 it is suggested to create a new bug for that.
### Blocking
* [Bug 64813](https://bugs.freedesktop.org/show_bug.cgi?id=64813)
* [Bug 80159](https://bugs.freedesktop.org/show_bug.cgi?id=80159)https://gitlab.freedesktop.org/poppler/poppler/-/issues/274RTL select, copy/paste and search support for Arabic and Hebrew scripts are m...2018-10-27T15:16:57ZBugzilla Migration UserRTL select, copy/paste and search support for Arabic and Hebrew scripts are missing## Submitted by Bryan Clark
Assigned to **poppler-bugs**
**[Link to original bug (#2981)](https://bugs.freedesktop.org/show_bug.cgi?id=2981)**
## Description
I know it's very complicated, but many times we need to search for just ...## Submitted by Bryan Clark
Assigned to **poppler-bugs**
**[Link to original bug (#2981)](https://bugs.freedesktop.org/show_bug.cgi?id=2981)**
## Description
I know it's very complicated, but many times we need to search for just a word
in a pdf/ps and we cann't.
As I know, no viewer support RtL scripts yet.
------- From Behdad Esfahbod 2005-03-15 10:31 -------
Maybe a first step is to simply support searching/copy/paste Unicode strings.
That should quite possible give the encoding vector of PS (and PDF) fonts. SVG
should have no problem I guess.
### Depends on
* [Bug 55977](https://bugs.freedesktop.org/show_bug.cgi?id=55977)
### Blocking
* [Bug 4101](https://bugs.freedesktop.org/show_bug.cgi?id=4101)
### See also
* https://bugs.freedesktop.org/show_bug.cgi?id=55977https://gitlab.freedesktop.org/poppler/poppler/-/issues/273Rendering unprecise -> holes in large parentheses2018-08-21T10:35:05ZBugzilla Migration UserRendering unprecise -> holes in large parentheses## Submitted by Patrick Häcker
Assigned to **poppler-bugs**
**[Link to original bug (#64855)](https://bugs.freedesktop.org/show_bug.cgi?id=64855)**
## Description
The rendering of a PDF file generated by LaTeX is unprecise, which ...## Submitted by Patrick Häcker
Assigned to **poppler-bugs**
**[Link to original bug (#64855)](https://bugs.freedesktop.org/show_bug.cgi?id=64855)**
## Description
The rendering of a PDF file generated by LaTeX is unprecise, which leads to tiny holes in large parentheses as described here http://tex.stackexchange.com/q/115260. As this is reproducible in all tested poppler viewers including xpdf, but cannot be reproduces with mupdf, this seems to be a poppler issue. Unfortunately, I do not know poppler good enough to describe the problematic component, but it occurs in Okular, for example.https://gitlab.freedesktop.org/poppler/poppler/-/issues/271add API to create PopplerDocument from FD2018-08-21T10:34:58ZBugzilla Migration Useradd API to create PopplerDocument from FD## Submitted by Christian Persch (GNOME)
Assigned to **poppler-bugs**
**[Link to original bug (#107599)](https://bugs.freedesktop.org/show_bug.cgi?id=107599)**
## Description
Created attachment 141154
patch
There is API to create...## Submitted by Christian Persch (GNOME)
Assigned to **poppler-bugs**
**[Link to original bug (#107599)](https://bugs.freedesktop.org/show_bug.cgi?id=107599)**
## Description
Created attachment 141154
patch
There is API to create PopplerDocument from a filename, GFile, GInputStream, but not a simple FD. While one could wrap a FD into a GUnixInputStream, that's not as convenient or performant.
The attached simple patch adds the necessary API; and while I was at it, also the corresponding to-fd variants of the save APIs.
The use case for this is FDs pointing to an already unlinked tempfile (which means that one cannot use the open-by-filename APIs).
**Patch 141154**, "patch":
[poppler-fd.patch](/uploads/9190ab3202c7b48bc3d06d11f4490f9f/poppler-fd.patch)https://gitlab.freedesktop.org/poppler/poppler/-/issues/270Links are not correct if using complex and single html mode in pdftohtml2018-10-11T20:23:54ZBugzilla Migration UserLinks are not correct if using complex and single html mode in pdftohtml## Submitted by Fabian B
Assigned to **poppler-bugs**
**[Link to original bug (#41457)](https://bugs.freedesktop.org/show_bug.cgi?id=41457)**
## Description
Created attachment 51966
The solution for this problem
If you have a doc...## Submitted by Fabian B
Assigned to **poppler-bugs**
**[Link to original bug (#41457)](https://bugs.freedesktop.org/show_bug.cgi?id=41457)**
## Description
Created attachment 51966
The solution for this problem
If you have a document with several pdf slides and want to convert it to html in complex and single html mode, the links leading from one to another slides are not correct.
My solution is setting an html anchor after the body of each slide and setting the links to these anchors.
For that I changed some lines in the source code (see the atached file)
**Attachment 51966**, "The solution for this problem":
[HtmlOutputDev.cc](/uploads/0c95202dfba4c178a30783492cb67d99/HtmlOutputDev.cc)https://gitlab.freedesktop.org/poppler/poppler/-/issues/267very slow render2018-08-21T10:34:17ZBugzilla Migration Uservery slow render## Submitted by nameX
Assigned to **poppler-bugs**
**[Link to original bug (#64892)](https://bugs.freedesktop.org/show_bug.cgi?id=64892)**
## Description
Created attachment 79690
the 3rd page render very slow
This pdf's page 3 re...## Submitted by nameX
Assigned to **poppler-bugs**
**[Link to original bug (#64892)](https://bugs.freedesktop.org/show_bug.cgi?id=64892)**
## Description
Created attachment 79690
the 3rd page render very slow
This pdf's page 3 renders very slow.It seems caused by tilingpatternfill.
Xpdf renders it much faster than poppler(5mins vs 20mins).
**Attachment 79690**, "the 3rd page render very slow":
[sample2.pdf](/uploads/060d4d87220606081791cd1ca26bc767/sample2.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/266pdfinfo prints unrotated dimensions for landscape pages2018-10-07T00:35:43ZBugzilla Migration Userpdfinfo prints unrotated dimensions for landscape pages## Submitted by Ilmari Heikkinen
Assigned to **poppler-bugs**
**[Link to original bug (#17195)](https://bugs.freedesktop.org/show_bug.cgi?id=17195)**
## Description
Calling pdfinfo on a PDF with landscape orientation prints the un...## Submitted by Ilmari Heikkinen
Assigned to **poppler-bugs**
**[Link to original bug (#17195)](https://bugs.freedesktop.org/show_bug.cgi?id=17195)**
## Description
Calling pdfinfo on a PDF with landscape orientation prints the unrotated page dimensions and doesn't tell that the page is rotated.
Proposed fix:
poppler/utils/pdfinfo.cc should use doc->getPageRotate(pg) to either print whether the page is rotated or to swap w and h.
Here's a patch that does w-h swapping:
http://github.com/kig/poppler/commit/1be66974479781f84fbb6872573bb2febdc1ad60https://gitlab.freedesktop.org/poppler/poppler/-/issues/265pdfunite crash while open and write to the same file2018-10-11T20:25:57ZBugzilla Migration Userpdfunite crash while open and write to the same file## Submitted by Thomasy
Assigned to **poppler-bugs**
**[Link to original bug (#95331)](https://bugs.freedesktop.org/show_bug.cgi?id=95331)**
## Description
Created attachment 123589
damaged pdf file
Execute pdfunite design/force_...## Submitted by Thomasy
Assigned to **poppler-bugs**
**[Link to original bug (#95331)](https://bugs.freedesktop.org/show_bug.cgi?id=95331)**
## Description
Created attachment 123589
damaged pdf file
Execute pdfunite design/force_sensor.pdf out.pdf using shell script and pdfunite will crash with message:
Syntax Error: Couldn't find trailer dictionary
Internal Error (0): Call to Object where the object was type 5, not the expected type 7
##########
gdb debug info
pdfunite design/force_sensor.pdf out.pdf
GNU gdb (Ubuntu 7.11-0ubuntu1) 7.11
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from pdfunite...Reading symbols from /usr/lib/debug/.build-id/d5/681490cf3a1a7b36229bafe2cdc992e80581bf.debug...done.
done.
```
(gdb) run
Starting program: /usr/bin/pdfunite design/force_sensor.pdf design/force_sensor.pdf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Syntax Error: Couldn't find trailer dictionary
Internal Error (0): Call to Object where the object was type 5, not the expected type 7
Program received signal SIGABRT, Aborted.
0xb7fdac31 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fdac31 in __kernel_vsyscall ()
#1 0xb7a4be89 in __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#2 0xb7a4d3e7 in __GI_abort () at abort.c:89
#3 0x0804ab30 in Object::getDict (this=0xbfffef38, this=0xbfffef38) at ../poppler/Object.h:209
#4 0x08049c88 in main (argc=3, argv=0xbffff054) at pdfunite.cc:247
(gdb)
```
**Attachment 123589**, "damaged pdf file":
[force_sensor.pdf](/uploads/5ca52508f556cb4db7f5afb81d08948b/force_sensor.pdf)