poppler issueshttps://gitlab.freedesktop.org/poppler/poppler/-/issues2020-06-01T10:50:26Zhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/922pdftocairo doesn't fix the whole pdf2020-06-01T10:50:26ZVidmantaspdftocairo doesn't fix the whole pdfWe are working with various pdfs and more often than not we get a pdf that is somehow corrupt, that is, if you try to use pdftocairo, or pdftotext or any other tool from poppler with the document, it shows quite a few errors:
```
Syntax ...We are working with various pdfs and more often than not we get a pdf that is somehow corrupt, that is, if you try to use pdftocairo, or pdftotext or any other tool from poppler with the document, it shows quite a few errors:
```
Syntax Error (678743): Missing 'endstream' or incorrect stream length
Syntax Error (1253955): Missing 'endstream' or incorrect stream length
Syntax Error: Missing 'endstream' or incorrect stream length
```
We use pdftocairo to fix such pdfs and it's working well for the most part, but we have noticed that sometimes pdftocairo doesn't fix the whole pdf the first time. I have attached a file with which you can reproduce this: [corrupt.pdf](/uploads/21afdea9efc4bffc49d574b1b67b190d/corrupt.pdf)
To reproduce:
1. Call `pdftotext corrupt.pdf -`
2. Observe the output, clearly not all of the text was extracted from the pdf.
3. Call `pdftocairo -pdf corrupt.pdf corrupt-fixed.pdf`
4. Call pdftotext again on fixed pdf
5. Observe the output, the text is still not fully extracted
6. Call `pdftocairo -pdf corrupt-fixed.pdf corrupt-fixed-twice.pdf`
7. Call pdftotext on corrupt-fixed-twice.pdf
8. Observe that the output text is now bigger and is in fact all the text in pdf.
Expected: we should only have to call pdftocairo on a document once to get the fully fixed pdf
Actual: we have to call pdftocairo 2 times on a document to get the fully fixed pdf
Version: 0.89.0https://gitlab.freedesktop.org/poppler/poppler/-/issues/920pdftocairo inconsistent color rendering2020-05-27T08:36:45ZŠtěpán Procházkapdftocairo inconsistent color renderingI am bumping into the issue of certain colors being changed during conversion (colors in resulting png differ from original pdf).
# Steps to reproduce
Test file contains three sets of hex numbers (one set for each color component), each...I am bumping into the issue of certain colors being changed during conversion (colors in resulting png differ from original pdf).
# Steps to reproduce
Test file contains three sets of hex numbers (one set for each color component), each number is written in respective color (e.g. `42` in _blue_ paragraph has `#000042` color).
- generating PDF file using `xelatex` (optional)
[test.tex](/uploads/21d6eec6b0fcd6ae0e09c97766a76ef3/test.tex)
```
xelatex test.tex
```
- converting pdf to png (no aliasing, transparent background)
[test.pdf](/uploads/9234a0ef2b22fb93e8d646601066bce3/test.pdf)
```
pdftocairo -transp -r 300 -antialias none -png test.pdf test
```
![test-1](/uploads/c35272020d162c39453efc2185697cef/test-1.png)
# Observations
Most of the colors are rendered correctly, only the following colors with specific value of any of the component cause the issue. I have inspected the contents of PDF and looked for stroke and fill color values (`rg` and `RG` tags).
| TEX value | PDF value | PNG value |
|:---------:|:---------:|:---------:|
| 07 | 0.027 | 06 |
| 08 | 0.031 | 07 |
| 09 | 0.035 | 08 |
| 0a | 0.039 | 09 |
| 14 | 0.078 | 13 |
| 15 | 0.082 | 14 |
| ea | 0.918 | eb |
| eb | 0.922 | ec |
| f5 | 0.961 | f6 |
| f6 | 0.965 | f7 |
| f7 | 0.969 | f8 |
| f8 | 0.973 | f9 |
`xelatex` seems to convert RGB 0-255 color component `c` using `sprintf(_, '%.3f', (c / 255.0))`. The conflicting values are symmetrical (`07`-`15` correspond to `f8`-`ea`). Eventhough the value in PDF is not the exactly the original one i would expect the converted color to be closest match - i.e. the correct color.
I was unable to trace the whole conversion code and potential origin of the issue in _poppler_ library. Hope it will be :cake: for someone well oriented in the codebase.
NB: my _pdftocairo_ version is 0.62.0, reading the changelog I did not found any change in newer versions relating to this issue.https://gitlab.freedesktop.org/poppler/poppler/-/issues/918Bad FontBBox set on existing font when using pdftocairo2020-05-18T17:57:01Zken sandsBad FontBBox set on existing font when using pdftocairoI tried to run a pdf through pdftocairo in order to embed some non embedded fonts to ready a file for sending off to a printer.
The fonts embedded just fine, however of the fonts that were already embedded one (helvetica) was assigned a ...I tried to run a pdf through pdftocairo in order to embed some non embedded fonts to ready a file for sending off to a printer.
The fonts embedded just fine, however of the fonts that were already embedded one (helvetica) was assigned a new negative bbox.
While that doesn't appear to cause any issues with appearance it does cause adobe reader to throw up a BLABLA_Helvetica contains a bad /BBox message box.
I checked the original file and the font in there has FontBBox[ -951 -481 1446 1122]
I checked the file after pdftocairo and it's /FontBBox [ 31049 -480 1445 1121 ]
I edited the resulting file to [ -951 -480 1445 1121 ] and the error is gone, to be sure I diff checked the output and all 3 are visually identical.
Looking at those numbers it seems to me there is a fairly simple int -> uint type thing slipping through (32000-951 being 31049)
Attached a before and after of pdftocairo -pdf P11_safe.pdf P11_cairo.pdf
[P11_cairo.pdf](/uploads/baa28b1791f058d2f5ed982d6f338683/P11_cairo.pdf)
[P11_safe.pdf](/uploads/fae486f3773452f957fecd28d5e4cc46/P11_safe.pdf)
The contents of the pdfs have been deliberately scraped of bits of sensitive text so that I could upload it.https://gitlab.freedesktop.org/poppler/poppler/-/issues/889[pdftocario]Misrendering italic font style when converting pdf to png2020-03-13T20:42:52Z月迷津渡[pdftocario]Misrendering italic font style when converting pdf to png`AOB` and `M` `N`
[italic.pdf](/uploads/728d1c7fce296e544f1c701befd4afbd/italic.pdf)
![italic](/uploads/0d79b79df80e834a6bf040d598c8e690/italic.png)`AOB` and `M` `N`
[italic.pdf](/uploads/728d1c7fce296e544f1c701befd4afbd/italic.pdf)
![italic](/uploads/0d79b79df80e834a6bf040d598c8e690/italic.png)https://gitlab.freedesktop.org/poppler/poppler/-/issues/855pdftocairo takes many minutes to convert this PDF2021-06-26T12:49:44ZAlex Kpdftocairo takes many minutes to convert this PDFHi team,
It takes 6+ minutes on my 12 Core workstation to process this file. Perhaps there could be some optimizations added to speed it up? We have this command as part of the printing process to ensure that PDFs have all the fonts pr...Hi team,
It takes 6+ minutes on my 12 Core workstation to process this file. Perhaps there could be some optimizations added to speed it up? We have this command as part of the printing process to ensure that PDFs have all the fonts properly embedded, and we'd appreciate if it could process this sort of files faster.
`pdftocairo -pdf ./d413875-001.pdf out.pdf`
Ubuntu 19.10,
poppler-utils 0.80.0-0ubuntu1
libcairo2 1.16.0-4
The file: [d413875-001.pdf](/uploads/91d6da9f83f653f406766f6c12d05c3d/d413875-001.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/810pdftocairo -paper crop2019-07-27T16:19:32Zvstepaniukpdftocairo -paper crop```
-paper size
Set the paper size to one of "letter", "legal", "A4", or "A3" (PS,PDF,SVG only). This can also be set to "match", which will set
the paper size of each page to match the size specifi...```
-paper size
Set the paper size to one of "letter", "legal", "A4", or "A3" (PS,PDF,SVG only). This can also be set to "match", which will set
the paper size of each page to match the size specified in the PDF file. If none the -paper, -paperw, or -paperh options are speci‐
fied the default is to match the paper size.
```
I suggest to add a `crop` value to the `pdftocairo -paper` option to mean the crop area dimensions, specified by the `-W` and `-H` options.https://gitlab.freedesktop.org/poppler/poppler/-/issues/807Font rendering issue unrelated to substituted fonts2019-07-24T22:59:14ZKrešimir ČoharFont rendering issue unrelated to substituted fontsHey guys, so we noticed something that might be a poppler (cairo) issue in https://gitlab.gnome.org/GNOME/evince/issues/1221
See "st udents" and "n ew" in Evince (left) vs Chromium (right, students and new, respectively):
![image](/upl...Hey guys, so we noticed something that might be a poppler (cairo) issue in https://gitlab.gnome.org/GNOME/evince/issues/1221
See "st udents" and "n ew" in Evince (left) vs Chromium (right, students and new, respectively):
![image](/uploads/ea37bb8d47c9b7832c0ca04906c8b7e1/image.png)
Using pdftocairo, this happens:
![image](/uploads/8db6e47fb9dc05961e445cc5787ca503/image.png)
So, while Evince's font smoothing exacerbates the problem, it doesn't seem to be the root cause of it.
The fonts in this PDF aren't substituted but embedded.
Is this fixable?
(Running Ubuntu 19.04, GNOME 3.32.1, Evince 3.32.0)https://gitlab.freedesktop.org/poppler/poppler/-/issues/774pdftocairo generates PS that crashes Adobe engine2019-12-12T17:07:06ZAlex Kpdftocairo generates PS that crashes Adobe engineWhen some PDFs are converted to PS by pdftocairo using cairo 1.15.10 or later, the resulting PS files crash printers that are using Adobe PS engine. In my case, Ricoh printers.
Adobe reviewed the PS files and said this:
> Cairo incorp...When some PDFs are converted to PS by pdftocairo using cairo 1.15.10 or later, the resulting PS files crash printers that are using Adobe PS engine. In my case, Ricoh printers.
Adobe reviewed the PS files and said this:
> Cairo incorporates pattern data into form data. When printing, the form data is drawn repeatedly, but the cache memory overflows because the pattern data is included. Due to this, an illegal memory access occurs and the job is canceled.
>
> If Cairo does not include pattern data in the form data, it is possible to work around the problem.
Does this pattern data need to be included in the form?
Perhaps it's still possible to return to 1.15.8 behavior, or pinpoint the commit that I could remove just for my environment?
Here are two example PDF files, and two resulting PS files for each PDF.
Cairo 1.15.8
pdftocairo -ps -level3 [pwc.pdf](/uploads/4b116753fd71f98039d7b9859776cc40/pwc.pdf) [pwc158.ps](/uploads/244b5e7b88165b3dd47197f8e0ae5d17/pwc158.ps)
pdftocairo -ps -level3 [sub.pdf](/uploads/542415215e2f672623e0f6d2b5166faa/sub.pdf) [sub158.ps](/uploads/394979596b4345e5fc12d6cad0bd32fa/sub158.ps)
Cairo 1.16.0 (I'm using 1.16.0 in this example, but the issue occurs with 1.15.10 onward).
pdftocairo -ps -level3 [pwc.pdf](/uploads/4b116753fd71f98039d7b9859776cc40/pwc.pdf) [pwc160.ps](/uploads/ef14cb790292400e55d3544eaf3246f7/pwc160.ps)
pdftocairo -ps -level3 [sub.pdf](/uploads/542415215e2f672623e0f6d2b5166faa/sub.pdf) [sub160.ps](/uploads/4f396f64ed5f96d0ad2a1659a6954ab6/sub160.ps)https://gitlab.freedesktop.org/poppler/poppler/-/issues/764pdftocairo takes 20+ minutes to process this PDF2019-05-08T21:58:13ZAlex Kpdftocairo takes 20+ minutes to process this PDFOn my 12-core machine this PDF conversion takes 20+ minutes and produces a huge 127Mb PDF.
pdftocairo -pdf [wojtka.pdf](/uploads/ea07e11941ae9699a4364de2018e5006/wojtka.pdf) wojtka-out.pdf
```
$ time pdftocairo -pdf ./wojtka.pdf wo...On my 12-core machine this PDF conversion takes 20+ minutes and produces a huge 127Mb PDF.
pdftocairo -pdf [wojtka.pdf](/uploads/ea07e11941ae9699a4364de2018e5006/wojtka.pdf) wojtka-out.pdf
```
$ time pdftocairo -pdf ./wojtka.pdf wojtka-out.pdf
Syntax Warning: Invalid Font Weight
Syntax Warning: Invalid Font Weight
Syntax Warning: Invalid Font Weight
Syntax Warning: Invalid Font Weight
Syntax Warning: Invalid Font Weight
Syntax Warning: Invalid Font Weight
real 20m46.750s
user 20m45.753s
sys 0m0.977s
```
Perhaps something could be done to speed it up?
cairo 1.16.0
poppler 0.61.1https://gitlab.freedesktop.org/poppler/poppler/-/issues/757pdftocairo -pdf produces a broken pdf out of this pdf2019-04-17T20:53:27ZAlex Kpdftocairo -pdf produces a broken pdf out of this pdfHow to reproduce:
Convert the file original.pdf into another PDF with
`pdftocairo -pdf original.pdf orig-cairo.pdf`
Resulting file will be missing all the text, and pdftopdf will choke on it thus making it impossible to print
```
$ ...How to reproduce:
Convert the file original.pdf into another PDF with
`pdftocairo -pdf original.pdf orig-cairo.pdf`
Resulting file will be missing all the text, and pdftopdf will choke on it thus making it impossible to print
```
$ cat /tmp/orig-cairo.pdf | /usr/lib/cups/filter/pdftopdf 1 1 1 1 '' >out.pdf
DEBUG: pdftopdf: No PPD file specified, could not determine whether to log pages or not, so turned off page logging.
WARNING: temp file: file is damaged
WARNING: temp file (object 7 0, offset 15236): expected n n obj
WARNING: temp file: Attempting to reconstruct cross-reference table
WARNING: temp file: object 7 0 not found in file after regenerating cross reference table
```
Cairo 1.16.0, poppler 0.61.1, qpdf 8.0.2.
[original.pdf](/uploads/96118a2bcd2f9fe0984ce899cad089ea/original.pdf).
[orig-cairo.pdf](/uploads/8a7a22ace6b97a074e70b11a35cab537/orig-cairo.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/747pdftocairo crashes on this PDF file with _cairo_ps_surface_operation_supporte...2019-03-29T22:12:26ZAlex Kpdftocairo crashes on this PDF file with _cairo_ps_surface_operation_supported failedpoppler utils 0.61.1, cairo 1.16.0 on Debian Testing.
How to reproduce:
pdftocairo -ps -level3 [d96882-edited.pdf](/uploads/b3be72f3b77feeca3e2e5866581ab0ef/d96882-edited.pdf) out.ps
```
pdftocairo: ../../../../src/cairo-ps-surface.c...poppler utils 0.61.1, cairo 1.16.0 on Debian Testing.
How to reproduce:
pdftocairo -ps -level3 [d96882-edited.pdf](/uploads/b3be72f3b77feeca3e2e5866581ab0ef/d96882-edited.pdf) out.ps
```
pdftocairo: ../../../../src/cairo-ps-surface.c:4986: _cairo_ps_surface_mask: Assertion `_cairo_ps_surface_operation_supported (surface, op, source, mask, &extents.bounded)' failed.
Program received signal SIGABRT, Aborted.
```
Gdb stack shows this
```
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ffff65013fa in __GI_abort () at abort.c:89
#2 0x00007ffff64f8e37 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x7ffff7ba9870 "_cairo_ps_surface_operation_supported (surface, op, source, mask, &extents.bounded)", file=file@entry=0x7ffff7ba7a58 "../../../../src/cairo-ps-surface.c", line=line@entry=4986, function=function@entry=0x7ffff7ba99f0 <__PRETTY_FUNCTION__.14368> "_cairo_ps_surface_mask") at assert.c:92
#3 0x00007ffff64f8ee2 in __GI___assert_fail (assertion=assertion@entry=0x7ffff7ba9870 "_cairo_ps_surface_operation_supported (surface, op, source, mask, &extents.bounded)", file=file@entry=0x7ffff7ba7a58 "../../../../src/cairo-ps-surface.c", line=line@entry=4986, function=function@entry=0x7ffff7ba99f0 <__PRETTY_FUNCTION__.14368> "_cairo_ps_surface_mask") at assert.c:101
#4 0x00007ffff7b820b1 in _cairo_ps_surface_mask (abstract_surface=0x5555557cea50, op=CAIRO_OPERATOR_OVER, source=0x555555830df8, mask=0x555555830f10, clip=<optimized out>) at ../../../../src/cairo-ps-surface.c:4986
#5 0x00007ffff7b31747 in _cairo_surface_mask (surface=0x5555557cea50, op=CAIRO_OPERATOR_OVER, source=0x555555830df8, mask=0x555555830f10, clip=0x5555558a6a90) at ../../../../src/cairo-surface.c:2247
#6 0x00007ffff7b2df40 in _cairo_surface_wrapper_mask (wrapper=wrapper@entry=0x7fffffffd200, op=CAIRO_OPERATOR_OVER, source=source@entry=0x555555830df8, mask=mask@entry=0x555555830f10, clip=<optimized out>) at ../../../../src/cairo-surface-wrapper.c:200
#7 0x00007ffff7b1afcb in _cairo_recording_surface_replay_internal (surface=surface@entry=0x5555558472b0, surface_extents=surface_extents@entry=0x0, surface_transform=surface_transform@entry=0x0, target=target@entry=0x5555557cea50, target_clip=target_clip@entry=0x0, surface_is_unbounded=surface_is_unbounded@entry=0, type=CAIRO_RECORDING_REPLAY, region=<optimized out>) at ../../../../src/cairo-recording-surface.c:1896
#8 0x00007ffff7b1c287 in _cairo_recording_surface_replay_region (surface=surface@entry=0x5555558472b0, surface_extents=surface_extents@entry=0x0, target=target@entry=0x5555557cea50, region=region@entry=CAIRO_RECORDING_REGION_NATIVE) at ../../../../src/cairo-recording-surface.c:2210
#9 0x00007ffff7b7f430 in _cairo_ps_surface_emit_recording_surface (surface=surface@entry=0x5555557cea50, recording_surface=0x5555558472b0, recording_extents=0x7fffffffd510, subsurface=subsurface@entry=0) at ../../../../src/cairo-ps-surface.c:3398
#10 0x00007ffff7b800e3 in _cairo_ps_surface_emit_surface (surface=0x5555557cea50, mode=CAIRO_EMIT_SURFACE_ANALYZE, params=0x7fffffffd580) at ../../../../src/cairo-ps-surface.c:3684
#11 0x00007ffff7b8061e in _cairo_ps_surface_emit_surface_pattern (surface=0x5555557cea50, pattern=0x5555557f2a48, extents=<optimized out>, op=CAIRO_OPERATOR_OVER) at ../../../../src/cairo-ps-surface.c:4117
#12 0x00007ffff7b81ed3 in _cairo_ps_surface_fill (abstract_surface=0x5555557cea50, op=CAIRO_OPERATOR_OVER, source=0x5555557f2a48, path=0x5555557f2b60, fill_rule=CAIRO_FILL_RULE_WINDING, tolerance=<optimized out>, antialias=<optimized out>, clip=0x5555557c20a0) at ../../../../src/cairo-ps-surface.c:5163
#13 0x00007ffff7b3196a in _cairo_surface_fill (surface=0x5555557cea50, op=CAIRO_OPERATOR_OVER, source=0x5555557f2a48, path=0x5555557f2b60, fill_rule=CAIRO_FILL_RULE_WINDING, tolerance=0.10000000000000001, antialias=CAIRO_ANTIALIAS_DEFAULT, clip=0x5555557c20a0) at ../../../../src/cairo-surface.c:2422
#14 0x00007ffff7b2e6f0 in _cairo_surface_wrapper_fill (wrapper=wrapper@entry=0x7fffffffde50, op=CAIRO_OPERATOR_OVER, source=source@entry=0x5555557f2a48, path=path@entry=0x5555557f2b60, fill_rule=CAIRO_FILL_RULE_WINDING, tolerance=0.10000000000000001, antialias=CAIRO_ANTIALIAS_DEFAULT, clip=0x5555557f0c30) at ../../../../src/cairo-surface-wrapper.c:384
#15 0x00007ffff7b1b2e6 in _cairo_recording_surface_replay_internal (surface=<optimized out>, surface_extents=surface_extents@entry=0x0, surface_transform=surface_transform@entry=0x0, target=<optimized out>, target_clip=target_clip@entry=0x0, surface_is_unbounded=surface_is_unbounded@entry=0, type=CAIRO_RECORDING_REPLAY, region=<optimized out>) at ../../../../src/cairo-recording-surface.c:1980
#16 0x00007ffff7b1c287 in _cairo_recording_surface_replay_region (surface=<optimized out>, surface_extents=surface_extents@entry=0x0, target=<optimized out>, region=region@entry=CAIRO_RECORDING_REGION_NATIVE) at ../../../../src/cairo-recording-surface.c:2210
#17 0x00007ffff7afce42 in _paint_page (surface=surface@entry=0x5555557d0bf0) at ../../../../src/cairo-paginated-surface.c:469
#18 0x00007ffff7afd313 in _cairo_paginated_surface_show_page (abstract_surface=0x5555557d0bf0) at ../../../../src/cairo-paginated-surface.c:583
#19 0x00007ffff7b31ccb in INT_cairo_surface_show_page (surface=0x5555557d0bf0) at ../../../../src/cairo-surface.c:2504
```https://gitlab.freedesktop.org/poppler/poppler/-/issues/721pdftocairo - Incorrect transform matrix in SVG2019-02-22T10:23:48ZКонстантин Савинскийpdftocairo - Incorrect transform matrix in SVGResult SVG files has incorrect transform matrix
![Screenshot_1](/uploads/dc30540d3630b26117ad4daa6a69a4d5/Screenshot_1.png)
cmd: pdftocairo -svg bg.pdf bg.svg
poppler: 0.74.0
cairo: 1.16.0
source file: [bg.pdf](/uploads/f81533f542a79...Result SVG files has incorrect transform matrix
![Screenshot_1](/uploads/dc30540d3630b26117ad4daa6a69a4d5/Screenshot_1.png)
cmd: pdftocairo -svg bg.pdf bg.svg
poppler: 0.74.0
cairo: 1.16.0
source file: [bg.pdf](/uploads/f81533f542a79b7cd615e4719180d6bb/bg.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/617pdftocairo -pdf output breaks extracted text2018-10-08T10:29:56ZBugzilla Migration Userpdftocairo -pdf output breaks extracted text## Submitted by nop..@..il.com
Assigned to **poppler-bugs**
**[Link to original bug (#106444)](https://bugs.freedesktop.org/show_bug.cgi?id=106444)**
## Description
Created attachment 139431
PDFs, original and outputs from Ubuntu ...## Submitted by nop..@..il.com
Assigned to **poppler-bugs**
**[Link to original bug (#106444)](https://bugs.freedesktop.org/show_bug.cgi?id=106444)**
## Description
Created attachment 139431
PDFs, original and outputs from Ubuntu and Mac. Extracted text original and Ubuntu optimized.
Under Ubuntu 16.04 processing select PDFs with pdftocairo -pdf (both versions 0.41.0 (pkg) and 0.64.0 (src)) results in text extracted from the resulting PDF to appear as question mark symbols (suggesting a text encoding problem). The rendered image output appears correct.
I initially observed the problem with the extracted text when programmatically processing the text layer when rendered with pdf.js but then confirmed the behavior looking at the output of pdftotext. (Also when copying text from other pdf viewers.)
Interestingly when the same PDF is processed on a Mac with pdftocairo (0.64.0) the output PDFs extracted text appears *correct*. I am not sure if it is relevant but in the attached example I do observe some differences in the font encoding as shown below.
pdffonts from original PDF:
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
FFXDHY+ArialMT TrueType MacRoman yes yes no 10 0
EESSLH+Helvetica TrueType WinAnsi yes yes yes 9 0
pdffonts after processing on Ubuntu:
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
DFUWOB+ArialMT CID TrueType Identity-H yes yes yes 5 0
pdffonts after processing on Mac:
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
DFUWOB+ArialMT TrueType WinAnsi yes yes yes 5 0
**Attachment 139431**, "PDFs, original and outputs from Ubuntu and Mac. Extracted text original and Ubuntu optimized.":
[cairo-optimized-pdf-extract-text-bug-report.zip](/uploads/b7785afc5fdc3104ae9a3cf742f43bfb/cairo-optimized-pdf-extract-text-bug-report.zip)https://gitlab.freedesktop.org/poppler/poppler/-/issues/614pdftocairo does not report some errors2018-10-08T10:28:42ZBugzilla Migration Userpdftocairo does not report some errors## Submitted by a3n..@..nm.net
Assigned to **poppler-bugs**
**[Link to original bug (#92195)](https://bugs.freedesktop.org/show_bug.cgi?id=92195)**
## Description
The pdftocairo command line tool does not report certain errors. Th...## Submitted by a3n..@..nm.net
Assigned to **poppler-bugs**
**[Link to original bug (#92195)](https://bugs.freedesktop.org/show_bug.cgi?id=92195)**
## Description
The pdftocairo command line tool does not report certain errors. The cases which I have observed are:
- when specifying the -scale-to option for conversions to types that do not accept it (e.g., for SVG), the option and its value are ignored with no error message
- when only one of -paperw and -paperh are specified, both are silently ignored
- when giving to -paperw or -paperh a non-integer value (e.g., "42.3"), or indeed any other erroneous value that cannot be parsed as an integer, the conversion is aborted and no error message is displayed (only the exit code reflects that something went wrong); by contrast negative integers do not make the conversion fail but mean that -paperw and -paperh are silently ignored.
I think pdftocairo should display an error when the conversion was not actually performed, and display warnings (or display an error and fail) when some parameters were ignored.https://gitlab.freedesktop.org/poppler/poppler/-/issues/548pdftocairo - Flag to disable text drawing2018-10-08T10:29:02ZBugzilla Migration Userpdftocairo - Flag to disable text drawing## Submitted by Ryan Fox
Assigned to **poppler-bugs**
**[Link to original bug (#65877)](https://bugs.freedesktop.org/show_bug.cgi?id=65877)**
## Description
Created attachment 80975
Patch to add a flag to disable text drawing. Bas...## Submitted by Ryan Fox
Assigned to **poppler-bugs**
**[Link to original bug (#65877)](https://bugs.freedesktop.org/show_bug.cgi?id=65877)**
## Description
Created attachment 80975
Patch to add a flag to disable text drawing. Based on the code in the 0.23.2 release.
I needed to hack pdftocairo to allow me to disable the text drawing, and I thought it could be something other people might benefit from, so I'm presenting a tiny patch to add a flag for it.
Background: Cairo's SVG backend doesn't draw text as text; it creates shapes for each letter. (See [bug 38516](https://bugs.freedesktop.org/show_bug.cgi?id=38516)) I'm using the output from pdftocairo for the structure of a PDF, rather than the visual representation, so the actual text is important to me, as well as all of the shapes. I can get sufficient text information from `pdftohtml -xml` for this. To prevent losing non-letter glyphs, I need to prevent the drawing of the text rather than just discarding all of the glyphs.
**Attachment 80975**, "Patch to add a flag to disable text drawing. Based on the code in the 0.23.2 release.":
[notext.patch](/uploads/eb059e151a453c366c6ee6294dc84b77/notext.patch)https://gitlab.freedesktop.org/poppler/poppler/-/issues/484[PATCH] Add -noannotate option in pdftocairo to disable annotations2018-10-08T10:30:30ZBugzilla Migration User[PATCH] Add -noannotate option in pdftocairo to disable annotations## Submitted by Stephen E.
Assigned to **poppler-bugs**
**[Link to original bug (#94304)](https://bugs.freedesktop.org/show_bug.cgi?id=94304)**
## Description
Created attachment 121977
Patch to add -noannotate option to pdftocairo...## Submitted by Stephen E.
Assigned to **poppler-bugs**
**[Link to original bug (#94304)](https://bugs.freedesktop.org/show_bug.cgi?id=94304)**
## Description
Created attachment 121977
Patch to add -noannotate option to pdftocairo
I was looking for a way to prevent pdftocairo from drawing PDF form fields when rendering to a bitmap, and came up short. The attached patch adds a -noannotate flag which does this. (Thanks to jcrain from IRC for pointing me toward the appropriate internals!)
**Attachment 121977**, "Patch to add -noannotate option to pdftocairo":
[noannotate.patch](/uploads/c9e16990a1fd5b1f62f35e921f2a07ff/noannotate.patch)https://gitlab.freedesktop.org/poppler/poppler/-/issues/326Pattern image is repeated thousands of times, producing huge output2021-10-03T21:20:07ZBugzilla Migration UserPattern image is repeated thousands of times, producing huge output## Submitted by Dmitry Shubin
Assigned to **poppler-bugs**
**[Link to original bug (#90009)](https://bugs.freedesktop.org/show_bug.cgi?id=90009)**
## Description
Created attachment 115049
Files to reproduce the issue, see descript...## Submitted by Dmitry Shubin
Assigned to **poppler-bugs**
**[Link to original bug (#90009)](https://bugs.freedesktop.org/show_bug.cgi?id=90009)**
## Description
Created attachment 115049
Files to reproduce the issue, see description.
When source PDF contains multiple references to the same image resource, Poppler output has this image duplicated as many times.
The very original image is the attached slowpptx.pptx (80k). It was converted to pdf using LibreOffice 4.3.1, resulting in attached slowpptx.lo.pdf (35k). Result of
> pdftocairo.exe -svg -f 1 -l 1 slowpptx.lo.pdf
produces a 1.7M svg (slowpptx.lo.svg.zip), which contains the same image duplicated 1741 times. Same thing happens with
> pdftohtml.exe -f 1 -l 1 slowpptx.lo.pdf
so I assume this is not related to Cairo.
Thanks
Dmitry
(Internal ref PCC-22530)
**Attachment 115049**, "Files to reproduce the issue, see description.":
[slowpptx.zip](/uploads/331cbaaa9d7159fce40bc16ca6088429/slowpptx.zip)https://gitlab.freedesktop.org/poppler/poppler/-/issues/183Incorrect EPS content when converting a landscape PDF with pdftocairo -eps2018-10-08T10:45:41ZBugzilla Migration UserIncorrect EPS content when converting a landscape PDF with pdftocairo -eps## Submitted by Alexander Wieland
Assigned to **poppler-bugs**
**[Link to original bug (#107060)](https://bugs.freedesktop.org/show_bug.cgi?id=107060)**
## Description
Created attachment 140374
Lanscape PDF
I think there's a bug ...## Submitted by Alexander Wieland
Assigned to **poppler-bugs**
**[Link to original bug (#107060)](https://bugs.freedesktop.org/show_bug.cgi?id=107060)**
## Description
Created attachment 140374
Lanscape PDF
I think there's a bug when a landscape PDF file is converted with the tool pdftocairo to an EPS file. ( -eps )
The output I get is a shrinked but not rotated version of the original file. Tested with pdftocairo version 0.62.0 and cairo 1.15.10.
**Attachment 140374**, "Lanscape PDF":
![landscape_pdf](/uploads/7cd6d3f8456598d8c4324e2740c4ac0c/landscape_pdf.png)