poppler issueshttps://gitlab.freedesktop.org/poppler/poppler/-/issues2019-11-20T07:57:54Zhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/838evince and pdftocairo not following poppler's nor fontconfig's font substitut...2019-11-20T07:57:54ZFabian Greffrathevince and pdftocairo not following poppler's nor fontconfig's font substitution rulesHello,
I have initially filed this issue against Evince ([1] which is now confidental), but in the course of the discussion it turned out the bug is somewhere in poppler itself instead, since even its own pdftocairo renders the document...Hello,
I have initially filed this issue against Evince ([1] which is now confidental), but in the course of the discussion it turned out the bug is somewhere in poppler itself instead, since even its own pdftocairo renders the document with the same artifacts that I have seen in evince.
I have received a PDF document which is written (mostly) in Arial. No problem, I don't have Arial installed, but I have a substitution font "Arimo" available and both fontconfig and poppler are reporting they are going to use this instead of Arial:
```
$ fc-match Arial
Arimo-Regular.ttf: "Arimo" "Regular"
pdffonts test.pdf
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
Arial TrueType WinAnsi no no no 9 0
Arial,Bold TrueType WinAnsi no no no 10 0
Arial TrueType WinAnsi no no no 11 0
Arial,Bold TrueType WinAnsi no no no 12 0
Arial TrueType WinAnsi no no no 14 0
Arial TrueType WinAnsi no no no 15 0
Arial,Bold TrueType WinAnsi no no no 16 0
Arial,Bold TrueType WinAnsi no no no 20 0
3of9Barcode CID TrueType Identity-H no no yes 21 0
CourierNew TrueType WinAnsi no no no 22 0
Arial CID TrueType Identity-H no no yes 23 0
$ pdffonts -subst test.pdf
name object ID substitute font substitute font file
------------------------------------ --------- ------------------------------------ ------------------------------------
Arial 9 0 Arimo /usr/share/fonts/truetype/croscore/Arimo-Regular.ttf
Arial,Bold 10 0 Arimo Bold /usr/share/fonts/truetype/croscore/Arimo-Bold.ttf
Arial 11 0 Arimo /usr/share/fonts/truetype/croscore/Arimo-Regular.ttf
Arial,Bold 12 0 Arimo Bold /usr/share/fonts/truetype/croscore/Arimo-Bold.ttf
Arial 14 0 Arimo /usr/share/fonts/truetype/croscore/Arimo-Regular.ttf
Arial 15 0 Arimo /usr/share/fonts/truetype/croscore/Arimo-Regular.ttf
Arial,Bold 16 0 Arimo Bold /usr/share/fonts/truetype/croscore/Arimo-Bold.ttf
Arial,Bold 20 0 Arimo Bold /usr/share/fonts/truetype/croscore/Arimo-Bold.ttf
3of9Barcode 21 0 DejaVu Sans /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
CourierNew 22 0 Cousine /usr/share/fonts/truetype/croscore/Cousine-Regular.ttf
Arial 23 0 Arimo /usr/share/fonts/truetype/croscore/Arimo-Regular.ttf
```
Evince, however, does *not* use Arimo as a substitute for Arial, but NimbusSans-Regular instead which is part of the 35 Ghostscript Core fonts by URW++. This font, however, does not feature the same glyphs as Arial/Arimo, which leads to certain parts of the document being misrendered, e.g. the missing EUR currency glyph in the "Betrag in Höhe von ..." field.
![Bildschirmfoto_vom_2019-09-21_22-30-38](/uploads/32c613aa63e2030f3c3d23d658b1c98e/Bildschirmfoto_vom_2019-09-21_22-30-38.png)
![Bildschirmfoto_vom_2019-09-21_22-33-02](/uploads/c379d5fafee88848b95f8c4d16b7a27f/Bildschirmfoto_vom_2019-09-21_22-33-02.png)
The versions of all the involved packages are as follows:
```
$ dpkg -l {evince,libpoppler*,libharfbuzz*,libfontconfig*} | awk '/^ii/{print $2 " " $3}'
evince 3.32.0-2
libfontconfig1:amd64 2.13.1-2+b1
libharfbuzz-icu0:amd64 2.6.1-3
libharfbuzz0b:amd64 2.6.1-3
libpoppler-cpp0v5:amd64 0.71.0-5+b1
libpoppler-glib8:amd64 0.71.0-5+b1
libpoppler82:amd64 0.71.0-5+b1
```
In the original evince bug report, Jason Crane stated the following:
"
Jason Crain
Jason Crain @jcrain · 1 month ago
Developer
I think I see what poppler is doing. It defines Arial as being an alias for Helvetica, so it searches for Helvetica instead.
I'm going to guess that your PDF is "broken", at least I would probably consider it broken, since it has probably embedded Arial glyph IDs and is using those to look up glyphs. I'm not sure if even Arimo has that level of compatibility with Arial, so possibly the only way it would render correctly is if it uses the real Arial font.
"
I am attaching the document here. After all, it's just a repair invoice for my coffee machine. However, it contains my full postal address, so if you could please mark this issue as confidental, that would be appreciated. Thanks!
- Fabian
https://gitlab.gnome.org/GNOME/evince/issues/1257https://gitlab.freedesktop.org/poppler/poppler/-/issues/837Annotation not shown due to obsolete generation number in indirect reference2019-11-16T09:41:51ZTobias DeimingerAnnotation not shown due to obsolete generation number in indirect referenceThis is a follow up to a part of [Okular bug 413819](https://bugs.kde.org/show_bug.cgi?id=413819), where Poppler fails to load an annotation due to an "outdated" generation number in an indirect reference by `/Annots`. Mupdf and Foxit ma...This is a follow up to a part of [Okular bug 413819](https://bugs.kde.org/show_bug.cgi?id=413819), where Poppler fails to load an annotation due to an "outdated" generation number in an indirect reference by `/Annots`. Mupdf and Foxit manage to load the annotation regardless of the wrong reference.
[This file](https://bugs.kde.org/attachment.cgi?id=123763) was last saved by Foxit. We see page 1 holds an indirect reference `74 0 R` to a Highlight Annotation, but the actual Highlight Annotation object has newer ID `74 1` (it's linking back correctly to page 1 via `/P`).
```
74 1 obj
<< /P 1 0 R ... /Type/Annot/Subtype/Highlight >>
```
```
75 0 obj
[ 74 0 R 78 0 R 80 0 R 81 0 R 82 0 R 87 0 R ]
endobj
```
All objects start with generation 0 in a new document. Obviously the generation got somehow increased to 1, which could be the result of a delete and recreate operation. Whatever software did it, it forgot to update page 1 `/Annots`. The array still references the Highlight Annotation using the old generation number `74 0`.
In consequence, and IMO expected, Okular, PDF.js and qpdf fail to find and show that annotation. Somewhat surprisingly, Foxit and Mupdf manage to display it.
I'm interessted in your opionions whether it's worth to consider a workaround.
- Maybe be less strict about generation number matching in `XRef::fetch(int num, int gen, int recursion)`?
- Or maybe something like a reverse lookup, like "find all /Type /Annot objects in the document, then look at their /P and add them to the referenced page"?
- Or shall we just close the issue because the root cause is an inconsistent document?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/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/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/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.https://gitlab.freedesktop.org/poppler/poppler/-/issues/813pdfsig not run in apache php shell_exec2019-08-06T12:34:05ZFogler Tibor (Utopszkij)pdfsig not run in apache php shell_execHello.
My system is Linux Mind 19, apache 2.4.29, php 7.0, pdfsig 0.62.
The pdfsig working good in command line.
But if it is run in apache /php /shell_execute then i get error:
Internal Error (0): couldn't find default Firefox...Hello.
My system is Linux Mind 19, apache 2.4.29, php 7.0, pdfsig 0.62.
The pdfsig working good in command line.
But if it is run in apache /php /shell_execute then i get error:
Internal Error (0): couldn't find default Firefox Folder
Segmentation fault
(pdfsig -h and pdfsig signed.pdf command too.)
php code:
```
<?php
....
$out = shell_exec('pdfsig signed.pdf 2>&1');
....
?>
```
[signed.pdf](/uploads/c1375947b71cb60697fe98254e48288f/signed.pdf)
It is a web server, not installed firefox browser.
Apache run by "www-data" user. The "/home/www-data" folder not exists.
Thans!https://gitlab.freedesktop.org/poppler/poppler/-/issues/812text().to_latin1() returns invalid STL string with zero bytes inside of it2019-08-05T18:19:00Zyuri@FreeBSDtext().to_latin1() returns invalid STL string with zero bytes inside of itI use this program to convert the pdf document to text:
```
#include <iostream>
#include "poppler-document.h"
#include "poppler-page.h"
using namespace std;
int main(int argc, char *argv[]) {
poppler::document *doc = poppler::document...I use this program to convert the pdf document to text:
```
#include <iostream>
#include "poppler-document.h"
#include "poppler-page.h"
using namespace std;
int main(int argc, char *argv[]) {
poppler::document *doc = poppler::document::load_from_file(argv[1]);
const int pagesNbr = doc->pages();
cout << "page count: " << pagesNbr << endl;
for (int i = 0; i < pagesNbr; i++) {
cout << "page " << (i+1) << " of " << pagesNbr << endl;
cout << doc->create_page(i)->text().to_latin1() << endl; // STL string
//cout << doc->create_page(i)->text().to_latin1().c_str() << endl; // C-string pointer in the same STL string
}
}
```
The document can be downloaded from here: http://sci-hub.tw/10.1016/j.cell.2018.03.006
I use the program above that prints ```text().to_latin1()``` and its variation that prints ```text().to_latin1().c_str()```. The results differ on the page 23.
The attached screenshot has both programs' outputs comparison in the hex format.
```text().to_latin1()``` returns the zero byte that gets printed into the output, see the left side of the attached screenshot, and the right side has the corresponding C-string that treats this zero byte as a termination character.
The outputs should be identical because zero byte isn't allowed in std::string, but poppler returns it anyway, which is a bug.
![image](/uploads/2e2cce6e4a08aaf91c1a68613e97b277/image.png)
poppler-0.77.0 on FreeBSD 12 amd64, installed from the package.https://gitlab.freedesktop.org/poppler/poppler/-/issues/811okular (poppler) segfaults when opening a digitally signed pdf2019-08-06T07:55:30ZJiri Slabyokular (poppler) segfaults when opening a digitally signed pdfThe backtrace is below. `subjectDN` is NULL as can be seen. It is enough to open [vypis_z_KN.pdf](/uploads/e68a14b43b5281ee9f68846dd114621e/vypis_z_KN.pdf) in okular.
```
#0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:...The backtrace is below. `subjectDN` is NULL as can be seen. It is enough to open [vypis_z_KN.pdf](/uploads/e68a14b43b5281ee9f68846dd114621e/vypis_z_KN.pdf) in okular.
```
#0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
#1 0x00007ffff7e68daf in __GI___strdup (s=s@entry=0x0) at strdup.c:41
#2 0x00007fffe861241d in SignatureInfo::setSubjectDN (this=0x555555db9ae0, subjectDN=0x0) at /usr/src/debug/poppler-0.72.0-1.6.x86_64/poppler/SignatureInfo.cc:127
#3 0x00007fffe868fc23 in FormFieldSignature::validateSignature (forceRevalidation=<optimized out>, validationTime=4294967295, doVerifyCert=true, this=0x555555dbadc0)
at /usr/src/debug/poppler-0.72.0-1.6.x86_64/poppler/Form.cc:1750
#4 FormFieldSignature::validateSignature (this=0x555555dbadc0, doVerifyCert=<optimized out>, forceRevalidation=<optimized out>, validationTime=4294967295)
at /usr/src/debug/poppler-0.72.0-1.6.x86_64/poppler/Form.cc:1690
#5 0x00007fffe87e36e4 in Poppler::FormFieldSignature::validate (this=this@entry=0x555555dbb300, opt=opt@entry=1, validationTime=...)
at /usr/src/debug/poppler-qt5-0.72.0-1.6.x86_64/qt5/src/poppler-form.cc:681
#6 0x00007fffe87e3c30 in Poppler::FormFieldSignature::validate (this=0x555555dbb300, opt=opt@entry=Poppler::FormFieldSignature::ValidateVerifyCertificate)
at /usr/src/debug/poppler-qt5-0.72.0-1.6.x86_64/qt5/src/poppler-form.cc:674
#7 0x00007fffe886b937 in PopplerFormFieldSignature::PopplerFormFieldSignature (field=0x555555dbb300, this=0x555555dbaf80)
at /usr/src/debug/okular-19.04.3-1.1.x86_64/generators/poppler/formfields.cpp:387
#8 PDFGenerator::addFormFields (this=<optimized out>, page=<optimized out>, popplerPage=<optimized out>) at /usr/src/debug/okular-19.04.3-1.1.x86_64/generators/poppler/generator_pdf.cpp:1983
#9 PDFGenerator::loadPages (rotation=0, clear=false, pagesVector=..., this=0x555555dbb300) at /usr/src/debug/okular-19.04.3-1.1.x86_64/generators/poppler/generator_pdf.cpp:792
#10 PDFGenerator::init (this=this@entry=0x555555d78c20, pagesVector=..., password=...) at /usr/src/debug/okular-19.04.3-1.1.x86_64/generators/poppler/generator_pdf.cpp:688
#11 0x00007fffe886bf58 in PDFGenerator::loadDocumentWithPassword (this=0x555555d78c20, filePath=..., pagesVector=..., password=...)
at /usr/src/debug/okular-19.04.3-1.1.x86_64/generators/poppler/generator_pdf.cpp:643
#12 0x00007ffff04c8cbc in Okular::DocumentPrivate::openDocumentInternal (this=0x555555589610, offer=..., isstdin=<optimized out>, docFile=..., filedata=..., password=...)
at /usr/src/debug/okular-19.04.3-1.1.x86_64/core/document.cpp:875
#13 0x00007ffff04be881 in Okular::Document::openDocument (this=this@entry=0x555555688190, docFile=..., url=..., _mime=..., password=...)
at /usr/src/debug/okular-19.04.3-1.1.x86_64/core/document.cpp:2446
#14 0x00007ffff065d255 in Okular::Part::doOpenFile (this=this@entry=0x555555775430, mimeA=..., fileNameToOpenA=..., isCompressedFile=isCompressedFile@entry=0x7fffffffd6c7)
at /usr/src/debug/okular-19.04.3-1.1.x86_64/part.cpp:1415
#15 0x00007ffff06608fb in Okular::Part::openFile (this=0x555555775430) at /usr/src/debug/okular-19.04.3-1.1.x86_64/part.cpp:1549
#16 0x00007ffff7dc610c in ?? () from /usr/lib64/libKF5Parts.so.5
#17 0x00007ffff7dc696f in KParts::ReadOnlyPart::openUrl(QUrl const&) () from /usr/lib64/libKF5Parts.so.5
#18 0x00007ffff065cc56 in Okular::Part::openUrl (this=0x555555775430, _url=..., swapInsteadOfOpening=<optimized out>) at /usr/src/debug/okular-19.04.3-1.1.x86_64/part.cpp:1755
#19 0x000055555556b190 in Shell::openUrl (this=0x5555557123f0, url=..., serializedOptions=...) at /usr/src/debug/okular-19.04.3-1.1.x86_64/shell/shell.cpp:280
#20 0x000055555556b497 in Shell::openDocument (this=0x5555557123f0, url=..., serializedOptions=...) at /usr/src/debug/okular-19.04.3-1.1.x86_64/shell/shell.cpp:221
#21 0x0000555555562a93 in Shell::openDocument (serializedOptions=..., url=..., this=0x5555557123f0) at /usr/src/debug/okular-19.04.3-1.1.x86_64/shell/okular_main.cpp:171
#22 Okular::main (serializedOptions=..., paths=...) at /usr/src/debug/okular-19.04.3-1.1.x86_64/shell/okular_main.cpp:176
#23 main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/okular-19.04.3-1.1.x86_64/shell/main.cpp:77
```https://gitlab.freedesktop.org/poppler/poppler/-/issues/809Can't render text in pdf correctly2019-07-27T22:47:41ZRobert SchultzCan't render text in pdf correctlyA pdf file created by a collaborator using WordPerfect 8 does not render correctly in Linux, namely Atril, Evince, Okular under F30. Renders perfectly on original author's various Adobe readers under W7, and with Adobe on Mac. Renders in...A pdf file created by a collaborator using WordPerfect 8 does not render correctly in Linux, namely Atril, Evince, Okular under F30. Renders perfectly on original author's various Adobe readers under W7, and with Adobe on Mac. Renders incorrectly on default Ubuntu pdf reader. Renders significantly better on F30 using free PDFStudioViewer, and ok using Master PDF Editor 5. Extracted section of pdf with bad rendering text attached for reference.[bad-rendering.pdf](/uploads/06175331f3e95d6f5e0355f8d423427e/bad-rendering.pdf) Examination using MasterPDF Editor seems to indicate that WP8 composes text in "ransom note" format, each character separately, rather than a standard PS-like string. Could possibly be part of an underlying problem, along with incorrect fonts.https://gitlab.freedesktop.org/poppler/poppler/-/issues/808Pdftocairo has problems with some PDF files2022-10-12T11:49:01ZzmmPdftocairo has problems with some PDF files
hi, friends, I found that some PDF files print differently than they appear. May I ask who can help me?
Commands:
pdftocairo -svg bill2.pdf bill2_poppler.svg
pdftocairo -printdlg bill2.pdf
os: windows7
poppler's version: all
cairo'...
hi, friends, I found that some PDF files print differently than they appear. May I ask who can help me?
Commands:
pdftocairo -svg bill2.pdf bill2_poppler.svg
pdftocairo -printdlg bill2.pdf
os: windows7
poppler's version: all
cairo's version: all
[bill2.pdf](/uploads/683c1f36d6200bf2d1e275e5ae548d1c/bill2.pdf)
[bill2_A4_Nearest.xps](/uploads/69674f90c7075822ec30a34b0cb6d435/bill2_A4_Nearest.xps)
![bill2_poppler.svg](/uploads/aecaf3923b69e1544912946cb30fe17c/bill2_poppler.svg)https://gitlab.freedesktop.org/poppler/poppler/-/issues/806okular cant properly display pdf2020-10-31T01:04:09ZCat22okular cant properly display pdfI receive weekly PDF reports from TD Ameritrade but the text is always either mangled or missing or both. See attached pdf
**Check the second table in the pdf**
[weekly-summary.pdf](/uploads/76c34470d317cff44d40f3a3eb52bf85/weekly-summar...I receive weekly PDF reports from TD Ameritrade but the text is always either mangled or missing or both. See attached pdf
**Check the second table in the pdf**
[weekly-summary.pdf](/uploads/76c34470d317cff44d40f3a3eb52bf85/weekly-summary.pdf)
please see this for more info:
https://bugs.kde.org/show_bug.cgi?id=403627