poppler issueshttps://gitlab.freedesktop.org/poppler/poppler/-/issues2024-03-24T21:08:42Zhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/992Transparency rendered opaque2024-03-24T21:08:42ZTilman HausherrTransparency rendered opaquefile is from https://bugs.ghostscript.com/show_bug.cgi?id=697425
[gs-bugzilla697425.pdf](/uploads/5ca1abdda2bdf1df1a4b5d026ba16b24/gs-bugzilla697425.pdf)
see the yellow marked text
Expected rendering (pdftoppm):
![gs-bugzilla697425.pdf...file is from https://bugs.ghostscript.com/show_bug.cgi?id=697425
[gs-bugzilla697425.pdf](/uploads/5ca1abdda2bdf1df1a4b5d026ba16b24/gs-bugzilla697425.pdf)
see the yellow marked text
Expected rendering (pdftoppm):
![gs-bugzilla697425.pdf-1](/uploads/1341bf49f0ce6bdbcbe7fab2dd27aa19/gs-bugzilla697425.pdf-1.png)
Actual rendering (pdftocairo, version 0.88.0 of cygwin):
![gs-bugzilla697425.pdf-1](/uploads/e41a7c174c109caa5f3bef743dace1f1/gs-bugzilla697425.pdf-1.png)https://gitlab.freedesktop.org/poppler/poppler/-/issues/991pdftocairo fails to convert a specific PDF2022-06-27T19:15:18ZShai4shepdftocairo fails to convert a specific PDFsample pdf: https://www.math.ku.dk/english/research-files/conference-papers/CopenhagenD-Tuesday.pdf
```
pdftocairo -png -f 1 -l 1 CopenhagenD-Thursday.pdf
```
gets nothing, while
```
pdftoppm -png -f 1 -l 1 CopenhagenD-Thursday.pdf
```
...sample pdf: https://www.math.ku.dk/english/research-files/conference-papers/CopenhagenD-Tuesday.pdf
```
pdftocairo -png -f 1 -l 1 CopenhagenD-Thursday.pdf
```
gets nothing, while
```
pdftoppm -png -f 1 -l 1 CopenhagenD-Thursday.pdf
```
gets the correct image.
Reference: https://gitlab.gnome.org/GNOME/evince/-/issues/1517#note_960597https://gitlab.freedesktop.org/poppler/poppler/-/issues/985Unable to convert PDF to TIFF using pdftocairo2020-11-09T21:06:19Zyogi2806Unable to convert PDF to TIFF using pdftocairoTried to use this command in **windows **system using version **poppler-20.11.0** loading:
pdftocairo.exe test.pdf -tiff which generates same output like test.tif file with 0kb.
I was using pdf2Image lib even this lib does the same thi...Tried to use this command in **windows **system using version **poppler-20.11.0** loading:
pdftocairo.exe test.pdf -tiff which generates same output like test.tif file with 0kb.
I was using pdf2Image lib even this lib does the same thing and they wanted to contact you on this issue. Kindly help me out to fix the issue.https://gitlab.freedesktop.org/poppler/poppler/-/issues/982Decide on linking & packaging for backends2020-11-13T04:09:18ZKyle AubleDecide on linking & packaging for backendsThis issue is a spin-off of #335 to focus on Cairo & Splash separately from the front-ends.
This [mail-list conversation](https://lists.freedesktop.org/archives/poppler/2018-February/012813.html) suggested dropping the orphaned .pc file...This issue is a spin-off of #335 to focus on Cairo & Splash separately from the front-ends.
This [mail-list conversation](https://lists.freedesktop.org/archives/poppler/2018-February/012813.html) suggested dropping the orphaned .pc files and keeping the back-ends private. More recently though, #83 was settled by providing the Cairo headers as an unstable API. At least Debian provides both the Splash & Cairo headers (and then some?) in a `libpoppler-private-dev` package too.
There is also a suggestion from the email to build the Cairo back-end as a distinct library & allow linking it statically.
I can think of the following questions (and changes when needed) to settle everything:
- ~~Should Cairo have its own folder like Splash?~~ Not necessary
- Should Cairo & Splash be built more modularly (distinct CMakeLists, compile to static libraries)?
- ~~Should the .pc files be dropped or updated for downstream (add *-uninstalled.pc files if keeping)?~~ Dropped
- ~~Exactly which files should be included in these dev packages (just module-specific headers)?~~ Packaging back-ends discouraged
Possible tags: [build system][cairo][splash]https://gitlab.freedesktop.org/poppler/poppler/-/issues/978Very slow rendering of file with pattern reuse2020-10-31T03:42:24ZTilman HausherrVery slow rendering of file with pattern reuse[gs-bugzilla692158-schleuse-veryslow.pdf](/uploads/f538f137fff13ac7df8775587d78c292/gs-bugzilla692158-schleuse-veryslow.pdf)
file is from ghostscript: https://bugs.ghostscript.com/show_bug.cgi?id=692158
I am using version 0.88.0 of cyg...[gs-bugzilla692158-schleuse-veryslow.pdf](/uploads/f538f137fff13ac7df8775587d78c292/gs-bugzilla692158-schleuse-veryslow.pdf)
file is from ghostscript: https://bugs.ghostscript.com/show_bug.cgi?id=692158
I am using version 0.88.0 of cygwin.
The rendering has been running for at least an hour.
There are 20 patterns, but these are reused a lot.https://gitlab.freedesktop.org/poppler/poppler/-/issues/977Wrong rendering of PDF with 16 bpc image Flate compressed with predictor2020-10-31T03:43:42ZTilman HausherrWrong rendering of PDF with 16 bpc image Flate compressed with predictor[GWG181_16Bit_CMYK_X4.pdf](/uploads/05dcea9eba213eb0ccf443af64b3fcc1/GWG181_16Bit_CMYK_X4.pdf)
Expected rendering:
![GWG181_16Bit_CMYK_X4-1](/uploads/44f47e324a87212b34394815e0a6e9bf/GWG181_16Bit_CMYK_X4-1.png)
Actual rendering (pdfto...[GWG181_16Bit_CMYK_X4.pdf](/uploads/05dcea9eba213eb0ccf443af64b3fcc1/GWG181_16Bit_CMYK_X4.pdf)
Expected rendering:
![GWG181_16Bit_CMYK_X4-1](/uploads/44f47e324a87212b34394815e0a6e9bf/GWG181_16Bit_CMYK_X4-1.png)
Actual rendering (pdftoppm):
![GWG181_16Bit_CMYK_X4-1](/uploads/897a8add7f70c3c306a2702073907120/GWG181_16Bit_CMYK_X4-1.png)
I am using version 0.88.0 of cygwin.https://gitlab.freedesktop.org/poppler/poppler/-/issues/975Partially transparent images lead to artifacts2024-03-25T11:54:24ZRalf JungPartially transparent images lead to artifactsTo reproduce this problem, take some PDF file and then use Xournal to add a PNG file with alpha channel. That can result in a file like this: [dummy-a.pdf](/uploads/cbb0175a7daa70987802e4eeee217afd/dummy-a.pdf).
When opening this file i...To reproduce this problem, take some PDF file and then use Xournal to add a PNG file with alpha channel. That can result in a file like this: [dummy-a.pdf](/uploads/cbb0175a7daa70987802e4eeee217afd/dummy-a.pdf).
When opening this file in a poppler-based viewer such as Okular or Evince, it shows a border around the opaque part of the embedded image:
![poppler](/uploads/ad46e8bd685a390c66842726134bc448/poppler.png)
I first thought this was a [Xournal bug](https://sourceforge.net/p/xournal/bugs/215/), but the developer says they are not adding any kind of border, and indeed Firefox shows no such artifact when opening the same PDF file:
![firefox](/uploads/0161a562461980a67c5e96c1a8b3941e/firefox.png)
I am no PDF expert, but the Xournal developer says this might indicate a sub-pixel misalignment of the "soft mask" associated with the embedded image, and maybe there's something poppler can do to render these files better, the way Firefox does.
Okular says "Using Poppler 20.09.0".https://gitlab.freedesktop.org/poppler/poppler/-/issues/974Implement support for /PrintState of a layer2020-10-28T11:16:29ZTomasz KaźmierczakImplement support for /PrintState of a layerA layer in PDF (or rather, more generally, an Optional Content Group, OCG) can have a flag saying that it is not intended for printing, for instance:
```
34 0 obj
<<
/Type /OCG
/Name <FEFF006B006F006C006F0072002000740142006100200028006E...A layer in PDF (or rather, more generally, an Optional Content Group, OCG) can have a flag saying that it is not intended for printing, for instance:
```
34 0 obj
<<
/Type /OCG
/Name <FEFF006B006F006C006F0072002000740142006100200028006E00690065006400720075006B006F00770061006E00790029>
/Usage <</Print <</PrintState /OFF>> /View <</ViewState /ON>>>>
>>
```
You can see the **/PrintState /OFF** entry in the /Print dictionary.
When I print a file containing the above defined layer (app: Okular, libpoppler: 0.86.1), the setting seems to be ignored and the layer gets printed.
Please implement support for print disabling for OCGs.https://gitlab.freedesktop.org/poppler/poppler/-/issues/971Requested CMAKE_C*_FLAGS are not used2020-11-11T08:15:25ZMartin ŘehákRequested CMAKE_C*_FLAGS are not used-DCMAKE_CXX_FLAGS="-m32" doesn't work for poppler-20.10.0 on Solaris but I believe it is platform independent. 0.87.0 worked well. This is how configure fails:
```
-- The C compiler identification is GNU 9.3.0
-- The CXX compiler identi...-DCMAKE_CXX_FLAGS="-m32" doesn't work for poppler-20.10.0 on Solaris but I believe it is platform independent. 0.87.0 worked well. This is how configure fails:
```
-- The C compiler identification is GNU 9.3.0
-- The CXX compiler identification is GNU 9.3.0
-- Check for working C compiler: /usr/gcc/9/bin/gcc
-- Check for working C compiler: /usr/gcc/9/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/gcc/9/bin/g++
-- Check for working CXX compiler: /usr/gcc/9/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 - Failed
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29")
-- Looking for pthread.h
-- Looking for pthread.h - not found
-- Could NOT find Threads (missing: Threads_FOUND)
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - not found
-- Looking for stdint.h
-- Looking for stdint.h - not found
-- Looking for stddef.h
-- Looking for stddef.h - not 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-3.15/Modules/TestBigEndian.cmake:50 (message):
no suitable type found
Call Stack (most recent call first):
CMakeLists.txt:21 (test_big_endian)
```
And this is the particular error:
```
Performing C++ SOURCE FILE Test GCC_HAS_AS_NEEDED failed with the following output:
Change Dir: /builds/mrehak/workspace/poppler/components/desktop/poppler/build/i86/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/gnu/bin/make cmTC_fab48/fast && /usr/gnu/bin/make -f CMakeFiles/cmTC_fab48.dir/build.make CMakeFiles/cmTC_fab48.dir/build
make[1]: Entering directory '/builds/mrehak/workspace/poppler/components/desktop/poppler/build/i86/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_fab48.dir/src.cxx.o
/usr/gcc/9/bin/g++ -fno-exceptions -fno-check-new -fno-common -D_DEFAULT_SOURCE -DGCC_HAS_AS_NEEDED -o CMakeFiles/cmTC_fab48.dir/src.cxx.o -c /builds/mrehak/workspace/poppler/components/desktop/poppler/build/i86/CMakeFiles/CMakeTmp/src.cxx
Linking CXX executable cmTC_fab48
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_fab48.dir/link.txt --verbose=1
/usr/gcc/9/bin/g++ -fno-exceptions -fno-check-new -fno-common -D_DEFAULT_SOURCE -DGCC_HAS_AS_NEEDED -m32 CMakeFiles/cmTC_fab48.dir/src.cxx.o -o cmTC_fab48 -Wl,--as-needed
ld: fatal: file CMakeFiles/cmTC_fab48.dir/src.cxx.o: wrong ELF class: ELFCLASS64
collect2: error: ld returned 1 exit status
make[1]: *** [CMakeFiles/cmTC_fab48.dir/build.make:87: cmTC_fab48] Error 1
make[1]: Leaving directory '/builds/mrehak/workspace/poppler/components/desktop/poppler/build/i86/CMakeFiles/CMakeTmp'
make: *** [Makefile:121: cmTC_fab48/fast] Error 2
```[00-poppler-macros.patch](/uploads/0e7ba077ae32c87d22c898134bd9b60e/00-poppler-macros.patch)
I have resolved it by attached patch. Please consider it for integration.
Thank you.https://gitlab.freedesktop.org/poppler/poppler/-/issues/970Bad font rendering without anti-aliasing2020-10-21T15:56:23ZLennart AckermansBad font rendering without anti-aliasingIt seems we are in a minority, but many people can't stand anti-aliased fonts. Unfortunately, non-antialiased font rendering is extremely ugly in poppler-based pdf viewers, on both viewers using the Cairo and Splash backend. I'm not sure...It seems we are in a minority, but many people can't stand anti-aliased fonts. Unfortunately, non-antialiased font rendering is extremely ugly in poppler-based pdf viewers, on both viewers using the Cairo and Splash backend. I'm not sure if the issue is with poppler but hopefully someone can point this out.
Adobe reader does a much better job. The following examples are screenshots from acroread and qpdfview with Splash backend.
![sample1](/uploads/a8a30505d5a452f22ce7f8c3ae04141b/sample1.png)
System font rendering on Mate (using Cairo?) makes beautiful sharp text, so why can't poppler make them? The following larger examples are from acroread, Pluma on Mate, pdftocairo and qpdfview with Splash backend.
![sample2](/uploads/4bccb9a1832f2a64f2ca6768592243a7/sample2.png)
See the source pdf:
[test.pdf](/uploads/38ba5b052a421f33ea61256f003751c7/test.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/968make fails on debian with fuzzers enabled2020-10-09T19:37:04ZCeyhun Alpmake fails on debian with fuzzers enabledI'm trying to build poppler with fuzz testing enabled. I follow the instructions in INSTALL so I installed the extra cmake modules and I'm running the following commands:
```
mkdir build
cd build
cmake .. -DCMAKE_CXX_COMPILER=clang++ -D...I'm trying to build poppler with fuzz testing enabled. I follow the instructions in INSTALL so I installed the extra cmake modules and I'm running the following commands:
```
mkdir build
cd build
cmake .. -DCMAKE_CXX_COMPILER=clang++ -DENABLE_FUZZER=ON -DECM_ENABLE_SANITIZERS='fuzzer;address' -DCMAKE_C_FLAGS='-fPIE'
make
```
However, `make` fails with the following error:
```
/usr/bin/ld: CMakeFiles/pdftoppm.dir/pdftoppm.cc.o: in function `main':
/usr/local/google/home/ceyhunalp/workspace/poppler/utils/pdftoppm.cc:369: multiple definition of `main'; /usr/lib/llvm-9/lib/clang/9.0.1/lib/linux/libclang_rt.fuzzer-x86_64.a(fuzzer.o):(.text.main+0x0): first defined here
/usr/bin/ld: /usr/lib/llvm-9/lib/clang/9.0.1/lib/linux/libclang_rt.fuzzer-x86_64.a(fuzzer.o): in function `main':
(.text.main+0x12): undefined reference to `LLVMFuzzerTestOneInput'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [utils/CMakeFiles/pdftoppm.dir/build.make:115: utils/pdftoppm] Error 1
make[1]: *** [CMakeFiles/Makefile2:315: utils/CMakeFiles/pdftoppm.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
```
I was able to work around this issue by running `make pdf_fuzzer` instead but it would be good to understand why poppler fails. Any ideas?https://gitlab.freedesktop.org/poppler/poppler/-/issues/965PDF Display completely messed up with various software (inkscape, firefox, gn...2020-10-02T22:25:28Z8FordPrefect8PDF Display completely messed up with various software (inkscape, firefox, gnome document viewer, libre office)I have a problem with various documents from my thesis from some years ago. They were created 2017 with inkscape under windows and currently the only software displaying them proper so far I tested was chromium. The degree of missing ite...I have a problem with various documents from my thesis from some years ago. They were created 2017 with inkscape under windows and currently the only software displaying them proper so far I tested was chromium. The degree of missing items and kind of problems vary with different software.
I think that might trace back to transparency. But I am not sure. I can provide a sample file, but I don't know whether I can upload it here to public access. I really don't want to accidentally create a copy right issue.https://gitlab.freedesktop.org/poppler/poppler/-/issues/960SVG text is corrupted after pdftocairo2021-06-13T21:53:22ZArtur MogozovSVG text is corrupted after pdftocairoWhen attached [input.pdf](/uploads/ca95f39965a335ded93e934c0d384438/input.pdf) is processed via pdftocairo to svg, text part of output looks misplaced in editing apps like adobe illustrator or figma, screenshot: ![image__1_](/uploads/858...When attached [input.pdf](/uploads/ca95f39965a335ded93e934c0d384438/input.pdf) is processed via pdftocairo to svg, text part of output looks misplaced in editing apps like adobe illustrator or figma, screenshot: ![image__1_](/uploads/8588d4bcf4611c9256d37ec122846d73/image__1_.png)
but looks fine in Firefox and Chrome.
Both pdftocairo 20.09 (mac) and 0.62 (ubuntu 18.04) are having this issue.
Is this a problem with original pdf or pdftocairo?https://gitlab.freedesktop.org/poppler/poppler/-/issues/955Transition to built-in cmake find modules2020-09-05T11:59:10ZKyle AubleTransition to built-in cmake find modulesHi, long-time Poppler user here that's looking to help out some & refresh my c++ skills.
To start, I'm just playing with the various build options and taking notes. One thing I've noticed is the build-system uses some custom find module...Hi, long-time Poppler user here that's looking to help out some & refresh my c++ skills.
To start, I'm just playing with the various build options and taking notes. One thing I've noticed is the build-system uses some custom find modules & commands that CMake now has built-in versions of: [cmake-modules, current release](https://cmake.org/cmake/help/latest/manual/cmake-modules.7.html)
After looking into the details, this is what I had in mind...
| Custom | Built-in | Supported since CMake v.? | Approach | Note |
| ------ | ------ | ------ | ------ | ------ |
| find_package(PkgConfig) | include(FindPkgConfig) | 2.6 or earlier | Consolidate in CMakeLists.txt | Keep optional for basic build? |
| FindFontconfig.cmake | include(FindFontconfig) | 3.14 | Wrap include in CMake version if-else for now | |
| FindIconv.cmake | include(FindIconv) | 3.11 | Wrap include in CMake version if-else for now | Still must set CONST flag separately |
It's just minor refactoring, but I already have one patch that passed a clean configure, build, and unit-test locally. If there's any interest, I can get a full merge-request ready. Just to check too, are contributors normally expected to test locally with multiple platforms or ad-hoc test-cases before trying CI?
Possible tags: [build-system][minor][patch][refactoring]https://gitlab.freedesktop.org/poppler/poppler/-/issues/954Straight line not rendered at rotation=452020-08-28T22:18:12ZThorsten WißmannStraight line not rendered at rotation=45Depending on the zoom level, evince and pdftocairo do not render the PDF correctly ([this PDF](/uploads/8c904bcc107441ce789f9d2de97464e2/linemissingmwe.pdf)) which is generated from the following latex source:
```latex
\documentclass[a4p...Depending on the zoom level, evince and pdftocairo do not render the PDF correctly ([this PDF](/uploads/8c904bcc107441ce789f9d2de97464e2/linemissingmwe.pdf)) which is generated from the following latex source:
```latex
\documentclass[a4paper]{article}
\usepackage{tikz,geometry}
\begin{document}
Depending on the zoom level, the line in the following box is
rendered or not:
\begin{tikzpicture}
\node[draw,rotate=45] {
\begin{tikzpicture}
\draw[-] (0cm,0cm) -- (1cm,0cm);
\end{tikzpicture}
};
\end{tikzpicture}
The issue does not arise with other rotation angles.
\end{document}
```
In order to reproduce, compile the above `linemissingmwe.tex` and render it at different resolutions via pdftocairo:
```bash
pdflatex linemissingmwe.tex
pdftocairo -r 127 -png linemissingmwe.pdf zoom-127 # hides the line
pdftocairo -r 128 -png linemissingmwe.pdf zoom-128 # shows the line
```
![comparison](/uploads/b75e3aab16c0281373a0f42f912265b2/comparison.png)
All resolutions lower than 127 seem to hide the line, and all resultions higher
than 128 render it correctly. I am using the following poppler version on arch linux:
```
$ pdftocairo -v
pdftocairo version 0.90.1
Copyright 2005-2020 The Poppler Developers - http://poppler.freedesktop.org
Copyright 1996-2011 Glyph & Cog, LLC
```
The issue only arises in pdftocairo and evince (version 3.36.7 here), but not in other poppler-based pdf viewers (okular, katarakt are both fine); pdftoppm (0.90.1) also shows the line consistently.
Experimenting with the latex source, I found out that it is really crucial here that the rotation is 45 here.
I don't know how this might be related to other misrendering issues of the cairo backend. Even if this is a duplicate, I hope this issue is helpful because the minimal working example is smaller than the other PDFs I've seen when looking through the existing issues for a possible duplicate.https://gitlab.freedesktop.org/poppler/poppler/-/issues/953Cairo backend loses gradient-filled rectangle when converting PDF to PNG / JPEG2020-08-27T19:41:28ZMatt DoddsCairo backend loses gradient-filled rectangle when converting PDF to PNG / JPEGHello,
We use `pdftocairo` version `0.90.1` to automate conversions from PDF document to PNG or JPEG. One customer document has been flagged up where a gradient-filled rectangle is missing from the converted image.
I've attached the so...Hello,
We use `pdftocairo` version `0.90.1` to automate conversions from PDF document to PNG or JPEG. One customer document has been flagged up where a gradient-filled rectangle is missing from the converted image.
I've attached the source and resulting PNG. Maybe someone can identify what's going wrong.
Many thanks
Matt
![AnonSlide.pdf](/uploads/6d4e028b38898b8d19a70610825e429b/AnonSlide.pdf)
![AnonSlide-1](/uploads/ff25f030acd1db0bebb62cc5637c59bf/AnonSlide-1.png)https://gitlab.freedesktop.org/poppler/poppler/-/issues/952Poppler cairo backend doesn't render PDF with lots of thin lines properly2020-08-17T23:26:08ZFrancisco RamosPoppler cairo backend doesn't render PDF with lots of thin lines properlyI originally reported it to inkscape but it also happens with evince and it seems to be an issue with some viewers. For example, gsx (ghostscript viewer), okular and google-chrome PDF reader show the PDF correctly, while evince, firefox ...I originally reported it to inkscape but it also happens with evince and it seems to be an issue with some viewers. For example, gsx (ghostscript viewer), okular and google-chrome PDF reader show the PDF correctly, while evince, firefox and some others don't. https://gitlab.com/inkscape/inbox/-/issues/3342
The issue is seen when comparing the original eps file with the transformed pdf... it is the same if it is converted with ps2pdf or plain gs command. The PDF is seen like a bit "pale" because some thin lines are dropped
I reported it to evince upstream and they found that the issue is in poppler cairo backend:
https://gitlab.gnome.org/GNOME/evince/-/issues/1472#note_892217
Thanks a lot for your help[ss.pdf](/uploads/6a1162bd7c323a6531d7af879f94f7ce/ss.pdf)[ss.eps][ss.pdf](/uploads/da294a7495ae62df9ab627231263ab37/ss.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/950Suboptimal rendering of images with text on lowdpi screens2021-06-07T22:17:27ZJan RathmannSuboptimal rendering of images with text on lowdpi screensHello,
when I open a PDF file that contains images with text in them (e.g. scanned pages), the rendering is a bit "ugly" on my lowdpi screen (24", 1920x1200) at some commonly used range of zoom levels.
I only see this with Okular and q...Hello,
when I open a PDF file that contains images with text in them (e.g. scanned pages), the rendering is a bit "ugly" on my lowdpi screen (24", 1920x1200) at some commonly used range of zoom levels.
I only see this with Okular and qpdfview, rendering in Evince, Atril, Zathura is fine.
STEPS TO REPRODUCE
1. Open attached file "test.pdf" with Okular or qpdfview.
2. Set zoom level to 75% (or up to ~100%).
OBSERVED RESULT
Text looks "rather ugly".
(See also attached screenshot.)
EXPECTED RESULT
Text looks "clearly readable".
(Compare screenshot from same document opened in Evince.)
To reproduce this in a clean environment, I was booting live images of Kubuntu 20.04 and KDE Neon (neon-unstable-20200726-1102.iso).
The original bug report on the KDE bugtracker is here:
https://bugs.kde.org/show_bug.cgi?id=424817
Kind regards,
Jan
[ Example pdf illustrating the bug (generated with 'img2pdf -o test.pdf test.png')](/uploads/7f094da749274142946538e9c4b9ea1f/test.pdf)
[Source image file from which the test example was generated](/uploads/c53e719eed554a460e1f3e2875581878/test.png)
[Screenshot rendering of test.pdf with Okular (zoom level 75%)](/uploads/4fa09de6762a7c1c0b87a08a34e1ff6e/Bildschirmfoto_20200809_191836.png)
[Screenshot rendering of test.pdf with Evince (zoom level 75%)](/uploads/807c6671c317ad986b13d5d413fef451/Bildschirmfoto_20200809_191907.png)https://gitlab.freedesktop.org/poppler/poppler/-/issues/946Overprint preview output2020-07-29T15:04:26ZMarius TurcuOverprint preview outputHello!
I try to achieve a png output preview output like the one from adobe reader. Please let me know if is possible or if I do something wrong.
- Command: `pdftocairo -q -png -x 0 -y 0 -W 1604 -H 773 -r 171 -singlefile -f 1 -l 1 -tran...Hello!
I try to achieve a png output preview output like the one from adobe reader. Please let me know if is possible or if I do something wrong.
- Command: `pdftocairo -q -png -x 0 -y 0 -W 1604 -H 773 -r 171 -singlefile -f 1 -l 1 -transp input.pdf out.png`
- File: [input.pdf](/uploads/1fe622326ff84db9379dcb453cedd064/input.pdf)
- Expected result: ![image](/uploads/898e36fd13c14720cecd676a39e791f5/image.png)
- Actual result: ![image](/uploads/b385779ce6ea4c5324888c017d5cb661/image.png)
Thank you in advance!https://gitlab.freedesktop.org/poppler/poppler/-/issues/945Feature Request: tabs in pdftotext -layout2020-07-26T10:56:29ZCraig SandersFeature Request: tabs in pdftotext -layoutIs it possible to have the `-layout` option add tab characters between columns, when working with a multi-column PDF?
Or another option, say "`-columntabs`", to be used with -layout to do this?
I often work with 2 or 3 column PDF files ...Is it possible to have the `-layout` option add tab characters between columns, when working with a multi-column PDF?
Or another option, say "`-columntabs`", to be used with -layout to do this?
I often work with 2 or 3 column PDF files with lots of text tables. Without `-layout`, the tables are a useless mess so I use the `-layout` option and manually edit the text file with vim to insert tab characters between the columns, then use a perl script to split each page on the tabs and convert it to single-column.
Even with vim, adding the tabs can be a long and tedious process, especially with dozens or hundreds of pages.
It would be great if I could skip the "edit with vim" stage, or even minimise that step to just removing excess tabs from tables.