poppler issueshttps://gitlab.freedesktop.org/poppler/poppler/-/issues2019-03-29T11:48:22Zhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/558Fix handling of UTF16-LE annotations2019-03-29T11:48:22ZBugzilla Migration UserFix handling of UTF16-LE annotations## Submitted by Christophe Fergeau `@teuf`
Assigned to **poppler-bugs**
**[Link to original bug (#103023)](https://bugs.freedesktop.org/show_bug.cgi?id=103023)**
## Description
Created attachment 134538
Test case
The 'unicode' an...## Submitted by Christophe Fergeau `@teuf`
Assigned to **poppler-bugs**
**[Link to original bug (#103023)](https://bugs.freedesktop.org/show_bug.cgi?id=103023)**
## Description
Created attachment 134538
Test case
The 'unicode' annotation in the attached test case does not render properly. I added it through the default mail application on my iOS11 iphone.
I trade that down to _poppler_goo_string_to_utf8() which assumes UTF16 strings will always be big endian, while in my test file, a little endian UTF16 string is used.
I've fixed this by adding 2 new methods to GooString (hasBigEndianBOM() hasLittleEndianBOM()), but all users of GooString::hasUnicodeMarker() should probably be audited and handle both types of UTF16 strings unless the pdf specs mandates big endian strings. Since I'm not familiar at all with the PDF format, I haven't tried to address this yet.
**Attachment 134538**, "Test case":
[poppler-utf16-le.pdf](/uploads/ea9109513c4071675495ad777343ce6a/poppler-utf16-le.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/557Option thinlinemode shape for pdftoppm doesn't work correct for fill operations2018-10-11T08:21:18ZBugzilla Migration UserOption thinlinemode shape for pdftoppm doesn't work correct for fill operations## Submitted by Thomas Freitag
Assigned to **poppler-bugs**
**[Link to original bug (#94152)](https://bugs.freedesktop.org/show_bug.cgi?id=94152)**
## Description
Created attachment 121754
splashThinLineShape also for fill operati...## Submitted by Thomas Freitag
Assigned to **poppler-bugs**
**[Link to original bug (#94152)](https://bugs.freedesktop.org/show_bug.cgi?id=94152)**
## Description
Created attachment 121754
splashThinLineShape also for fill operations
This is a followup for [bug 94052](https://bugs.freedesktop.org/show_bug.cgi?id=94052)!
Looking at [bug 94052](https://bugs.freedesktop.org/show_bug.cgi?id=94052) I encountered that the thinlinemode shape doesn't work correctly for the PDF of [bug 94052](https://bugs.freedesktop.org/show_bug.cgi?id=94052): Instead of a gray grid the background is completely removed and shown as white if using this option.
The difference between the PDF of [bug 94052](https://bugs.freedesktop.org/show_bug.cgi?id=94052) and the one of [bug 37347](https://bugs.freedesktop.org/show_bug.cgi?id=37347) is that in the PDF of [bug 37347](https://bugs.freedesktop.org/show_bug.cgi?id=37347) the lines are drawn with a stroke, where as in the one of [bug 94052](https://bugs.freedesktop.org/show_bug.cgi?id=94052) the lines are drawn with a fill command.
So I extend in this patch the implementation of the "shape" mode so that it works with fills, too.
**Patch 121754**, "splashThinLineShape also for fill operations":
[94052.patch](/uploads/8450021efdf72f06d70342738823ea9f/94052.patch)https://gitlab.freedesktop.org/poppler/poppler/-/issues/556-xml outputs malformed xml2018-08-21T11:11:02ZBugzilla Migration User-xml outputs malformed xml## Submitted by dan..@..il.com
Assigned to **poppler-bugs**
**[Link to original bug (#98305)](https://bugs.freedesktop.org/show_bug.cgi?id=98305)**
## Description
Overview:
The following pdf causes pdftohtml to output malform...## Submitted by dan..@..il.com
Assigned to **poppler-bugs**
**[Link to original bug (#98305)](https://bugs.freedesktop.org/show_bug.cgi?id=98305)**
## Description
Overview:
The following pdf causes pdftohtml to output malformed xml:
http://www.atmel.com/images/Atmel-8284-8-bit-AVR-microcontroller-ATmega169A_PA_329A_PA_3290A_PA_649A_P_6490A_P_datasheet.pdf
The resulting xml file has multiple similar errors, the first one on line 71641:
`<text top="180" left="71" width="101" height="15" font="11">``<b>`Sp<a href="Atmel-8284-8-bit-AVR-microcontroller-ATmega169A_PA_329A_PA_3290A_PA_649A_P_6490A_P_datasheet.html#876">eed [MHz] `</b>`(3)`</a>``</text>`
(the closing b and a tags are not in the correct order)
Steps to Reproduce:
1) wget http://www.atmel.com/images/Atmel-8284-8-bit-AVR-microcontroller-ATmega169A_PA_329A_PA_3290A_PA_649A_P_6490A_P_datasheet.pdf
2) pdftohtml -q -i -xml Atmel-8284-8-bit-AVR-microcontroller-ATmega169A_PA_329A_PA_3290A_PA_649A_P_6490A_P_datasheet.pdf output.xml
Actual Results:
malformed xml
Expected Results:
well-formed xml. And I'm not quite sure if the link is placed on the correct piece of text. In the pdf only the text "(3)" is clickable and none of it is bold.
Build Date & Hardware:
Built on 2016-10-18 from source (0.48.0) on Ubunty 14.04 LTS
Additional Builds and Platforms:
Also occurred in the version of pdftohtml that was installed using apt-get (0.28 if I recall correctly)
Cheers,
Danielhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/555pdftoppm writes to standard output2018-10-06T23:50:36ZBugzilla Migration Userpdftoppm writes to standard output## Submitted by Christopher Yeleighton
Assigned to **poppler-bugs**
**[Link to original bug (#35221)](https://bugs.freedesktop.org/show_bug.cgi?id=35221)**
## Description
When invoked as { pdftoppm x.pdf; }, pdftoppm writes PPM to...## Submitted by Christopher Yeleighton
Assigned to **poppler-bugs**
**[Link to original bug (#35221)](https://bugs.freedesktop.org/show_bug.cgi?id=35221)**
## Description
When invoked as { pdftoppm x.pdf; }, pdftoppm writes PPM to standard output. This behavior is undocumented.https://gitlab.freedesktop.org/poppler/poppler/-/issues/554gfile win32 unicode fixes and refactoring2018-10-23T12:08:46ZBugzilla Migration Usergfile win32 unicode fixes and refactoring## Submitted by Adrian Johnson `@ajohnson`
Assigned to **poppler-bugs**
**[Link to original bug (#104045)](https://bugs.freedesktop.org/show_bug.cgi?id=104045)**
## Description
The aim of the following patches is to:
- Improve wi...## Submitted by Adrian Johnson `@ajohnson`
Assigned to **poppler-bugs**
**[Link to original bug (#104045)](https://bugs.freedesktop.org/show_bug.cgi?id=104045)**
## Description
The aim of the following patches is to:
- Improve win32 unicode support in goo/gfile.cc.
- Eliminate duplicated functions that differ only by char*/wchar_t*. All internal functions should use char* and the win32 wchar_t conversion should be performed at the point where the win32 API is invoked.
- Eliminate unused code.
- Eventually get windows.h out of the header files. It slows down the compile and pollutes the namespace.
- Plus some other mingw fixes and build cleanups I found while working on this.https://gitlab.freedesktop.org/poppler/poppler/-/issues/553"UTF-16" not native byte order on OS X iconv (re ustrings to_utf8)2018-10-26T11:11:40ZBugzilla Migration User"UTF-16" not native byte order on OS X iconv (re ustrings to_utf8)## Submitted by Franz Brauße
Assigned to **poppler-bugs**
**[Link to original bug (#96313)](https://bugs.freedesktop.org/show_bug.cgi?id=96313)**
## Description
Hi.
ustring::to_utf8() creates a
MiniIconv ic("UTF-8", "UTF-16");...## Submitted by Franz Brauße
Assigned to **poppler-bugs**
**[Link to original bug (#96313)](https://bugs.freedesktop.org/show_bug.cgi?id=96313)**
## Description
Hi.
ustring::to_utf8() creates a
MiniIconv ic("UTF-8", "UTF-16");
assuming that iconv(3) uses the native byte order for "UTF-16". On OS X w/ Intel CPUs (I installed poppler through MacPorts, but this issue is unrelated, see below) this fails, as a quick
$ echo -n 7 | iconv -t utf-16 | hexdump -C
00000000 fe ff 00 37 |...7|
reveals: it's UTF-16BE.
This breaks page-labels for me, which instead of "78" (UTF-8) return the (hex) values
e3 9c 80 e3 a0 80
which is 0x3700 0x3800.
A fix might be to not "decode" GooString's UTF-16BE to native byte order in
detail::unicode_GooString_to_ustring(GooString *str)
or use a source encoding based on the BYTE_ORDER macro instead of just "UTF-16BE" or to check the BOM-character output by iconv(3) (which e.g.
ustring::from_utf8(const char *str, int len)
currently skips).https://gitlab.freedesktop.org/poppler/poppler/-/issues/552Build failed with XCode - nspr.h not found2019-01-09T13:02:16ZBugzilla Migration UserBuild failed with XCode - nspr.h not found## Submitted by hey..@..il.com
Assigned to **poppler-bugs**
**[Link to original bug (#94868)](https://bugs.freedesktop.org/show_bug.cgi?id=94868)**
## Description
Trying to compile poppler-qt5 with XCode but I can because of this ...## Submitted by hey..@..il.com
Assigned to **poppler-bugs**
**[Link to original bug (#94868)](https://bugs.freedesktop.org/show_bug.cgi?id=94868)**
## Description
Trying to compile poppler-qt5 with XCode but I can because of this error : "SignatureHandler.h --> nspr.h file not found"https://gitlab.freedesktop.org/poppler/poppler/-/issues/551Symbian version of Poppler2018-10-06T23:52:03ZBugzilla Migration UserSymbian version of Poppler## Submitted by Fran
Assigned to **poppler-bugs**
**[Link to original bug (#25899)](https://bugs.freedesktop.org/show_bug.cgi?id=25899)**
## Description
As you know, Nokia has released Qt 4.6, that includes support for mobile plat...## Submitted by Fran
Assigned to **poppler-bugs**
**[Link to original bug (#25899)](https://bugs.freedesktop.org/show_bug.cgi?id=25899)**
## Description
As you know, Nokia has released Qt 4.6, that includes support for mobile platforms as Symbian and Maemo 6. (http://qt.nokia.com/about/news/nokia-releases-qt-4.6)
I admit I don't know much about Poppler, so I really don't know if that eases the portability of Poppler to Symbian.
That would allow the creation of GPL Acrobat readers in that platform, that is very extended in Europe...
Is that as simple as adding some compiler options or would it take a lot of effort?
Thanks in advance,
Franciscohttps://gitlab.freedesktop.org/poppler/poppler/-/issues/550the documentation for poppler_document_new_from_data is not complete2021-02-14T11:02:25ZBugzilla Migration Userthe documentation for poppler_document_new_from_data is not complete## Submitted by mehmet yasar
Assigned to **poppler-bugs**
**[Link to original bug (#13549)](https://bugs.freedesktop.org/show_bug.cgi?id=13549)**
## Description
The documentation should precise that :
- poppler_document_new_from_d...## Submitted by mehmet yasar
Assigned to **poppler-bugs**
**[Link to original bug (#13549)](https://bugs.freedesktop.org/show_bug.cgi?id=13549)**
## Description
The documentation should precise that :
- poppler_document_new_from_data doesn't make a copy of the data
- the data must not be freed !https://gitlab.freedesktop.org/poppler/poppler/-/issues/549Selections with ligatures are not correctly drawn2020-11-05T22:01:52ZBugzilla Migration UserSelections with ligatures are not correctly drawn## Submitted by Jose Aliste
Assigned to **poppler-bugs**
**[Link to original bug (#34301)](https://bugs.freedesktop.org/show_bug.cgi?id=34301)**
## Description
Forwarded from Gnome bugzilla. The following bug appears when using ev...## Submitted by Jose Aliste
Assigned to **poppler-bugs**
**[Link to original bug (#34301)](https://bugs.freedesktop.org/show_bug.cgi?id=34301)**
## Description
Forwarded from Gnome bugzilla. The following bug appears when using evince or poppler-glib-demo to draw selections.
1. Download the following document:
http://java.sun.com/docs/books/jvms/second_edition/ClassFileFormat-final-draft.pdf
2. Open page 54 which is numbered 146.
3. Select the word "reflective" on the second row from the top.
Then the ligature "fl" gets rendered with another symbol, in my case "ß"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/547Text not displayed in PDF2018-10-07T00:19:26ZBugzilla Migration UserText not displayed in PDF## Submitted by Cédric
Assigned to **poppler-bugs**
**[Link to original bug (#71141)](https://bugs.freedesktop.org/show_bug.cgi?id=71141)**
## Description
Created attachment 88511
Pdf of Invoice
Hello,
I receive regularly a pdf ...## Submitted by Cédric
Assigned to **poppler-bugs**
**[Link to original bug (#71141)](https://bugs.freedesktop.org/show_bug.cgi?id=71141)**
## Description
Created attachment 88511
Pdf of Invoice
Hello,
I receive regularly a pdf document but when I open it, no text is displayed. I have tried with the pdf viewers okular and zathura. If I change the backend to mupdf for those viewers the pdf is displayed properly. The file is a pdf version 1.2. It's old, but unfortunately, it's what I receive and it's from a firm, so I can change nothing. I have modified a pdf document with which we can reproduce the the problem. There is not a lot of text in the modified version.
Just tell me if you need something else.
Thanks
~~**Attachment 88511**~~, "Pdf of Invoice":
[test.pdf](/uploads/66354fcd13973a1d3a49f29e594d77f4/test.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/546Certificate chain from PDF digital signature back to trusted root certificate...2020-07-29T10:37:56ZBugzilla Migration UserCertificate chain from PDF digital signature back to trusted root certificate not verified?## Submitted by Sebastian Rasmussen
Assigned to **poppler-bugs**
**[Link to original bug (#99365)](https://bugs.freedesktop.org/show_bug.cgi?id=99365)**
## Description
I believe that the full certificate chain back to a trusted ro...## Submitted by Sebastian Rasmussen
Assigned to **poppler-bugs**
**[Link to original bug (#99365)](https://bugs.freedesktop.org/show_bug.cgi?id=99365)**
## Description
I believe that the full certificate chain back to a trusted root certificate is not verified when attempting to verify digital signatures in PDFs.
SignatureHandler::init_nss() initializes NSS to point to my root
certficate database in my firefox profile or if not available
(it is available) /etc/pki/nssdb (which is unpopoulated on my machine).
I believe that the idea is that this database of root certificates
will be used when verifying the chain of certificates in digital signatures.
I downloaded http://blogs.adobe.com/security/SampleSignedPDFDocument.pdf
and then ran pdfsig (compiled from git HEAD currently at c301f6c6) like so:
./pdfsig-original ./SampleSignedPDFDocument.pdf
Digital Signature Info of:./SampleSignedPDFDocument.pdf
Signature #1:
- Signer Certificate Common Name: John B Harris
- Signing Time: Jul 16 2009 16:47:47
- Signature Validation: Signature is Valid.
- Certificate Validation: Certificate has Expired
The mesage "Signature is Valid" implies that the chain of certificates
has all been checked. However if I replace the call to NSS_Init() with
a call that explicitlydisables any preinitialized database like so:
diff --git a/poppler/SignatureHandler.cc b/poppler/SignatureHandler.cc
index 15c9321c..4be4a140 100644
--- a/poppler/SignatureHandler.cc
+++ b/poppler/SignatureHandler.cc
@@ -91,16 +91,9 @@ GooString *SignatureHandler::getDefaultFirefoxCertDB_Linux()
*/
void SignatureHandler::init_nss()
{
- GooString *certDBPath = getDefaultFirefoxCertDB_Linux();
- if (certDBPath == NULL) {
- NSS_Init("sql:/etc/pki/nssdb");
- } else {
- NSS_Init(certDBPath->getCString());
- }
+ NSS_NoDB_Init("");
//Make sure NSS root certificates module is loaded
SECMOD_AddNewModule("Root Certs", "libnssckbi.so", 0, 0);
-
- delete certDBPath;
}
And then recompile and rerun pdfsig I get the same message as above:
./pdfsig-changed ./SampleSignedPDFDocument.pdf
Digital Signature Info of: ./SampleSignedPDFDocument.pdf
Signature #1:
- Signer Certificate Common Name: John B Harris
- Signing Time: Jul 16 2009 16:47:47
- Signature Validation: Signature is Valid.
- Certificate Validation: Certificate has Expired
Which again seems to claim that the chain of certificates is valid.
How can that be when there are no trusted root certificates in the database?
This appears to be corroborated by the comment preceeding the function
NSS_CMSSignerInfo_Verify() which SignatureHandler later calls to do the
verification:
"Just verifies the signature. The assumption is that verification of
the certificate is done already", see
https://hg.mozilla.org/projects/nss/file/tip/lib/smime/cmssiginfo.c#l310
I believe that the intent with the poppler code is to verify
the entire certificate chain (why else bother to add the firefox
root certificate database?), but I don't think that is what is happening.
Unfortunately I'm not yet well versed in this code to figure out
how to fix this, hence there is no patch attached fixing this issue.
Maybe the decision is to be happy that the certificate is self-consistent
and that the digest is matching, etc. but to ignore that the _chain_ of
certificates is never checked, however in that case I'd suggest mentioning
this clearly, e.g. "Signature is Valid (chain back to root certificate not checked)".
Oh, and of course any UI that uses SignatureHandler is equally affected
as pdfsig, but I find reporting issued using command-line tools easier. :)https://gitlab.freedesktop.org/poppler/poppler/-/issues/545Type 6 shadings with edge connections are not displayed correctly2018-10-26T15:54:27ZBugzilla Migration UserType 6 shadings with edge connections are not displayed correctly## Submitted by ben..@..il.com
Assigned to **poppler-bugs**
**[Link to original bug (#84465)](https://bugs.freedesktop.org/show_bug.cgi?id=84465)**
## Description
Created attachment 107069
Type 6 shading with and without edge conn...## Submitted by ben..@..il.com
Assigned to **poppler-bugs**
**[Link to original bug (#84465)](https://bugs.freedesktop.org/show_bug.cgi?id=84465)**
## Description
Created attachment 107069
Type 6 shading with and without edge connections
Type 6 shadings with edge connections do not render properly. The problem specifically seems to affect shadings where a coordinate is shared 3 times. The first and second pages should appear identical, but the shared edge flags used in the object on the second page cause the shading to be incorrectly displayed.
**Attachment 107069**, "Type 6 shading with and without edge connections":
[6.pdf](/uploads/935a89349fc9b88178e2b090bff70fda/6.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/544[PATCH] Form and annotation borders are not drawn when field /S is not presen...2018-10-07T00:20:25ZBugzilla Migration User[PATCH] Form and annotation borders are not drawn when field /S is not present in /BS## Submitted by Andrew Chen
Assigned to **poppler-bugs**
**[Link to original bug (#102640)](https://bugs.freedesktop.org/show_bug.cgi?id=102640)**
## Description
Border width should not be forced to 0 when /W and/or /S are not pre...## Submitted by Andrew Chen
Assigned to **poppler-bugs**
**[Link to original bug (#102640)](https://bugs.freedesktop.org/show_bug.cgi?id=102640)**
## Description
Border width should not be forced to 0 when /W and/or /S are not present in /BS
Commit 289679405 introduced the behavior: "Avoid drawing borders unless /W and /S are specified in /BS" as a work around for acroread 8. This is not compliant with the pdf specs, and the latest versions of Adobe Acrobat (2017) don't requires both fields to be present, and does not emit the /S field when not necessary.
User visible impact: form and annotation borders are not generated properly when saving pdfs after editing.https://gitlab.freedesktop.org/poppler/poppler/-/issues/543Treatment of page labels2018-10-07T00:26:29ZBugzilla Migration UserTreatment of page labels## Submitted by Nonsmoker
Assigned to **poppler-bugs**
**[Link to original bug (#92734)](https://bugs.freedesktop.org/show_bug.cgi?id=92734)**
## Description
I use pdf2djvu (which in turn uses poppler) to convert pdf-files (e-book...## Submitted by Nonsmoker
Assigned to **poppler-bugs**
**[Link to original bug (#92734)](https://bugs.freedesktop.org/show_bug.cgi?id=92734)**
## Description
I use pdf2djvu (which in turn uses poppler) to convert pdf-files (e-books) to .djvu-files. Occasionally, these files have pages without a label (usually the title page). I was told that Poppler treats a page without label as if it had a label equal to physical page number. Hence, the conversion creates a file with a messed up page numbering. Perhaps this could be amended in poppler?https://gitlab.freedesktop.org/poppler/poppler/-/issues/542Some parts of the document aren't printed2018-08-21T18:28:43ZBugzilla Migration UserSome parts of the document aren't printed## Submitted by Geert Janssens
Assigned to **poppler-bugs**
**[Link to original bug (#89061)](https://bugs.freedesktop.org/show_bug.cgi?id=89061)**
## Description
Attached you will find an invoice I receive monthly in pdf format. ...## Submitted by Geert Janssens
Assigned to **poppler-bugs**
**[Link to original bug (#89061)](https://bugs.freedesktop.org/show_bug.cgi?id=89061)**
## Description
Attached you will find an invoice I receive monthly in pdf format. This
document displays fine in okular. If I print it (or look at the print preview
for that matter) I find that the text below "Facturatieadres" is hidden except
for one character and hence not printed properly.
This happens with every invoice I receive from this vendor.
I can print this document just fine with evince on the same machine.
Reproducible: Always
Steps to Reproduce:
1. Open the attached document
2. Open print preview in okular or print it
Actual Results:
The text below "Facturatieadres" is not visible except for one character. The
same when you effectively print the document.
Expected Results:
The address would be printeld completely.
I had first reported this bug against okular [1], but I was told this is a bug in poppler and I should report it here.
[1] https://bugs.kde.org/show_bug.cgi?id=343996https://gitlab.freedesktop.org/poppler/poppler/-/issues/541"8" shown instead of "x" inside checkbox when converting LibreOffice-generate...2021-05-22T20:58:12ZBugzilla Migration User"8" shown instead of "x" inside checkbox when converting LibreOffice-generated form to PostScript## Submitted by Michael Weghorn
Assigned to **poppler-bugs**
**[Link to original bug (#107303)](https://bugs.freedesktop.org/show_bug.cgi?id=107303)**
## Description
Created attachment 140724
Sample form generated by LibreOffice
...## Submitted by Michael Weghorn
Assigned to **poppler-bugs**
**[Link to original bug (#107303)](https://bugs.freedesktop.org/show_bug.cgi?id=107303)**
## Description
Created attachment 140724
Sample form generated by LibreOffice
Converting a LibreOffice-generated PDF form with a ticked checkbox to PostScript leads to an "8" being shown inside the check box rather than the expected "x" sign.
Steps to reproduce:
1) Open attached PDF form "simple_form.pdf" in Okular
2) tick the checkbox
3) print (either to a real printer or use "Print to File (PDF)")
4) Look at the output/printout
Result:
An "8" is shown inside of the checkbox that has been ticked.
Expected result:
The same checkmark ("x") as displayed in Okular is shown inside the checkbox on the printout.
This can also be reproduced by directly calling 'pdftops' on a PDF form saved after ticking the checkbox:
$ pdftops simple_form_CHECKBOX_TICKED_CLEANED.pdf
Syntax Error: Unknown font tag 'ZaDb'
Syntax Error: Unknown font tag 'ZaDb'
(In addition to ticking the checkbox, the document has been run through 'mutool clean' to make analysis easier.)
**Attachment 140724**, "Sample form generated by LibreOffice":
[simple_form.pdf](/uploads/0dcb7e1b803e6d4429d083695109d896/simple_form.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/540Japanese characters inside table are garbled in HTML2018-10-05T22:18:16ZBugzilla Migration UserJapanese characters inside table are garbled in HTML## Submitted by Nitesh G.
Assigned to **poppler-bugs**
**[Link to original bug (#65896)](https://bugs.freedesktop.org/show_bug.cgi?id=65896)**
## Description
Created attachment 80998
PDF input file
Hi,
I have tried to convert th...## Submitted by Nitesh G.
Assigned to **poppler-bugs**
**[Link to original bug (#65896)](https://bugs.freedesktop.org/show_bug.cgi?id=65896)**
## Description
Created attachment 80998
PDF input file
Hi,
I have tried to convert the attached PDF to HTML(using pdftohtml.exe) and found that Japanese characters inside table are garbled
I am attaching the reference PDF.
Thanks,
Nitesh
**Attachment 80998**, "PDF input file":
[pdftohtml_isues_4.pdf](/uploads/4479fa9a0691dd944afd8d802d465115/pdftohtml_isues_4.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/539Wrong encoding when filling out a PDF form2019-01-16T20:57:23ZBugzilla Migration UserWrong encoding when filling out a PDF form## Submitted by Thomas Dreibholz
Assigned to **poppler-bugs**
**[Link to original bug (#103492)](https://bugs.freedesktop.org/show_bug.cgi?id=103492)**
## Description
Evince and Okular (based on poppler) uses the wrong encoding wh...## Submitted by Thomas Dreibholz
Assigned to **poppler-bugs**
**[Link to original bug (#103492)](https://bugs.freedesktop.org/show_bug.cgi?id=103492)**
## Description
Evince and Okular (based on poppler) uses the wrong encoding when filling out a PDF form.
How to reproduce:
- Get the official Chinese Visa Application Form from http://www.china-embassy.org/eng/visas/fd/W020130830801798289342.pdf
- Open it in Evince
- Fill in a name (e.g. "Smith"). The entered text is displayed correctly.
- Click into another filed
- The previously entered name is displayed in wrong characters (wrong encoding used?). E.g. "Smith" becomes "4NJUI".
- Saving and loading the PDF (with the entered text) also results in displaying wrong characters
- Clicking into the name filed results in displaying the correct name ("Smith")
=> It seems that somewhere in Evince (or libpoppler?) the wrong encoding is used for displaying non-active input fields.
Tested Ubuntu versions:
- Ubuntu 16.04
- Ubuntu 17.10