poppler issueshttps://gitlab.freedesktop.org/poppler/poppler/-/issues2020-08-03T04:26:39Zhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/836pdftoppm -v version info send to stderr2020-08-03T04:26:39ZFerenc Radiuspdftoppm -v version info send to stderrtested with 0.80.0 and 0.71.0
```pdftoppm -v 1> /dev/null # does still output the version info```
```
cmd = [
"pdftoppm",
"-v"
]
with subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, stdin=subprocess.PIP...tested with 0.80.0 and 0.71.0
```pdftoppm -v 1> /dev/null # does still output the version info```
```
cmd = [
"pdftoppm",
"-v"
]
with subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, stdin=subprocess.PIPE) as p:
output, err = p.communicate()
print("err: %s" % err)
```
prints the version info as
```err: <version info>```https://gitlab.freedesktop.org/poppler/poppler/-/issues/835No progress indicator or meter for page rendering2020-12-01T18:24:08ZsgerwkNo progress indicator or meter for page renderingSome pages take very long time to show (example: [fasciaverdenew.pdf](/uploads/bee644ea1bd2378fb0217664cd92676e/fasciaverdenew.pdf)). This is not a fault of poppler, they are just huge. The only way I see so far to inform the user that s...Some pages take very long time to show (example: [fasciaverdenew.pdf](/uploads/bee644ea1bd2378fb0217664cd92676e/fasciaverdenew.pdf)). This is not a fault of poppler, they are just huge. The only way I see so far to inform the user that something is happening is by a spinner or something running in a separate thread. That, however:
- does not make any difference between the case where file reading is blocked, slow or just going on normally but the page is long to process;
- does not tell anything about the progress made so far.
For example, if the page is on a network volume rendering could be stopped or slowed down because of the network while the spinner is still spinning as if the network was ok but the page is hard to render.
I agree that there is no sure way to tell the progress made in rendering, but this also applies to many other processes where progress meters are used, like downloading large files from the Internet or installing new software.
I think such problems could be solved by a callback to the file-reading operations. As far as I can see poppler reads the file during rendering in block of 256 bytes; this would make it straightforward to tell how fast page reading is progressing, distinguishing pages of large content from pages on problematic filesystems.
A progress meter could be implemented if the callback received the current offset in the file, the starting offset and size of the object that is currently being read, and the same for the page content object (including the offset of the last read in it). Of course, this would still give a rough estimate.
This is a request for your opinion: what do you think about all of this?https://gitlab.freedesktop.org/poppler/poppler/-/issues/834issues with (supposedly?) malformed pdf files in libpoppler 0.822019-11-17T00:10:49ZFrank Mariakissues with (supposedly?) malformed pdf files in libpoppler 0.82I recently ran into some issues with libpoppler 0.82 and some PDF manual files from a ASUS graphics card CD that can be found at
https://archive.org/details/ASUSGraphicCardsMulti-languageManualV621Q3385Q3386Q33252008
,e.g. Installation...I recently ran into some issues with libpoppler 0.82 and some PDF manual files from a ASUS graphics card CD that can be found at
https://archive.org/details/ASUSGraphicCardsMulti-languageManualV621Q3385Q3386Q33252008
,e.g. Installation guide/AMD/g.pdf seems to be impossible to load, it even causes my application to crash. The file loads OK with the Adobe supplied readers - albeit that a small info pops up and closes again that something is damaged and gets repaired, though. XpdfReader manages to load the file as well.
[g.pdf](/uploads/d752af8959c837a928d08c7250adac8b/g.pdf) (MD5: b98df9f2b9c7fe1ecf7f75d96a4c8a24)
It should probably at least refuse to load or report the file as broken if it's damaged. I also want to point out that this has been included on a release CD, it has not been modified in any form ....https://gitlab.freedesktop.org/poppler/poppler/-/issues/832Password falsely required to read document2019-10-24T18:07:33ZIngo-FP-AngelPassword falsely required to read document**SUMMARY**
I have a PDF where a password is used to protect against editing. But the password is not needed for display only. This file cannot be opened in okular - which uses poppler - on my system.
**STEPS TO REPRODUCE**
1. Open htt...**SUMMARY**
I have a PDF where a password is used to protect against editing. But the password is not needed for display only. This file cannot be opened in okular - which uses poppler - on my system.
**STEPS TO REPRODUCE**
1. Open https://www.bgfg.de/fileadmin/bgfg/Geschaeftsberichte/Geschaeftsbericht_2018_BGFG_Jahrbuchteil_END-Doppelseiten-WEB.pdf in okular
2. Click "cancel" when asked for password
**OBSERVED RESULT**
Error is shown that the file cannot be opened
**EXPECTED RESULT**
The file should be displayed and there should be no password prompt.
**SOFTWARE/OS VERSIONS**
* OS: openSUSE Leap 15.1
* libpoppler73-0.62.0-lp151.3.4.x86_64
* libpoppler-glib8-0.62.0-lp151.3.4.x86_64
* libpoppler-qt5-1-0.62.0-lp151.3.4.x86_64
* poppler-data-0.4.8-lp151.2.1.noarch
* poppler-tools-0.62.0-lp151.3.4.x86_64
* okular: 1.6.3
* KDE Plasma Version: 5.12.8
* KDE Frameworks Version: 5.55.0
* Qt Version: 5.9.7
**ADDITIONAL INFORMATION**
Opening the file with Master PDF Editor on the same machine or with Adobe Reader on another PC does not prompt for a password and displays the file just fine.
Bug was originally reported at https://bugs.kde.org/show_bug.cgi?id=412856 and marked as "upstream".https://gitlab.freedesktop.org/poppler/poppler/-/issues/831link error: /usr/bin/ld: cannot find -lgtk-32020-10-17T00:04:13ZJohn Heinlink error: /usr/bin/ld: cannot find -lgtk-3When linking poppler-glib-demo, I get a linker error: /usr/bin/ld: cannot find -lgtk-3
The CMakeLists.txt file only pulls in the libraries (-lgtk-3, etc.) without the paths to the \
libraries (-L).
Here's a patch that fixes it:
--...When linking poppler-glib-demo, I get a linker error: /usr/bin/ld: cannot find -lgtk-3
The CMakeLists.txt file only pulls in the libraries (-lgtk-3, etc.) without the paths to the \
libraries (-L).
Here's a patch that fixes it:
--- poppler-0.81.0/glib/demo/CMakeLists.txt.orig 2019-10-09 21:27:03 UTC
+++ poppler-0.81.0/glib/demo/CMakeLists.txt
@@ -24,6 +24,9 @@
layers.c
selections.c
taggedstruct.c
)
poppler_add_test(poppler-glib-demo BUILD_GTK_TESTS ${poppler_glib_demo_SRCS})
-target_link_libraries(poppler-glib-demo ${CAIRO_LIBRARIES} poppler-glib ${GTK3_LIBRARIES})
+#target_link_libraries(poppler-glib-demo ${CAIRO_LIBRARIES} poppler-glib ${GTK3_LIBRARIES})
+find_package(PkgConfig REQUIRED)
+pkg_check_modules(GTK3 REQUIRED IMPORTED_TARGET gtk+-3.0)
+target_link_libraries(poppler-glib-demo ${CAIRO_LIBRARIES} poppler-glib PkgConfig::GTK3)
Part of that could be applied to poppler-0.81.0/cmake/modules/FindGTK.cmake instead.
Note: hint for unintuitive cmake features obtained from a stackoverflow answer here:
https://stackoverflow.com/questions/29191855/what-is-the-proper-way-to-use-pkg-config-from-cmakehttps://gitlab.freedesktop.org/poppler/poppler/-/issues/8300.83.0: cmake fails2019-12-09T23:52:17ZTomasz Kłoczko0.83.0: cmake fails<pre>+ /usr/bin/cmake -DBUILD_SHARED_LIBS=ON -DCMAKE_AR=/usr/bin/gcc-ar -DCMAKE_C_FLAGS_RELEASE=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE=-DNDEBUG -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_NM=/usr/bin/gcc-nm -DC...<pre>+ /usr/bin/cmake -DBUILD_SHARED_LIBS=ON -DCMAKE_AR=/usr/bin/gcc-ar -DCMAKE_C_FLAGS_RELEASE=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE=-DNDEBUG -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_NM=/usr/bin/gcc-nm -DCMAKE_RANLIB=/usr/bin/gcc-ranlib -DCMAKE_VERBOSE_MAKEFILE=ON -DINCLUDE_INSTALL_DIR=/usr/include -DLIB_INSTALL_DIR=/usr/lib64 -DLIB_SUFFIX=64 -DSHARE_INSTALL_PREFIX=/usr/share -DSYSCONF_INSTALL_DIR=/etc . -Bx86_64-redhat-linux-gnu -DENABLE_CMS=lcms2 -DENABLE_DCTDECODER=libjpeg -DENABLE_GTK_DOC=ON -DENABLE_LIBOPENJPEG=openjpeg2 -DENABLE_UNSTABLE_API_ABI_HEADERS=ON -DENABLE_ZLIB=OFF -DTEST_BIG_ENDIAN=OFF
-- The C compiler identification is GNU 9.2.1
-- The CXX compiler identification is GNU 9.2.1
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/g++
-- Check for working CXX compiler: /usr/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test GCC_HAS_AS_NEEDED
-- Performing Test GCC_HAS_AS_NEEDED - Success
-- Found PkgConfig: /usr/bin/pkg-config (found version "1.6.3")
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - no
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - failed
-- Check size of unsigned int
-- Check size of unsigned int - failed
-- Check size of unsigned long
-- Check size of unsigned long - failed
CMake Error at /usr/share/cmake/Modules/TestBigEndian.cmake:50 (message):
no suitable type found
Call Stack (most recent call first):
CMakeLists.txt:21 (test_big_endian)
-- Configuring incomplete, errors occurred!
See also "/home/tkloczko/rpmbuild/BUILD/poppler-0.81.0/x86_64-redhat-linux-gnu/CMakeFiles/CMakeOutput.log".
See also "/home/tkloczko/rpmbuild/BUILD/poppler-0.81.0/x86_64-redhat-linux-gnu/CMakeFiles/CMakeError.log".
error: Bad exit status from /var/tmp/rpm-tmp.QOZXAF (%build)
</pre>https://gitlab.freedesktop.org/poppler/poppler/-/issues/829pdffonts: long font names break fixed-width output2019-10-15T22:42:13Ztamunropdffonts: long font names break fixed-width outputIn ~pdffonts 0.80.0, fonts with long names break the fixed-width table format of the output. Here are examples from the attached file,
[Font_problems.pdf](/uploads/bf3d5e0b05d8211469274543a219a32d/Font_problems.pdf)
```
name ...In ~pdffonts 0.80.0, fonts with long names break the fixed-width table format of the output. Here are examples from the attached file,
[Font_problems.pdf](/uploads/bf3d5e0b05d8211469274543a219a32d/Font_problems.pdf)
```
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
MHAFVK+Times#20New#20Roman TrueType WinAnsi yes yes no 103 0
BMPSSD+Times#20New#20Roman,BoldItalic TrueType WinAnsi yes yes no 105 0
GXZEYL+Times#20New#20Roman,Bold_00 TrueType Custom yes yes no 108 0
WLZFBK+Times#20New#20Roman,Bold_0 TrueType WinAnsi yes yes no 110 0
GXZEYL+Times#20New#20Roman,BoldItalic_1_00 TrueType Custom yes yes no 112 0
LOMNPV+Times#20New#20Roman,Italic TrueType WinAnsi yes yes no 114 0
RXNFTE+Times#20New#20Roman_2_00 TrueType Custom yes yes no 117 0
QWBTND+Symbol_00 TrueType Custom yes yes no 120 0
AQAEUC+Times#20New#20Roman,Italic_3_01 TrueType Custom yes yes no 123 0
#cb#ce#cc#e5-GBK-EUC-H-Identity-H-Identity-H CID Type 0C Identity-H yes no no 59 0
CLIMBI+TimesNewRomanPSMT Type 1C Custom yes yes yes 54 0
CLIMDK+TimesNewRomanPS-BoldItalicMT Type 1C Custom yes yes yes 52 0
CLIMDL+Times#20New#20Roman Type 1C Custom yes yes yes 56 0
CLIMCI+TimesNewRomanPS-BoldMT Type 1C Custom yes yes yes 63 0
CLIMEL+TimesNewRomanPS-ItalicMT Type 1C Custom yes yes yes 60 0
MS#20Mincho-90ms-RKSJ-H-Identity-H-Identity-H CID Type 0C Identity-H yes no no 66 0
```
This introduces errors when importing into a spreadsheet. I've tried replacing spaces with tabs using regular expressions, but some font types and names contain spaces, so that introduces other errors. A simple fix for this could be to widen the name column by 20 characters, at least as an option. More elaborate, but probably more robust and useful, would be to offer tab-separated output as an option.https://gitlab.freedesktop.org/poppler/poppler/-/issues/828Support addition of revisions ("replies") to annotations with Qt5 bindings2019-10-15T22:39:25ZHugo DammeSupport addition of revisions ("replies") to annotations with Qt5 bindingsThe current Qt5 binding allows to retrieve the replies to a text/highlight annotation by using the revisions() method.
However, there is no method to allow adding new revisions to an annotation.
A service could be provided to add either...The current Qt5 binding allows to retrieve the replies to a text/highlight annotation by using the revisions() method.
However, there is no method to allow adding new revisions to an annotation.
A service could be provided to add either 1 annotation to the revision list, such as addRevision(const Annotation *), or a list of revisions addRevisions(const QVector<const Annotation *> &).https://gitlab.freedesktop.org/poppler/poppler/-/issues/827Validate LTV signatures2019-10-15T22:41:01ZGustavo MadrigalValidate LTV signaturesIs there a way for pdfsig to detect when a signature is LTV enable? (Long-Term Validated Signature)
https://www.pdfa.org/long-term-validation-of-signatures/
BTW, I can help testing, and provide sample PDF files with different types of ...Is there a way for pdfsig to detect when a signature is LTV enable? (Long-Term Validated Signature)
https://www.pdfa.org/long-term-validation-of-signatures/
BTW, I can help testing, and provide sample PDF files with different types of LTV signatures.
Cheershttps://gitlab.freedesktop.org/poppler/poppler/-/issues/826Apparently random rendering artifacts with some PDF files2019-10-21T21:02:59ZLéo GrangeApparently random rendering artifacts with some PDF filesAn issue was recently opened on Gnome evince project about some visual artifacts (more specifically some random letters in huge font sizes) appearing when viewing some documents.
You can find many details on the original issue: https://g...An issue was recently opened on Gnome evince project about some visual artifacts (more specifically some random letters in huge font sizes) appearing when viewing some documents.
You can find many details on the original issue: https://gitlab.gnome.org/GNOME/evince/issues/1244
Reporters (including me) are on bleeding-edge distributions (Manjaro or Arch) and the bug appeared only a few days/weeks ago.
As I observe the same behavior with other PDF viewers (specifically: with [pdf-tools](https://github.com/politza/pdf-tools) and [pdfpc](https://github.com/pdfpc/pdfpc)), we suspect either poppler or a library used by poppler to be the source of this issue.
Several examples of PDF files causing this are available in Evince issue thread, I can provide more if needed.
As this started around the time of poppler being updated to version 0.80, I tried to revert to poppler 0.79, but didn't changed anything.
I am not very available soon, but will try to help if you need more information.
For information, the list of packages and versions installed marked as dependencies of poppler on my system:
```
poppler 0.79.0-1
libjpeg-turbo 2.0.2-1
gcc-libs 9.1.0-2
cairo 1.17.2+17+g52a7c79fd-1
fontconfig 2:2.13.1+12+g5f5ec56-1
openjpeg2 2.3.1-1
lcms2 2.9-2
nss 3.46-1
curl 7.65.3-1
poppler-data 0.4.9-1
```https://gitlab.freedesktop.org/poppler/poppler/-/issues/825'Bogus memory allocation size' exception during image generation on a PDF2020-04-21T19:22:29ZLoickBRIOT'Bogus memory allocation size' exception during image generation on a PDFThe buggy PDF is here: [dws0rp_k.en.pdf](/uploads/d6dccbbff04801c220e8dacc29bf6c3d/dws0rp_k.en.pdf)
When it generates the image for the third page of this PDF, the program stops with the following exception:
```
Bogus memory allocation...The buggy PDF is here: [dws0rp_k.en.pdf](/uploads/d6dccbbff04801c220e8dacc29bf6c3d/dws0rp_k.en.pdf)
When it generates the image for the third page of this PDF, the program stops with the following exception:
```
Bogus memory allocation size
Syntax Error: Could not find start of jpeg data
```
I was able to reproduce this bug by using:
* the stable 'cpp' API from this file: https://gitlab.freedesktop.org/poppler/poppler/blob/master/cpp/tests/poppler-render.cpp
* the unstable 'poppler' API by using pdftocairo, pdftoppm... etchttps://gitlab.freedesktop.org/poppler/poppler/-/issues/824Cannot decrypt PDF with passwords containing special characters [åäö!"§$%&]2022-01-08T17:51:12ZleukimiCannot decrypt PDF with passwords containing special characters [åäö!"§$%&]**Summary**
Evince v3.28.4 and apparently also Okular does not open AES-256 encrypted PDF with password containing characters [åäö!"§$%&].
**Description**
Evince Document Viewer v3.28.4 (standard on Ubuntu 18.04LTS) and apparently als...**Summary**
Evince v3.28.4 and apparently also Okular does not open AES-256 encrypted PDF with password containing characters [åäö!"§$%&].
**Description**
Evince Document Viewer v3.28.4 (standard on Ubuntu 18.04LTS) and apparently also Okular, both apparently using `libpoppler`, does not open AES-256 encrypted PDF with password containing characters [åäö!"§$%&]. Firefox (and Foxit Reader) does open it. See [this](https://gitlab.gnome.org/GNOME/evince/issues/1007) and [this](https://gitlab.gnome.org/GNOME/evince/issues/1245) post about the issues that have been found. Suggestion was made to file the bug here.
Here is an output of what versions of `libpoppler` and `cups-pdf` are on the Ubuntu 18.04.3 LTS (latest) currently.
```
$ apt list --installed | grep poppler
libpoppler-glib8/bionic-updates,bionic-security,now 0.62.0-2ubuntu2.10 amd64
libpoppler73/bionic-updates,bionic-security,now 0.62.0-2ubuntu2.10 amd64
poppler-data/bionic,bionic,now 0.4.8-2 all
poppler-utils/bionic-updates,bionic-security,now 0.62.0-2ubuntu2.10 amd64
$ apt list --installed | grep cups-pdf
printer-driver-cups-pdf/bionic,now 3.0.1-5 amd64
```
Package info [printer-driver-cups-pdf 3.0.1-5](https://packages.debian.org/sid/printer-driver-cups-pdf)
Test script \[test_case_01.sh\] provided here to reproduce the issue:
```
#!/bin/bash
# test_case_01.sh
#
# Tested on GNU bash v4.4.20 on Ubuntu 18.04LTS.
# May also work on other linux releases.
# Script requires: qpdf poppler-utils printer-driver-cups-pdf cups-filters
# If not present, install it:
# sudo apt-get install qpdf poppler-utils printer-driver-cups-pdf cups-filters
# Generate a random text like lorem ipsum.
# Put the contents in a text file.
cd /tmp # directory where the three files will be created
filenametxt="foo.txt"
tr -dc a-z1-4 </dev/urandom | tr 1-2 ' \n' | awk 'length==0 || length>50' | tr 3-4 ' ' | sed 's/^ *//' | cat -s | sed 's/ / /g' | fmt | head -30 > $filenametxt
# Create a PDF file from the text file:
filenamepdf=$(basename -s .txt $filenametxt).pdf
cupsfilter -e $filenametxt > $filenamepdf
# Encrypt the PDF file and change the extension to [*_encrypted.pdf] :
userpassvar="ä" # "åäö"
ownerpassvar="å" # "åäö"
encryptedfilenamepdf=$(basename -s .txt $filenametxt)_encrypted.pdf
qpdf --encrypt $userpassvar $ownerpassvar 256 --use-aes=y -- $filenamepdf $encryptedfilenamepdf
# Show the info of the encrypted PDF:
pdfinfo -upw $userpassvar -opw $ownerpassvar $encryptedfilenamepdf
# Open the encrypted PDF with Evince and Firefox with the user/owner password.
evince $encryptedfilenamepdf &
firefox $encryptedfilenamepdf &
exit 0
```
**Result**
Evince v3.28.4 does not accept any of the passwords containing [åäö!"§$%&].
Firefox (and Foxit Reader) accepts both passwords containing [åäö!"§$%&].https://gitlab.freedesktop.org/poppler/poppler/-/issues/823An assertion error occurs when using pdftocairo to print the second page of t...2020-02-27T15:33:20ZzmmAn assertion error occurs when using pdftocairo to print the second page of the document error6.pdf[error6.pdf](/uploads/deef535e1f855584a0f9aeee270e01f0/error6.pdf)
![assertionError](/uploads/0084bcf3ac91244206527670a94794d3/assertionError.png)
![srcCode](/uploads/a9d7b13fee1e9bf8a89e3fdba45d5b44/srcCode.png)[error6.pdf](/uploads/deef535e1f855584a0f9aeee270e01f0/error6.pdf)
![assertionError](/uploads/0084bcf3ac91244206527670a94794d3/assertionError.png)
![srcCode](/uploads/a9d7b13fee1e9bf8a89e3fdba45d5b44/srcCode.png)https://gitlab.freedesktop.org/poppler/poppler/-/issues/821USE_FIXEDPOINT needs CI coverage2019-08-20T19:36:07ZAdrian BunkUSE_FIXEDPOINT needs CI coverageUSE_FIXEDPOINT seems to lack CI coverage, and is therefore breaking step by step. Known issues in OpenEmbedded are:
* https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/poppler/poppler/0002-CairoOutputDev.cc-fix-...USE_FIXEDPOINT seems to lack CI coverage, and is therefore breaking step by step. Known issues in OpenEmbedded are:
* https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/poppler/poppler/0002-CairoOutputDev.cc-fix-build-error-when-using-fixedpo.patch
* http://lists.openembedded.org/pipermail/openembedded-devel/2019-August/201265.html
USE_FIXEDPOINT needs CI coverage to catch such issues before they hit releases.
Or removal if it is no longer considered worth the effort - the Debian armel port already uses the FPU emulation for poppler, and older ARM CPUs without VFP no longer have many usecases where PDF performance matters much.https://gitlab.freedesktop.org/poppler/poppler/-/issues/820bug(pdftoppm): -: Error writing TIFF header.2020-09-23T13:58:33ZСаша Черныхbug(pdftoppm): -: Error writing TIFF header.### 1. Note
If I need post this issue to another place, please, show me this place.
### 2. Summary
I can't convert any PDF document to tif (tiff). In any case I get an error:
```text
-: Error writing TIFF header.
```
### 3. Possible...### 1. Note
If I need post this issue to another place, please, show me this place.
### 2. Summary
I can't convert any PDF document to tif (tiff). In any case I get an error:
```text
-: Error writing TIFF header.
```
### 3. Possible related issues
+ [**Bug 75969**](https://bugs.freedesktop.org/show_bug.cgi?id=75969)
+ Harsh Rai user [**reported**](http://disq.us/p/21m5qus) about this problem
### 4. Data
+ [**KiraGoddess.pdf**](https://app.box.com/s/dyunssgvwrybl5te7vq65nus4qfoeou9) — simple PDF file, that contains solely text `Kira Goddess!`.
### 5. Steps to reproduce
I download and unpack `poppler-0.68.0_x86` from [**here**](https://blog.alivate.com.au/poppler-windows/) as [**described on Stack Overflow**](https://stackoverflow.com/q/18381713/5951529) → I add `poppler-0.68.0_x86\poppler-0.68.0\bin` folder to user `PATH` environment variable → I run this command
```text
pdftoppm -tiff KiraGoddess.pdf KiraGoddess
```
### 6. Actual behavior
```text
-: Error writing TIFF header.
```
### 7. Expected behavior
Converting to JPEG successful for me.
```text
pdftoppm -jpeg KiraGoddess.pdf KiraGoddess
```
+ `KiraGoddess-1.jpg`:
![JPEG](https://i.imgur.com/uAlRJ24.jpg)
### 8. Environment
+ Windows 10 Enterprise LTSB 64-bit EN
Thanks.https://gitlab.freedesktop.org/poppler/poppler/-/issues/819Font Selection doesn't use postscript font name2022-10-10T13:09:06ZElahn IentileFont Selection doesn't use postscript font nameCurrently, poppler selects by font family name using fonts specified in the PDF. However, often PDF fonts are specified using their postscript names.
This behaviour is present in 0.62 and git d70f77ee6a1bdee8b17f08f3066c0cd685853d21. T...Currently, poppler selects by font family name using fonts specified in the PDF. However, often PDF fonts are specified using their postscript names.
This behaviour is present in 0.62 and git d70f77ee6a1bdee8b17f08f3066c0cd685853d21. Tested with fontconfig 2.12.6-0ubuntu2.
Steps to reproduce:
- Install msttcorefonts
- Download: https://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.1.pdf
- `pdffonts -subst UTN28-PlainTextMath-v3.1.pdf`:
![Screenshot_from_2019-08-19_19-30-40](/uploads/06f318c384d22e2f6716dd6c7094d96a/Screenshot_from_2019-08-19_19-30-40.png)
```bash
$ fc-match ArialMT
Vera.ttf: "Bitstream Vera Sans" "Roman"
$ fc-match :postscriptname=ArialMT
Arial.ttf: "Arial" "Regular"
$ fc-match TimesNewRomanPSMT
Vera.ttf: "Bitstream Vera Sans" "Roman"
$ fc-match :postscriptname=TimesNewRomanPSMT
Times_New_Roman.ttf: "Times New Roman" "Regular"
$ fc-match TimesNewRomanPS-ItalicMT
Vera.ttf: "Bitstream Vera Sans" "Roman"
$ fc-match :postscriptname=TimesNewRomanPS-ItalicMT
Times_New_Roman_Italic.ttf: "Times New Roman" "Italic"
```https://gitlab.freedesktop.org/poppler/poppler/-/issues/818poppler-cpp memory leaking on Windows2020-02-27T15:32:45ZJeroen Oomspoppler-cpp memory leaking on WindowsSeveral Windows users of the R bindings have [complained](https://github.com/ropensci/pdftools/issues/64) about major memory leakage and unfortunately I was able to confirm the problem. The R bindings [use the poppler-cpp interface](http...Several Windows users of the R bindings have [complained](https://github.com/ropensci/pdftools/issues/64) about major memory leakage and unfortunately I was able to confirm the problem. The R bindings [use the poppler-cpp interface](https://github.com/ropensci/pdftools/blob/master/src/bindings.cpp) and we use `mingw-w64` to build on Windows.
I have compared exactly the same code on Linux, MacOS and Windows, both with poppler 0.73.0 (our current release version). Indeed, on MacOS the memory usage is stable and on Windows it rapidly increases. I have confirmed this both with GCC 8.3.0 and GCC 4.9.3 on Windows.
From some trial and error, it seems that the issue does not appear yet when loading with `load_from_raw_data()`.
```cpp
static document *read_raw_pdf(RawVector x, std::string opw, std::string upw, bool info_only = 0){
document *doc = document::load_from_raw_data( (const char*) x.begin(), x.length(), opw, upw);
if(!doc)
throw std::runtime_error("PDF parsing failure.");
return doc;
}
```
However as soon as I read something from the document such as `doc->fonts()` or `doc->pages()`, it seems that the document starts leaking memory.
```cpp
List poppler_pdf_fonts (RawVector x, std::string opw, std::string upw) {
std::unique_ptr<poppler::document> doc(read_raw_pdf(x, opw, upw));
std::vector<font_info> fonts = doc->fonts();
...
}
```
Even after `doc` has been `delete`'d the process keeps holding on to memory. If we do this for many pdf files, we eventually run out of memory. It seems like something in the `document` is not being free'd on Windows.
Is the memory allocation in poppler different on Windows than unix? What could be causing this?https://gitlab.freedesktop.org/poppler/poppler/-/issues/817Use of uninitialized variable in pdfimages2019-08-19T22:06:44ZBowen WangUse of uninitialized variable in pdfimagesThis bug is found in git commit: d70f77ee6a1bdee8b17f08f3066c0cd685853d21
To reproduce the bug,compile poppler with MemorySanitizer.
I add following linens after project(poppler) in CMakeLists.txt:
set(CMAKE_C_FLAGS "-fsanitize=memory"...This bug is found in git commit: d70f77ee6a1bdee8b17f08f3066c0cd685853d21
To reproduce the bug,compile poppler with MemorySanitizer.
I add following linens after project(poppler) in CMakeLists.txt:
set(CMAKE_C_FLAGS "-fsanitize=memory")
set(CMAKE_CXX_FLAGS "-fsanitize=memory")
then:
mkdir build
cd build
cmake -G"Unix Makefiles" -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ..
To trigger the bug:
./pdfimages test-input output-dir/
The output information from MemorySanitizer:
==8276==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7f05d6c6e146 in void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/basic_string.tcc:211:42
#1 0x7f05d6c6e146 in void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char*>(char*, char*, std::__false_type) /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/basic_string.h:236
#2 0x7f05d6c6e146 in void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*) /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/basic_string.h:255
#3 0x7f05d6c6e146 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/basic_string.h:440
#4 0x7f05d6c6e146 in std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, UnicodeMap>::pair<UnicodeMap, true>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, UnicodeMap&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_pair.h:326
#5 0x7f05d6c6da03 in void __gnu_cxx::new_allocator<std::__detail::_Hash_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, UnicodeMap>, true> >::construct<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, UnicodeMap>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, UnicodeMap>(std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, UnicodeMap>*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, UnicodeMap&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/ext/new_allocator.h:136:23
#6 0x7f05d6c6da03 in void std::allocator_traits<std::allocator<std::__detail::_Hash_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, UnicodeMap>, true> > >::construct<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, UnicodeMap>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, UnicodeMap>(std::allocator<std::__detail::_Hash_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, UnicodeMap>, true> >&, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, UnicodeMap>*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, UnicodeMap&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/alloc_traits.h:475
#7 0x7f05d6c6da03 in std::__detail::_Hash_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, UnicodeMap>, true>* std::__detail::_Hashtable_alloc<std::allocator<std::__detail::_Hash_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, UnicodeMap>, true> > >::_M_allocate_node<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, UnicodeMap>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, UnicodeMap&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/hashtable_policy.h:2082
#8 0x7f05d6c6d523 in std::pair<std::__detail::_Node_iterator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, UnicodeMap>, false, true>, bool> std::_Hashtable<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, UnicodeMap>, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, UnicodeMap> >, std::__detail::_Select1st, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, false, true> >::_M_emplace<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, UnicodeMap>(std::integral_constant<bool, true>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, UnicodeMap&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/hashtable.h:1660:30
#9 0x7f05d6c61781 in std::pair<std::__detail::_Node_iterator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, UnicodeMap>, false, true>, bool> std::_Hashtable<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, UnicodeMap>, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, UnicodeMap> >, std::__detail::_Select1st, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, false, true> >::emplace<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, UnicodeMap>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, UnicodeMap&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/hashtable.h:748:11
#10 0x7f05d6c61781 in std::pair<std::__detail::_Node_iterator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, UnicodeMap>, false, true>, bool> std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, UnicodeMap, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, UnicodeMap> > >::emplace<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, UnicodeMap>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, UnicodeMap&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/unordered_map.h:388
#11 0x7f05d6c61781 in GlobalParams::GlobalParams(char const*) /home/user/poppler/poppler-msan-no-debug/poppler/GlobalParams.cc:439
#12 0x499fff in main /home/user/poppler/poppler-msan-no-debug/utils/pdfimages.cc:146:22
#13 0x7f05d640e09a in __libc_start_main /build/glibc-B9XfQf/glibc-2.28/csu/../csu/libc-start.c:308:16
#14 0x41f689 in _start (/home/user/poppler/poppler-msan-no-debug/build/utils/pdfimages+0x41f689)
SUMMARY: MemorySanitizer: use-of-uninitialized-value /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/basic_string.tcc:211:42 in void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag)
Exitinghttps://gitlab.freedesktop.org/poppler/poppler/-/issues/815pdftocairo gives a segmentation fault with -o on a one page document2019-12-05T23:41:00Zntoniazzipdftocairo gives a segmentation fault with -o on a one page documentWhen calling this command on a one page PDF, I get a segmentation fault (poppler 0.79):
```
$ ./pdftocairo ./input.pdf -pdf -o output.pdf
```When calling this command on a one page PDF, I get a segmentation fault (poppler 0.79):
```
$ ./pdftocairo ./input.pdf -pdf -o output.pdf
```https://gitlab.freedesktop.org/poppler/poppler/-/issues/814Manipulation of encrypted text allows plaintext revovery2020-02-20T21:31:58ZCERTManipulation of encrypted text allows plaintext revoveryWe would like to share information regarding vulnerabilities in the PDF specification which probably also impacts poppler.
Before sharing additional details (including the vulnerability report and exploits) we would like to make sure th...We would like to share information regarding vulnerabilities in the PDF specification which probably also impacts poppler.
Before sharing additional details (including the vulnerability report and exploits) we would like to make sure that this issue is not public. When creating the issue we checked the box which says "This issue is confidential and should only be visible to team members with at least Reporter access". However, when logging into gitlab.freedesktop.org for the first time we were prompted with a text including "This site and all other freedesktop.org services provide public forums: anything you publish here will be visible to anyone on the internet." Could you please confirm that the information shared in this issue is indeed not public and restricted in its visibility? Thank you.
Edit:
The attached pdfs exploit the vulnerabilities for Evince v3.22.1, v3.32.0 [exploits_evince.tgz](/uploads/f47071634e9c0b425a2d6ebb556aeda0/exploits_evince.tgz) and Okular v0.26.1, v1.7.3 [exploits_okular.tgz](/uploads/d3fd9e921cac12b6dd6281fc1d8a6a18/exploits_okular.tgz). The password for the encrypted pdf files is 'pass'. Since Evince and Okular use poppler, this might be of interest for poppler as well regarding the implementation of countermeasures. Both a maintainer of Okular and Evince agreed to share the details regarding Okular resp. Evince with poppler.
SUMMARY The attached report analyzes PDF encryption and shows two novel techniques for breaking the confidentiality of encrypted documents. [report_okular_evince.pdf](/uploads/18ec1e20c57342a03bd378a0977119a7/report_okular_evince.pdf) Note that there is a typo in the report: Evince v3.22.1 (as stated above), not v3.2.11 is affected. Also note that in addition to the versions mentioned in the report, Okular v1.7.3 and Evince v3.32.0 (as mentioned above) are vulnerable to the same vulnerabilities as described in the report as well.
Firstly, the PDF feature of partially encrypted documents is abused to wrap the encrypted part of the document within attacker-controlled content and therefore, exfiltrate the plaintext once the document is opened by a legitimate user. Secondly, abusing a flaw in the PDF encryption specification allows an attacker to arbitrarily manipulate encrypted content without knowing the corresponding key/password. The only requirement is one single block of known plaintext, which is fulfilled by design. By using exfiltration channels the attacks allow the recovery of the entire plaintext or parts of it within an encrypted document. The attacks rely only on standard compliant PDF features. The attacks described have been validated for widely used PDF viewers proofing many of them as vulnerable.
Workarounds in the various implementations may provide a short-term countermeasure. Adequate countermeasures rather need to be included as part of upcoming specifications. Therefore the issue has been escalated to the ISO working group on Crypto and Signatures and will be taken up in the next revision of the PDF Spec.
Disclosure is currently planned for the end of August 2019. Please restrain from publishing any details before that date.