poppler issueshttps://gitlab.freedesktop.org/poppler/poppler/-/issues2020-05-17T10:22:07Zhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/430No proper creation of PS / Can't print2020-05-17T10:22:07ZBugzilla Migration UserNo proper creation of PS / Can't print## Submitted by famo
Assigned to **poppler-bugs**
**[Link to original bug (#91190)](https://bugs.freedesktop.org/show_bug.cgi?id=91190)**
## Description
It is not possible to print this (see URL) 6 page document, instead it only p...## Submitted by famo
Assigned to **poppler-bugs**
**[Link to original bug (#91190)](https://bugs.freedesktop.org/show_bug.cgi?id=91190)**
## Description
It is not possible to print this (see URL) 6 page document, instead it only prints one page with the Berker Logo in the top-right.
From Okular bug:
https://bugs.kde.org/show_bug.cgi?id=349540https://gitlab.freedesktop.org/poppler/poppler/-/issues/429don't show the colour correctly in background-color in tables (create with OOo)2018-08-21T10:55:04ZBugzilla Migration Userdon't show the colour correctly in background-color in tables (create with OOo)## Submitted by Pedro Villavicencio
Assigned to **poppler-bugs**
**[Link to original bug (#18532)](https://bugs.freedesktop.org/show_bug.cgi?id=18532)**
## Description
this report has been opened here:
https://bugs.edge.launchpad...## Submitted by Pedro Villavicencio
Assigned to **poppler-bugs**
**[Link to original bug (#18532)](https://bugs.freedesktop.org/show_bug.cgi?id=18532)**
## Description
this report has been opened here:
https://bugs.edge.launchpad.net/ubuntu/+source/poppler/+bug/268726
"In the tables with columns (or rows) merged with a colour background (ex, red) evince shows lines on each box.
I attach an example created with OOo Calc.
PS: if you open the PDF with Adobe Reader it shows correctly."
pdf: http://launchpadlibrarian.net/17521634/exampletablesevince.pdf
screenshot:
http://launchpadlibrarian.net/17542818/example-areadervsevince.jpg
Thanks you,https://gitlab.freedesktop.org/poppler/poppler/-/issues/428PDFDoc Saving issue.2021-06-12T07:07:25ZBugzilla Migration UserPDFDoc Saving issue.## Submitted by alisolutions
Assigned to **poppler-bugs**
**[Link to original bug (#74272)](https://bugs.freedesktop.org/show_bug.cgi?id=74272)**
## Description
When I try to save PDFDoc object using this function PDFDoc::savePage...## Submitted by alisolutions
Assigned to **poppler-bugs**
**[Link to original bug (#74272)](https://bugs.freedesktop.org/show_bug.cgi?id=74272)**
## Description
When I try to save PDFDoc object using this function PDFDoc::savePageAs(GooString *name, int pageNo).
Orignal pdf file become corrupted.
And I could not able to save PDF page by page.https://gitlab.freedesktop.org/poppler/poppler/-/issues/427The main layer in PDF not seen2018-08-21T10:54:57ZBugzilla Migration UserThe main layer in PDF not seen## Submitted by Ash
Assigned to **poppler-bugs**
**[Link to original bug (#97768)](https://bugs.freedesktop.org/show_bug.cgi?id=97768)**
## Description
Created attachment 126461
A sample PDF unreadable via poppler (a page from Arc...## Submitted by Ash
Assigned to **poppler-bugs**
**[Link to original bug (#97768)](https://bugs.freedesktop.org/show_bug.cgi?id=97768)**
## Description
Created attachment 126461
A sample PDF unreadable via poppler (a page from Archive.org)
Archive.org generates PDFs which have layers. Some are not seen in Okular. I attach a PDF you cannot read in Okular, but it looks fine in any browser plugin or other PDF viewer. Here is the same sample PDF in case the attachment is not ok: https://dl.dropboxusercontent.com/u/58231097/189.pdf
Reproducible: Always
Steps to Reproduce:
1. Download the PDF: https://dl.dropboxusercontent.com/u/58231097/189.pdf
2. Open it in Okular
3. Open it in anything else reading PDFs
Actual Results:
I cannot read the text layer of the PDF in Okular
Expected Results:
The text layer should be readable, like in any other PDF viewer.
The bug report was initially posted on KDE Bugzilla, and the following reply was recieved:
=====================================
Yuri Chornoivan 2016-09-11 11:04:35 UTC
Hi,
This looks like a bug in poppler (library for handling PDF). At least, all poppler-based PDF-viewers (qpdfviewer, Evince) do not render it correctly. muPDF shows it as it should.
Please file a bug report against poppler here
https://bugs.freedesktop.org/
Thanks in advance for your work.
=====================================
I confirm that Inkscape cannot render the layer via poppler, either.
Thank you!
**Attachment 126461**, "A sample PDF unreadable via poppler (a page from Archive.org)":
[189.pdf](/uploads/d44b12346bf1985303098f3800de8020/189.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/426Mis-placed ActualText strings2018-08-21T10:54:46ZBugzilla Migration UserMis-placed ActualText strings## Submitted by Khaled Hosny
Assigned to **poppler-bugs**
**[Link to original bug (#26077)](https://bugs.freedesktop.org/show_bug.cgi?id=26077)**
## Description
Created attachment 32670
PDF file used
The ActualText strings seems ...## Submitted by Khaled Hosny
Assigned to **poppler-bugs**
**[Link to original bug (#26077)](https://bugs.freedesktop.org/show_bug.cgi?id=26077)**
## Description
Created attachment 32670
PDF file used
The ActualText strings seems to be placed incorrectly, in the attached PDF file the extracted text (using pdftotext) should be "This ⁂ is an asterism." but what I get is:
This
is an asterism.
⁂
~~**Attachment 32670**~~, "PDF file used":
[ast.pdf](/uploads/66083b8c3629ff9c9eb4f848f5b15eee/ast.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/425Handle font problems better2018-10-27T14:55:59ZBugzilla Migration UserHandle font problems better## Submitted by Orion Poplawski
Assigned to **poppler-bugs**
**[Link to original bug (#37292)](https://bugs.freedesktop.org/show_bug.cgi?id=37292)**
## Description
Created attachment 46832
Problematic pdf
The attached document ap...## Submitted by Orion Poplawski
Assigned to **poppler-bugs**
**[Link to original bug (#37292)](https://bugs.freedesktop.org/show_bug.cgi?id=37292)**
## Description
Created attachment 46832
Problematic pdf
The attached document apparently has some problems with the embedded Type 1C fonts in it. With gs 9.02, it reports errors and replaces the problematic fonts with system fonts:
$ pdf2ps NovopashinMuriel2002_IsTheCriticalReynoldsNumberUniversal.pdf
**** Warning: can't process font stream, loading font by the name.
**** Warning: can't process font stream, loading font by the name.
**** This file had errors that were repaired or ignored.
**** The file was produced by:
**** >>>> Mac OS X 10.6.7 Quartz PDFContext <<<<
**** Please notify the author of the software that produced this
**** file that it does not conform to Adobe's published PDF
**** specification.
gs directly also reports:
Substituting font Times-Roman for XQAGXY+Times-Pandre-Light.
Can't find (or can't open) font file /usr/share/ghostscript/9.02/Resource/Font/NimbusRomNo9L-Regu.
Can't find (or can't open) font file NimbusRomNo9L-Regu.
Can't find (or can't open) font file /usr/share/ghostscript/9.02/Resource/Font/NimbusRomNo9L-Regu.
Can't find (or can't open) font file NimbusRomNo9L-Regu.
Querying operating system for font files...
Loading NimbusRomNo9L-Regu font from /usr/share/fonts/default/Type1/n021003l.pfb... 3700140 2347017 6809988 5252199 3 done.
The poppler pdftops output when printed produces the following error on the printer:
ERROR: invalidfont
OFFENDING COMMAND: definefont
STACK:
/Font
-dictionary-
/RDNCVK+RusTimes-Pandre-LightItalic
It would be great if poppler could detect the same issue and do the same font substitution.
$ pdffonts NovopashinMuriel2002_IsTheCriticalReynoldsNumberUniversal.pdfname type emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
QGTTJK+Symbol TrueType yes yes no 10 0
FKIRVC+Symbol TrueType yes yes yes 11 0
TIZLRL+Times-Pandre-LightItalic Type 1C yes yes no 14 0
RDNCVK+RusTimes-Pandre-LightItalic Type 1C yes yes no 9 0
UJIXRV+Times-Roman TrueType yes yes no 7 0
BQZNJF+Times-Italic TrueType yes yes no 8 0
USEOII+Times-Bold TrueType yes yes no 12 0
XQAGXY+Times-Pandre-Light Type 1C yes yes no 22 0
**Attachment 46832**, "Problematic pdf":
[NovopashinMuriel2002_IsTheCriticalReynoldsNumberUniversal.pdf](/uploads/ced0f911f8d9aeb3cecda151a82de397/NovopashinMuriel2002_IsTheCriticalReynoldsNumberUniversal.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/424File that is slower in Splash renderer than in Cairo renderer2018-09-01T12:34:03ZBugzilla Migration UserFile that is slower in Splash renderer than in Cairo renderer## Submitted by Yuri
Assigned to **poppler-bugs**
**[Link to original bug (#22128)](https://bugs.freedesktop.org/show_bug.cgi?id=22128)**
## Description
gv opens it in a few seconds and okular (through poppler-0.10.6) takes over a...## Submitted by Yuri
Assigned to **poppler-bugs**
**[Link to original bug (#22128)](https://bugs.freedesktop.org/show_bug.cgi?id=22128)**
## Description
gv opens it in a few seconds and okular (through poppler-0.10.6) takes over a minute.https://gitlab.freedesktop.org/poppler/poppler/-/issues/423pdftops - same font is embedded multiple times into resulting postscript file2018-10-26T15:19:16ZBugzilla Migration Userpdftops - same font is embedded multiple times into resulting postscript file## Submitted by Alex Korobkin
Assigned to **poppler-bugs**
**[Link to original bug (#65306)](https://bugs.freedesktop.org/show_bug.cgi?id=65306)**
## Description
Created attachment 80237
P020110106297943134404.pdf
When pdftops co...## Submitted by Alex Korobkin
Assigned to **poppler-bugs**
**[Link to original bug (#65306)](https://bugs.freedesktop.org/show_bug.cgi?id=65306)**
## Description
Created attachment 80237
P020110106297943134404.pdf
When pdftops converts the attached PDF file into PS with -r 300 -level3 command line parameters, and when SimSun TTF font is available in the system, SimSun font gets embedded ~80 times into the resulting PS file, making it grow up to ~2 Gb, which not every printer would be able to congest.
It would be nice to have it embedded just one time or just a subset of characters.
Tested on poppler 0.18.4, 0.19.0, 0.20.0, 0.22.3, 0.22.4 on Ubuntu 12.04 x64 and Ubuntu 10.04 x64.
**Attachment 80237**, "P020110106297943134404.pdf":
[P020110106297943134404.pdf](/uploads/05c9e1a2813a3af838b1ea54b7330bf0/P020110106297943134404.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/422pdftohtml: add image and font extraction2018-10-08T10:47:35ZBugzilla Migration Userpdftohtml: add image and font extraction## Submitted by Joshua Richardson
Assigned to **poppler-bugs**
**[Link to original bug (#39385)](https://bugs.freedesktop.org/show_bug.cgi?id=39385)**
## Description
Created attachment 49314
patches to resolve this enhancement
No...## Submitted by Joshua Richardson
Assigned to **poppler-bugs**
**[Link to original bug (#39385)](https://bugs.freedesktop.org/show_bug.cgi?id=39385)**
## Description
Created attachment 49314
patches to resolve this enhancement
Now, instead of generating one large background image per page, smaller images, just large enough to capture the graphical elements are generated, and only on pages where there actually are graphical elements.
In addition, the images may optionally be generated at a larger viewing size, so that the images can be viewed larger, but they still show up the same size in the generated HTML. We added a new "-dpi" switch for this.
Finally, there is a new option "-embedfonts" which will make the generated html utilize extracted fonts. (For now, you'll have to use another utility like mu pdfextract to actually extract those fonts.)
These features were all built in parallel, so the easiest way to merge them back to the poppler public repository will probably be to apply all the patches together in order. In the tarball, I've also included other patches from the public repository that happened while we were developing. This is in the hope that it will be easier to figure out the right way to apply the patches in order without conflicts. But so as not to be confused, the only patches that are relevant to this enhancement bug are the ones authored by Joshua Richardson or Stephen Reichling.
~~**Attachment 49314**~~, "patches to resolve this enhancement":
[img-font-extract-patches.tgz](/uploads/c55279ecaddddcddf41fddf191f59a2e/img-font-extract-patches.tgz)https://gitlab.freedesktop.org/poppler/poppler/-/issues/421Accented characters are badly copied2018-10-27T15:13:12ZBugzilla Migration UserAccented characters are badly copied## Submitted by Guillaume Desmottes `@gdesmott`
Assigned to **poppler-bugs**
**[Link to original bug (#7065)](https://bugs.freedesktop.org/show_bug.cgi?id=7065)**
## Description
Transfering this bug from GNOME Bugzilla:
http://bug...## Submitted by Guillaume Desmottes `@gdesmott`
Assigned to **poppler-bugs**
**[Link to original bug (#7065)](https://bugs.freedesktop.org/show_bug.cgi?id=7065)**
## Description
Transfering this bug from GNOME Bugzilla:
http://bugzilla.gnome.org/show_bug.cgi?id=338942
To reproduce:
- Open this file: http://cass.no-ip.com/~cassidy/files/brol/test.pdf
- Copy the first line
- Paste it in gedit
The text pasted is:
Bugs : ´ ` c `
ea¸e
(The selection is badly displayed, see [bug 338940](https://bugs.freedesktop.org/show_bug.cgi?id=338940)).
I use evine 0.5.2 with poppler 0.5.1 (Ubuntu Dapper).
The pdf was created from http://cass.no-ip.com/~cassidy/files/brol/test.tex.
I'm not sure if this bug is a dup of [bug 2981](https://bugs.freedesktop.org/show_bug.cgi?id=2981). If it is, feel free to close it.https://gitlab.freedesktop.org/poppler/poppler/-/issues/420Can't fill (or even find) fields in PDF form created (or saved) with Mac Preview2018-10-27T13:45:20ZBugzilla Migration UserCan't fill (or even find) fields in PDF form created (or saved) with Mac Preview## Submitted by Germán Poo-Caamaño
Assigned to **poppler-bugs**
**[Link to original bug (#106844)](https://bugs.freedesktop.org/show_bug.cgi?id=106844)**
## Description
Created attachment 140057
PDF Test case
Reported in https://...## Submitted by Germán Poo-Caamaño
Assigned to **poppler-bugs**
**[Link to original bug (#106844)](https://bugs.freedesktop.org/show_bug.cgi?id=106844)**
## Description
Created attachment 140057
PDF Test case
Reported in https://gitlab.gnome.org/GNOME/evince/issues/657
Trying to complete a state tax form that was created or saved (I don't know which) on a Mac using Mac Preview. However, none of the input fields are visible nor can they be selected (it's like they aren't there). The maintainers of the form have used Windows and Adobe Reader to load and re-save it, so I can't provide a link to the failed form. However, I have attached my copy of the form for your use.
Linux Mint 17.3 and Document Viewer 3.10.3
**Attachment 140057**, "PDF Test case":
[tc-40.pdf](/uploads/acffd80e92ecce1528073e5edcaf51a0/tc-40.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/419poppler-0.44.0: memory leak (valgrind) in Gfx::doImage on broken file2018-10-05T23:19:09ZBugzilla Migration Userpoppler-0.44.0: memory leak (valgrind) in Gfx::doImage on broken file## Submitted by LE GARREC Vincent
Assigned to **poppler-bugs**
**[Link to original bug (#96269)](https://bugs.freedesktop.org/show_bug.cgi?id=96269)**
## Description
colorMap is not freed on broken file.
==10237== 1,472,616 (217,...## Submitted by LE GARREC Vincent
Assigned to **poppler-bugs**
**[Link to original bug (#96269)](https://bugs.freedesktop.org/show_bug.cgi?id=96269)**
## Description
colorMap is not freed on broken file.
==10237== 1,472,616 (217,200 direct, 1,255,416 indirect) bytes in 181 blocks are definitely lost in loss record 45 of 46
==10237== at 0x4C2C25D: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10237== by 0x4FC00D4: Gfx::doImage(Object*, Stream*, bool) (in /usr/lib64/libpoppler.so.60.0.0)
==10237== by 0x4FBEEE9: Gfx::opXObject(Object*, int) (in /usr/lib64/libpoppler.so.60.0.0)
==10237== by 0x4FABE4B: Gfx::execOp(Object*, Object*, int) (in /usr/lib64/libpoppler.so.60.0.0)
==10237== by 0x4FAB6DF: Gfx::go(bool) (in /usr/lib64/libpoppler.so.60.0.0)
==10237== by 0x4FAB4B0: Gfx::display(Object*, bool) (in /usr/lib64/libpoppler.so.60.0.0)
==10237== by 0x50180C2: Page::displaySlice(OutputDev*, double, double, int, bool, bool, int, int, int, int, bool, bool (*)(void*), void*, bool (*)(Annot*, void*), void*, bool) (in /usr/lib64/libpoppler.so.60.0.0)
==10237== by 0x5017AFF: Page::display(OutputDev*, double, double, int, bool, bool, bool, bool (*)(void*), void*, bool (*)(Annot*, void*), void*, bool) (in /usr/lib64/libpoppler.so.60.0.0)
==10237== by 0x501BB8E: PDFDoc::displayPage(OutputDev*, int, double, double, int, bool, bool, bool, bool (*)(void*), void*, bool (*)(Annot*, void*), void*, bool) (in /usr/lib64/libpoppler.so.60.0.0)
==10237== by 0x501BC2F: PDFDoc::displayPages(OutputDev*, int, int, double, double, int, bool, bool, bool, bool (*)(void*), void*, bool (*)(Annot*, void*), void*) (in /usr/lib64/libpoppler.so.60.0.0)
==10237== by 0x40EEF4: main (in /usr/bin/pdftohtml)https://gitlab.freedesktop.org/poppler/poppler/-/issues/418Not all characters sit on the baseline2018-08-21T10:53:55ZBugzilla Migration UserNot all characters sit on the baseline## Submitted by Sebastien Bacher
Assigned to **poppler-bugs**
**[Link to original bug (#7777)](https://bugs.freedesktop.org/show_bug.cgi?id=7777)**
## Description
(bug forwarded first to http://bugzilla.gnome.org/show_bug.cgi?id=3...## Submitted by Sebastien Bacher
Assigned to **poppler-bugs**
**[Link to original bug (#7777)](https://bugs.freedesktop.org/show_bug.cgi?id=7777)**
## Description
(bug forwarded first to http://bugzilla.gnome.org/show_bug.cgi?id=321142)
This bug has been opened here:
https://launchpad.net/distros/ubuntu/+source/evince/+bug/3217
"...
Description:
Sometimes characters in PDFs do not all sit on the base line. There is a slight
pixel vertical misalignment making the lines look messy.
Steps to reproduce the problem:
1. Download
http://www.changethis.com/13.SmartPeople/download/?screen=0&action=download_manifesto
.
2. Open the saved PDF in evince .
3. Press F5 to leave presentation mode.
4. Set the zoom to 150% and make the window wider.
5. Go to page 2.
Expected results:
The baseline of all characters in the same font to be level.
Actual results:
If you look at the e of the first "The" on the page you will notice that it
appears to be lower than "Th". The same goes for the c of "cubicle" on the third
line.
Additional information:
This isn't actually an evince bug because xpdf and even acroread have the same
problem. However acroread has the option not to use Local Fonts and not using
local fonts makes the problem go away. The same problem has been observed in
other distros (e.g. OpenSUSE 10) too. GNOME font settings are 96dpi, Smoothing
of grayscale and hinting of Medium (the defaults originally picked).
I have only filed it evince because that is where I first saw it and I hope that
this will let the bug be moved to its proper home.
http://librarian.launchpad.net/958903/evince%20baseline%20screenshot.png
Cropped screenshot of evince showing the misaligned baseline problem
..."https://gitlab.freedesktop.org/poppler/poppler/-/issues/417pdftohtml -xml fails to extract text that is extracted in pdftotext2018-08-21T10:53:53ZBugzilla Migration Userpdftohtml -xml fails to extract text that is extracted in pdftotext## Submitted by Petter Reinholdtsen
Assigned to **poppler-bugs**
**[Link to original bug (#50739)](https://bugs.freedesktop.org/show_bug.cgi?id=50739)**
## Description
When I convert
http://nrk.no/contentfile/file/1.8116520!offent...## Submitted by Petter Reinholdtsen
Assigned to **poppler-bugs**
**[Link to original bug (#50739)](https://bugs.freedesktop.org/show_bug.cgi?id=50739)**
## Description
When I convert
http://nrk.no/contentfile/file/1.8116520!offentligjournal02052012.pdf
to XML using
pdftohtml -xml -noframes 1.8116520\!offentligjournal02052012.pdf
I get the following content-less XML file. I find this rather strange,
as the PDF is searchable using xpdf, okular and evince. Any idea where
the text went? Anything I can do to get access to the text as XML?
This is the output I get:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd">
`<pdf2xml>`
`<page number="1" position="absolute" top="0" left="0" height="792" width="612">`
<fontspec id="0" size="18" family="Helvetica" color="#000000"/>
<fontspec id="1" size="5" family="Helvetica" color="#000000"/>
<fontspec id="2" size="5" family="Helvetica" color="#000000"/>
<fontspec id="3" size="7" family="Helvetica" color="#000000"/>
`</page>`
`<page number="2" position="absolute" top="0" left="0" height="792" width="612">`
<fontspec id="4" size="6" family="Helvetica" color="#000000"/>
`</page>`
`<page number="3" position="absolute" top="0" left="0" height="792" width="612">`
`</page>`
`<page number="4" position="absolute" top="0" left="0" height="792" width="612">`
`</page>`
`<page number="5" position="absolute" top="0" left="0" height="792" width="612">`
`</page>`
`<page number="6" position="absolute" top="0" left="0" height="792" width="612">`
`</page>`
`<page number="7" position="absolute" top="0" left="0" height="792" width="612">`
`</page>`
`<page number="8" position="absolute" top="0" left="0" height="792" width="612">`
`</page>`
`<page number="9" position="absolute" top="0" left="0" height="792" width="612">`
`</page>`
`<page number="10" position="absolute" top="0" left="0" height="792" width="612">`
`</page>`
`<page number="11" position="absolute" top="0" left="0" height="792" width="612">`
`</page>`
`<page number="12" position="absolute" top="0" left="0" height="792" width="612">`
`</page>`
`<page number="13" position="absolute" top="0" left="0" height="792" width="612">`
`</page>`
`<page number="14" position="absolute" top="0" left="0" height="792" width="612">`
`</page>`
`<page number="15" position="absolute" top="0" left="0" height="792" width="612">`
`</page>`
`<page number="16" position="absolute" top="0" left="0" height="792" width="612">`
`</page>`
`<page number="17" position="absolute" top="0" left="0" height="792" width="612">`
`</page>`
`<page number="18" position="absolute" top="0" left="0" height="792" width="612">`
`</page>`
`<page number="19" position="absolute" top="0" left="0" height="792" width="612">`
`</page>`
`<page number="20" position="absolute" top="0" left="0" height="792" width="612">`
`</page>`
`</pdf2xml>`
This problem is also reported to Debian as http://bugs.debian.org/676238https://gitlab.freedesktop.org/poppler/poppler/-/issues/416Make PDFDoc::setup provide the wasReconstructed value to the caller2021-05-14T22:21:32ZBugzilla Migration UserMake PDFDoc::setup provide the wasReconstructed value to the caller## Submitted by Albert Astals Cid
Assigned to **poppler-bugs**
**[Link to original bug (#75588)](https://bugs.freedesktop.org/show_bug.cgi?id=75588)**
## Description
This way the caller application may chose to show a warning to t...## Submitted by Albert Astals Cid
Assigned to **poppler-bugs**
**[Link to original bug (#75588)](https://bugs.freedesktop.org/show_bug.cgi?id=75588)**
## Description
This way the caller application may chose to show a warning to the user saying something like "The PDF is broken but we're still showing something, contents may not be correct"https://gitlab.freedesktop.org/poppler/poppler/-/issues/415Where are the pdftoppm output files if there is '/' in the arg?2020-08-03T21:57:18ZBugzilla Migration UserWhere are the pdftoppm output files if there is '/' in the arg?## Submitted by she..@..il.com
Assigned to **poppler-bugs**
**[Link to original bug (#81235)](https://bugs.freedesktop.org/show_bug.cgi?id=81235)**
## Description
If I run "pdftoppm example.pdf images/a" without creating directory...## Submitted by she..@..il.com
Assigned to **poppler-bugs**
**[Link to original bug (#81235)](https://bugs.freedesktop.org/show_bug.cgi?id=81235)**
## Description
If I run "pdftoppm example.pdf images/a" without creating directory "images", where are the output files?
There's no error display for such condition, and it seems working just without output.https://gitlab.freedesktop.org/poppler/poppler/-/issues/414poppler_document_new_from_stream creates PopplerInputStream with zero length2019-05-28T13:07:01ZBugzilla Migration Userpoppler_document_new_from_stream creates PopplerInputStream with zero length## Submitted by Emilio Pozuelo Monfort
Assigned to **poppler-bugs**
**[Link to original bug (#106295)](https://bugs.freedesktop.org/show_bug.cgi?id=106295)**
## Description
Hi,
I got this report: https://github.com/ruby-gnome2/ru...## Submitted by Emilio Pozuelo Monfort
Assigned to **poppler-bugs**
**[Link to original bug (#106295)](https://bugs.freedesktop.org/show_bug.cgi?id=106295)**
## Description
Hi,
I got this report: https://github.com/ruby-gnome2/ruby-gnome2/issues/1159
from Debian's: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896596
Looks like poppler_document_new_from_stream() creates a PopplerInputStream with zero length even when _new_from_stream's length parameter is specified. That seems to cause some problems with PDFDoc's getLength() check:
https://cgit.freedesktop.org/poppler/poppler/commit/?id=a59f61641fcb36859b625749afb4561557e419f6
There's a patch in https://github.com/ruby-gnome2/ruby-gnome2/issues/1159. I don't know if that needs a check for length == -1 (i.e. unknown)https://gitlab.freedesktop.org/poppler/poppler/-/issues/413Wrong text display in PDF2018-08-21T10:53:39ZBugzilla Migration UserWrong text display in PDF## Submitted by Dmitry
Assigned to **poppler-bugs**
**[Link to original bug (#105665)](https://bugs.freedesktop.org/show_bug.cgi?id=105665)**
## Description
Created attachment 138253
File with incorrectly displayed text
Text in t...## Submitted by Dmitry
Assigned to **poppler-bugs**
**[Link to original bug (#105665)](https://bugs.freedesktop.org/show_bug.cgi?id=105665)**
## Description
Created attachment 138253
File with incorrectly displayed text
Text in the attached file is horizontally cut, screenshot attached.
Text is displayed correctly with Okular, Foxit software, Master PDF Editor and Adobe.
The issue appears in Evince software, redirected here by their support. Link for Evince bugtracker issue:
https://bugzilla.gnome.org/show_bug.cgi?id=794562
**Attachment 138253**, "File with incorrectly displayed text":
[text-error.pdf](/uploads/1b083f8c574db25c216026c2a311ce53/text-error.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/412textList() reverse characters order for Arabic2018-08-21T10:53:33ZBugzilla Migration UsertextList() reverse characters order for Arabic## Submitted by Fahad Al-Saidi
Assigned to **poppler-bugs**
**[Link to original bug (#105015)](https://bugs.freedesktop.org/show_bug.cgi?id=105015)**
## Description
I am trying to fix okular bug #207748 (RTL languages searches tex...## Submitted by Fahad Al-Saidi
Assigned to **poppler-bugs**
**[Link to original bug (#105015)](https://bugs.freedesktop.org/show_bug.cgi?id=105015)**
## Description
I am trying to fix okular bug #207748 (RTL languages searches text backwards), I trace it to textList() reverse Arabic characters. so, if the pdf text is "testing تجربة "
textlist() will return something likes this:
[0] = "testing"
[1] = "ةبرجت"
It should be:
[0] = "testing"
[1] = "تجربة"https://gitlab.freedesktop.org/poppler/poppler/-/issues/411Bad rendering (hinting) in Evince and Xpdf2018-08-21T10:53:29ZBugzilla Migration UserBad rendering (hinting) in Evince and Xpdf## Submitted by Sebastien Bacher
Assigned to **poppler-bugs**
**[Link to original bug (#9862)](https://bugs.freedesktop.org/show_bug.cgi?id=9862)**
## Description
That bug has been described on https://launchpad.net/ubuntu/+source...## Submitted by Sebastien Bacher
Assigned to **poppler-bugs**
**[Link to original bug (#9862)](https://bugs.freedesktop.org/show_bug.cgi?id=9862)**
## Description
That bug has been described on https://launchpad.net/ubuntu/+source/poppler/+bug/26118
"...
http://librarian.launchpad.net/4941174/SplashFTFont.cc
Modified splash/SplashFTFont.cc from poppler-0.5.4
I think I nailed it!
First of all, the exact same issue arises in Edgy, which is what I am using now. However, it's easy to fix.
Second, it's a poppler problem, not an Evince problem per se.
See file splash/SplashFTFont.cc in poppler-0.5.4 (the Edgy version), lines 180 and following. This is where poppler loads glyphs for the splash output device; this code comes from xpdf, btw.
Basically, there is a compile-time check to see whether freetype has the bytecode interpreter enabled; if so, IT IS USED regardless of whether anti-aliasing is on or off. Otherwise, no hinting is used if anti-aliasing is on. Again, this is a compile-time check.
The problem is that, for most fonts used with LaTeX (but I'd say for most other fonts, too) it's best to omit hinting altogether.
I fixed the problem by simply deleting the portion of the code that is triggered if TT_CONFIG_OPTION_BYTECODE is defined, and instead leaving only the section that is compiled if it is not. Rebuilding with pdebuild and installing with dpkg -i did the trick.
Ideally, this should be a gconf setting, I guess.
Hope this helps,
M
..."