poppler issueshttps://gitlab.freedesktop.org/poppler/poppler/-/issues2021-02-07T22:04:15Zhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/1033PDF text forms not redering if only /V is present or /AP does not contain text.2021-02-07T22:04:15ZerikPDF text forms not redering if only /V is present or /AP does not contain text.When filling in textfields in a acroform without having an /AP field present, i think the expected behavior is to render the
context from the /V field, however currently poppler will render an empty field, or when the AP is an empty box ...When filling in textfields in a acroform without having an /AP field present, i think the expected behavior is to render the
context from the /V field, however currently poppler will render an empty field, or when the AP is an empty box it ant the /V has some contents in there it will not render the filled in text.
When running the pdf to the pdfto* tools it does report the following error:
`- Syntax Error: Can't get Fields array<0a> `
It could be that it is also somewhat a malformed pdf.[output.pdf](/uploads/84a3851a42b3dae9e6766a8ece3eddfa/output.pdf)
I have attached a pdf within this format containing some dummy data, both pdfjs and acrobat reader and at least the buildin iOS reader display this behavior of rendering the /V text, and also mupdf works fine.
This was tested with on arch with the latest poppler version (21.01.0), and the pdfs where generated using pypdf2.https://gitlab.freedesktop.org/poppler/poppler/-/issues/996Merging editable PDFs with pdfunite makes only the first one to be still edit...2020-11-18T10:39:43ZGustavo HenriqueMerging editable PDFs with pdfunite makes only the first one to be still editable in the final documentWhen I tried to merge with pdfunite the files listed below, that are all editable PDFs that work individually, the page corresponding to the first file in the parameters list is still editable, but the following aren't. I have changed th...When I tried to merge with pdfunite the files listed below, that are all editable PDFs that work individually, the page corresponding to the first file in the parameters list is still editable, but the following aren't. I have changed the parameters order to be sure that this was not an issue with that specific document, and it was confirmed: only the page corresponding to the first document in the parameter list is editable in the final document.
Files (original version in the [Wizards of the Coast website](https://dnd.wizards.com/products/tabletop-games/trpg-resources/trpg-resources)): [Spellcasting_Sheet__Optional__-_Form_Fillable.pdf](/uploads/20aa33724e0ed22943e5333797329c32/Spellcasting_Sheet__Optional__-_Form_Fillable.pdf), [Character_Sheet_-_Form_Fillable.pdf](/uploads/d3864173d92efbc68b981914a2734402/Character_Sheet_-_Form_Fillable.pdf), [Character_Details__Optional__-_Form_Fillable.pdf](/uploads/74df03f0ab20999807a957855fa57447/Character_Details__Optional__-_Form_Fillable.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/753incorrect kerning in some XFA form fields2020-10-24T15:19:05ZNathaniel M. Beaverincorrect kerning in some XFA form fieldsI entered some text into [a PDF containing XFA forms](/uploads/bc4560d890cf532a9acbb058ccae9eed/ss-5.pdf). I can enter the text without issue, but some of the letters are wrongly positioned, i.e. the kerning is wrong, both in xpdf and on...I entered some text into [a PDF containing XFA forms](/uploads/bc4560d890cf532a9acbb058ccae9eed/ss-5.pdf). I can enter the text without issue, but some of the letters are wrongly positioned, i.e. the kerning is wrong, both in xpdf and on the printed page. For example, the letter "i" overlaps with the letter "m" in "Smith":
![xpdf-screenshot](/uploads/fa7bc6b73a8cbb7562ca9013bc2bfcaf/xpdf-screenshot.png)
I've observed this bug to be present in Evince, xpdf, and Okular, but not mupdf or pdf.js. I've also confirmed it to be present in the output of `pdftoppm` and `pdfcairo`. An [Arch Linux user has reported reproducing the issue](https://askubuntu.com/questions/1031235/wrong-letter-positioning-and-font-in-pdf-form#comment1867868_1031235), and both [Ubuntu](https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1824260) and [GNOME](https://gitlab.gnome.org/GNOME/evince/issues/1127) have confirmed the bug.
My questions:
- Is this the correct place to report this bug?
- Is this a duplicate of https://gitlab.freedesktop.org/poppler/poppler/issues/694 ?
- Should I include any further debugging information?
libpoppler version:
$ file /usr/lib/x86_64-linux-gnu/libpoppler.so.73.0.0
/usr/lib/x86_64-linux-gnu/libpoppler.so.73.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=29185bb684d73e7289db19f77b3b4f3fbb4ca0f9, stripped
$ apt-cache policy libpoppler73
libpoppler73:
Installed: 0.62.0-2ubuntu2.8
Candidate: 0.62.0-2ubuntu2.8
Version table:
*** 0.62.0-2ubuntu2.8 500
500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
100 /var/lib/dpkg/status
0.62.0-2ubuntu2 500
500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
xpdf version:
$ xpdf -v
xpdf version 3.04
Copyright 1996-2014 Glyph & Cog, LLC
evince version:
$ evince --version
GNOME Document Viewer 3.28.4
Linux distribution: Ubuntu 18.04.
PDF information:
$ pdfinfo ss-5.pdf
Title: Application for Social Security Card
Subject: Use this form to apply for a new or replacemet SSN card.
Keywords: Social Security Card, Application, Card, SS-5, 5, SSN
Author: Social Security Administration
Creator: Adobe LiveCycle Designer ES 9.0
Producer: Adobe LiveCycle Designer ES 9.0
CreationDate: Mon Nov 16 07:36:43 2015 CST
ModDate: Mon Nov 23 08:01:40 2015 CST
Tagged: yes
UserProperties: no
Suspects: no
Form: XFA
JavaScript: yes
Pages: 5
Encrypted: yes (print:yes copy:no change:no addNotes:yes algorithm:AES)
Page size: 612 x 792 pts (letter)
Page rot: 0
File size: 141815 bytes
Optimized: no
PDF version: 1.7
$ pdffonts -subst ss-5.pdf
name object ID substitute font substitute font file
------------------------------------ --------- ------------------------------------ ------------------------------------
ArialMT 826 0 Arial /usr/share/fonts/truetype/msttcorefonts/Arial.ttf
Arial-BoldMT 828 0 Arial Negreta /usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
CourierStd 145 0 DejaVu Sans /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
Helvetica 197 0 Bitstream Vera Sans /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf
MyriadPro-Regular 198 0 DejaVu Sans /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
ZapfDingbats 199 0 DejaVu Sans /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
Evince bug:
https://gitlab.gnome.org/GNOME/evince/issues/1127
Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1824260
AskUbuntu question:
https://askubuntu.com/questions/1031235/wrong-letter-positioning-and-font-in-pdf-form
Potentially related bugs:
https://gitlab.freedesktop.org/poppler/poppler/issues/694
Attachments:
[ss-5.pdf](/uploads/bc4560d890cf532a9acbb058ccae9eed/ss-5.pdf)
[xpdf-screenshot](/uploads/fa7bc6b73a8cbb7562ca9013bc2bfcaf/xpdf-screenshot.png)https://gitlab.freedesktop.org/poppler/poppler/-/issues/652Encoding issue for PDF forms2022-07-16T20:30:06ZThomas DreibholzEncoding issue for PDF formsEvince 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
...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 18.04
Ubuntu 18.10
$ apt-show-versions |grep libpoppler | grep amd64
libpoppler-dev:amd64/bionic-security 0.62.0-2ubuntu2.2 uptodate
libpoppler-glib8:amd64/bionic-security 0.62.0-2ubuntu2.2 uptodate
libpoppler-private-dev:amd64/bionic-security 0.62.0-2ubuntu2.2 uptodate
libpoppler-qt5-1:amd64/bionic-security 0.62.0-2ubuntu2.2 uptodate
libpoppler73:amd64/bionic-security 0.62.0-2ubuntu2.2 uptodatehttps://gitlab.freedesktop.org/poppler/poppler/-/issues/642Checkboxes not rendered in Poppler based readers2018-11-21T21:34:20ZEmil SedghCheckboxes not rendered in Poppler based readersThe attached PDF file has many checkbox annotations.
They are all fine except for 4 checkboxes: They are simply not rendered by Okular or Evince.
Chrome, Master PDF Editor and Acrobat all render them though.
![2](/uploads/d41093300c47b...The attached PDF file has many checkbox annotations.
They are all fine except for 4 checkboxes: They are simply not rendered by Okular or Evince.
Chrome, Master PDF Editor and Acrobat all render them though.
![2](/uploads/d41093300c47b57c14dc8f90fab3fb53/2.png)
The troublesome checkboxes are on page 5.
Their fieldNames are:
* `Form338`
* `Form339`
* `Form2000`
* `Form2001`https://gitlab.freedesktop.org/poppler/poppler/-/issues/69Radiobutton produces multiple clickable items2018-10-26T15:50:23ZBugzilla Migration UserRadiobutton produces multiple clickable items## Submitted by Germán Poo-Caamaño
Assigned to **poppler-bugs**
**[Link to original bug (#107413)](https://bugs.freedesktop.org/show_bug.cgi?id=107413)**
## Description
Created attachment 140868
PDF Test case
This was reported in...## Submitted by Germán Poo-Caamaño
Assigned to **poppler-bugs**
**[Link to original bug (#107413)](https://bugs.freedesktop.org/show_bug.cgi?id=107413)**
## Description
Created attachment 140868
PDF Test case
This was reported in Evince's issue tracker from Launchpad as:
--------------------------------------------------------------
Downstream report:
https://bugs.launchpad.net/ubuntu/+source/evince/+bug/531516
lsb_release -rd
Description: Ubuntu Vivid Vervet (development branch)
Release: 15.04
apt-cache policy evince
evince:
Installed: 3.14.1-0ubuntu1
Candidate: 3.14.1-0ubuntu1
Version table:
*** 3.14.1-0ubuntu1 0
500 http://us.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages
100 /var/lib/dpkg/status
What is expected to happen is when one opens https://bugs.launchpad.net/ubuntu/+source/evince/+bug/531516/+attachment/1207516/+files/test.pdf one may click one of the four buttons, and then clicks another, the first one disappears, and reappears in the secondly clicked button, just like Adobe Reader.
What happens instead is clicking the second radio button does input a mark in the second button, but the first button clicked still has its mark. This was originally reported to be a regression, and against Ubuntu 9.10 evince 2.28.1-0ubuntu1.2.
--------------------------------------------------------------
The issue is reproducible with any viewer that depends on Poppler.
According to the comment https://gitlab.gnome.org/GNOME/evince/issues/539#note_276696 it is hyperref that produces a wrong form. The issue is in https://github.com/ho-tex/hyperref/issues/3
However, Acrobat Reader handle is as expected, same as FoxIt Reader.
**Attachment 140868**, "PDF Test case":
[test.pdf](/uploads/2e7e6d2ee9da39169c7a5a882173f145/test.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/420Can't fill (or even find) fields in PDF form created (or saved) with Mac Preview2018-10-27T13:45:20ZBugzilla Migration UserCan't fill (or even find) fields in PDF form created (or saved) with Mac Preview## Submitted by Germán Poo-Caamaño
Assigned to **poppler-bugs**
**[Link to original bug (#106844)](https://bugs.freedesktop.org/show_bug.cgi?id=106844)**
## Description
Created attachment 140057
PDF Test case
Reported in https://...## Submitted by Germán Poo-Caamaño
Assigned to **poppler-bugs**
**[Link to original bug (#106844)](https://bugs.freedesktop.org/show_bug.cgi?id=106844)**
## Description
Created attachment 140057
PDF Test case
Reported in https://gitlab.gnome.org/GNOME/evince/issues/657
Trying to complete a state tax form that was created or saved (I don't know which) on a Mac using Mac Preview. However, none of the input fields are visible nor can they be selected (it's like they aren't there). The maintainers of the form have used Windows and Adobe Reader to load and re-save it, so I can't provide a link to the failed form. However, I have attached my copy of the form for your use.
Linux Mint 17.3 and Document Viewer 3.10.3
**Attachment 140057**, "PDF Test case":
[tc-40.pdf](/uploads/acffd80e92ecce1528073e5edcaf51a0/tc-40.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/234Form entries with the same name do not share their values2018-10-07T00:02:06ZBugzilla Migration UserForm entries with the same name do not share their values## Submitted by Gurb
Assigned to **poppler-bugs**
**[Link to original bug (#104619)](https://bugs.freedesktop.org/show_bug.cgi?id=104619)**
## Description
Created attachment 136713
Test PDF file: a form with two fields whose names...## Submitted by Gurb
Assigned to **poppler-bugs**
**[Link to original bug (#104619)](https://bugs.freedesktop.org/show_bug.cgi?id=104619)**
## Description
Created attachment 136713
Test PDF file: a form with two fields whose names are 'name'
According to the PDF 1.7 standard (12.7.3.2), fields with the same fully qualified name shall have the same value. In Adobe Reader, when the user fills a text field, all other homonym fields are filled automatically with that value. Some PDF rely on this feature to autocopy their forms in different pages so that they can be delivered to different recipients once printed.
I guess this is a poppler bug since Evince and Okular do not show this behaviour. Different fields with a common name can be filled with different values. If the file is saved and opened in Adobe Reader the value of the first is shown in all of them. If opened in Evince or Okular, they show different values.
That happens in Arch Linux with poppler 0.61.1, evince 3.26.0+14+g2a499547-1 and okular version 17.12.1-1, but also in older versions. I attach a test PDF file.
PS: having a look at the source code it seems that different FormWidgetText can have a common FormFieldText parent, and when the value of any of the widgets changes, FormField::updateChildrenAppearance may refresh the displayed text of all other widgets for the field. But perhaps widgets are not created so that they share their parent.
**Attachment 136713**, "Test PDF file: a form with two fields whose names are 'name'":
[form.pdf](/uploads/7d363ad60dfcd09e7b48d5434527c93c/form.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/120Form text not displayed for upside-down field2018-10-27T14:35:49ZBugzilla Migration UserForm text not displayed for upside-down field## Submitted by Konstantin Svist
Assigned to **poppler-bugs**
**[Link to original bug (#95391)](https://bugs.freedesktop.org/show_bug.cgi?id=95391)**
## Description
See attached document, field "180 deg" (left-middle of the page)
...## Submitted by Konstantin Svist
Assigned to **poppler-bugs**
**[Link to original bug (#95391)](https://bugs.freedesktop.org/show_bug.cgi?id=95391)**
## Description
See attached document, field "180 deg" (left-middle of the page)
Pre-filled text appears properly, but if changed, text is not displayed for
this field at all
N.B. There are many more bugs I've noticed in this PDF. Should I list them here
in the comments or file each one separately?
Fedora 23
okular-15.12.3-1.fc23.x86_64
poppler-0.34.0-2.fc23.x86_64https://gitlab.freedesktop.org/poppler/poppler/-/issues/175Form data not displayed2018-10-07T00:03:21ZBugzilla Migration UserForm data not displayed## Submitted by Konstantin Svist
Assigned to **poppler-bugs**
**[Link to original bug (#95371)](https://bugs.freedesktop.org/show_bug.cgi?id=95371)**
## Description
After adding some forms to a document, Okular is able to edit the...## Submitted by Konstantin Svist
Assigned to **poppler-bugs**
**[Link to original bug (#95371)](https://bugs.freedesktop.org/show_bug.cgi?id=95371)**
## Description
After adding some forms to a document, Okular is able to edit the form data, but does not display it for printing (form appears blank)
Fedora 23
okular-15.12.3-1.fc23.x86_64
poppler-0.34.0-2.fc23.x86_64https://gitlab.freedesktop.org/poppler/poppler/-/issues/483Some forms are not saved2018-10-08T22:07:43ZBugzilla Migration UserSome forms are not saved## Submitted by Marek Kasik `@mkasik`
Assigned to **poppler-bugs**
**[Link to original bug (#93882)](https://bugs.freedesktop.org/show_bug.cgi?id=93882)**
## Description
Created attachment 121323
Mark holes in xref table as free e...## Submitted by Marek Kasik `@mkasik`
Assigned to **poppler-bugs**
**[Link to original bug (#93882)](https://bugs.freedesktop.org/show_bug.cgi?id=93882)**
## Description
Created attachment 121323
Mark holes in xref table as free entries
I've got downstream report with a PDF form which doesn't save entered data. I've looked at this in more detail and it seems that the problem is caused by reconstruction of xref table before saving of the form which causes "reset" of the form.
The reconstruction is performed because there is a call for XRef::getEntry() on entry which does not exist (with i = 7 btw). This entry doesn't exist because there is a hole in the xref table. I was not sure whether the table is correct then but from https://bugs.freedesktop.org/show_bug.cgi?id=48679 it seems that it is (and note 17 on section 3.4.3 in specification of PDF 1.7 says that we should treat such holes as free entries).
Attached is a patch which works for me but I'm not sure whether it doesn't add another bug elsewhere. It marks newly added entries which where not listed in previous sections of xref table as free. It doesn't do this if previous size of the xref table was 0 because this indicates that the PDF is probably linearized and it would mark some entries as free even if those will be populated later.
It doesn't "chain" the free entries but it seems that it work even without that (otherwise we would need to reuse the code from beginning of XRef::writeXRef() which does this).
The original report and the reproducer can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=1301016
**Attachment 121323**, "Mark holes in xref table as free entries":
[0001-Mark-holes-in-xref-table-as-free.patch](/uploads/26495f0d9c43b2636c12f102a50c4dc0/0001-Mark-holes-in-xref-table-as-free.patch)https://gitlab.freedesktop.org/poppler/poppler/-/issues/195Certain boxes fillable in Acrobat are not fillable2018-10-07T00:07:35ZBugzilla Migration UserCertain boxes fillable in Acrobat are not fillable## Submitted by Howdy
Assigned to **poppler-bugs**
**[Link to original bug (#93647)](https://bugs.freedesktop.org/show_bug.cgi?id=93647)**
## Description
Certain boxes that are fillable in acrobat are not fillable in evince(or oku...## Submitted by Howdy
Assigned to **poppler-bugs**
**[Link to original bug (#93647)](https://bugs.freedesktop.org/show_bug.cgi?id=93647)**
## Description
Certain boxes that are fillable in acrobat are not fillable in evince(or okular, or atril):
http://www.uscis.gov/sites/default/files/files/form/i-864.pdf
Boxes 1, 2 and 8 on part 5 are not fillable.https://gitlab.freedesktop.org/poppler/poppler/-/issues/437Text not shown when filling out form2018-10-06T23:56:21ZBugzilla Migration UserText not shown when filling out form## Submitted by Hanno Böck
Assigned to **poppler-bugs**
**[Link to original bug (#93569)](https://bugs.freedesktop.org/show_bug.cgi?id=93569)**
## Description
Created attachment 120779
PDF form causing problems
I'll attach a pdf ...## Submitted by Hanno Böck
Assigned to **poppler-bugs**
**[Link to original bug (#93569)](https://bugs.freedesktop.org/show_bug.cgi?id=93569)**
## Description
Created attachment 120779
PDF form causing problems
I'll attach a pdf file that poppler doesn't render properly when you try to fill a form. When opening the file in evince and trying to add text to any of the text fields (e.g. "Vorname") it will just show an empty field.
I'll also attach an image showing that.
~~**Attachment 120779**~~, "PDF form causing problems":
[Antragsformular_PAL_16.pdf](/uploads/e1b074cfa2604249b1bf5a174f7fda77/Antragsformular_PAL_16.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/523Unicode strings saved as literal strings2018-10-07T00:25:40ZBugzilla Migration UserUnicode strings saved as literal strings## Submitted by Marek Kasik `@mkasik`
Assigned to **poppler-bugs**
**[Link to original bug (#91058)](https://bugs.freedesktop.org/show_bug.cgi?id=91058)**
## Description
Created attachment 116655
Testing form
When saving the atta...## Submitted by Marek Kasik `@mkasik`
Assigned to **poppler-bugs**
**[Link to original bug (#91058)](https://bugs.freedesktop.org/show_bug.cgi?id=91058)**
## Description
Created attachment 116655
Testing form
When saving the attached PDF form, the string entered into the text field is saved as a literal string and not as a hexadecimal string which causes problems when viewing it in acroread.
I believe that such strings should be saved as hexadecimal strings.
I used "šč" string for testing.
**Attachment 116655**, "Testing form":
[form.pdf](/uploads/3c0343f645746b8698037cff39e931bf/form.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/364Arabic text in pdf forms cannot be saved or printed2019-08-05T19:51:12ZBugzilla Migration UserArabic text in pdf forms cannot be saved or printed## Submitted by Munzir Taha
Assigned to **poppler-bugs**
**[Link to original bug (#42944)](https://bugs.freedesktop.org/show_bug.cgi?id=42944)**
## Description
I can type Arabic in any pdf form fields but when trying to print to P...## Submitted by Munzir Taha
Assigned to **poppler-bugs**
**[Link to original bug (#42944)](https://bugs.freedesktop.org/show_bug.cgi?id=42944)**
## Description
I can type Arabic in any pdf form fields but when trying to print to PDF to save it or to a printer, Arabic text doesn't show!
You can test with:
http://launchpadlibrarian.net/11456651/f1040nre-2007.pdfhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/249poppler: can't render text in PDF form2018-10-27T15:00:29ZBugzilla Migration Userpoppler: can't render text in PDF form## Submitted by Török Edwin
Assigned to **poppler-bugs**
**[Link to original bug (#33199)](https://bugs.freedesktop.org/show_bug.cgi?id=33199)**
## Description
Created attachment 42114
confirmare.pdf
xpdf/okular/pdfedit can't ren...## Submitted by Török Edwin
Assigned to **poppler-bugs**
**[Link to original bug (#33199)](https://bugs.freedesktop.org/show_bug.cgi?id=33199)**
## Description
Created attachment 42114
confirmare.pdf
xpdf/okular/pdfedit can't render the text from this form:
http://static.anaf.ro/static/10/Anaf/formulare/confirmare.pdf
I wouldn't expect the form part to work perfectly (it probably uses some Adobe-specific behaviour), but I would expect to see at least the text.
See screenshots on how it looks now, and how it should look like.
libpoppler version 0.12.4-1.2
xpdf version 3.02-12
okular version 4:4.4.5-2
This form is needed to sign up for Romania's online fiscal statements system.
It would be nice if free software could be used to see and fill out the form.
**Attachment 42114**, "confirmare.pdf":
[confirmare.pdf](/uploads/74261adedbac6668956824894a10d03b/confirmare.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/82Cannot render specific PDF form2018-10-26T15:49:58ZBugzilla Migration UserCannot render specific PDF form## Submitted by Ettore Atalan
Assigned to **poppler-bugs**
**[Link to original bug (#28621)](https://bugs.freedesktop.org/show_bug.cgi?id=28621)**
## Description
Created attachment 36373
Screenshot of Okular
I've discovered an ex...## Submitted by Ettore Atalan
Assigned to **poppler-bugs**
**[Link to original bug (#28621)](https://bugs.freedesktop.org/show_bug.cgi?id=28621)**
## Description
Created attachment 36373
Screenshot of Okular
I've discovered an extraordinary PDF form [*], where the dynamic content in fill form mode doesn't work at all. Only the static PDF can be seen.
[*] http://file.wikileaks.org/file/sat-guide.pdf
**Attachment 36373**, "Screenshot of Okular":
![Screenshot_of_Okular](/uploads/03ee3875f2b335fc136eb4601f8c12ae/Screenshot_of_Okular.png)https://gitlab.freedesktop.org/poppler/poppler/-/issues/358pdf's forms are not alway recognized correctly2018-10-05T22:44:14ZBugzilla Migration Userpdf's forms are not alway recognized correctly## Submitted by Jan Kohnert
Assigned to **poppler-bugs**
**[Link to original bug (#26967)](https://bugs.freedesktop.org/show_bug.cgi?id=26967)**
## Description
Created attachment 33872
pdf containing a form ist es not recognized w...## Submitted by Jan Kohnert
Assigned to **poppler-bugs**
**[Link to original bug (#26967)](https://bugs.freedesktop.org/show_bug.cgi?id=26967)**
## Description
Created attachment 33872
pdf containing a form ist es not recognized within okular
I'm creating pdf files using pdflatex from texlive-2008. Those files contain forms to fill, which are correcty recognized in Acrobat Reader, but not in Okular which is using poppler.
I was asking in the IRC channel of okular and was adviced to file a bug here.
pdflatex from texlive-2009 is reported to work, but I could not yet test, as 2008 is stable on Gentoo. I'm doing an upgrade right at the moment, and will report back on that issue.
A quite minimal example (stolen from the Laxtex hyperref package documentation is attached.
**Attachment 33872**, "pdf containing a form ist es not recognized within okular":
[test.pdf](/uploads/cb7111c8dc7a602f18dd46dabfd4bae7/test.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/348complex (?) pdf forms not correctly rendered2018-10-26T15:52:33ZBugzilla Migration Usercomplex (?) pdf forms not correctly rendered## Submitted by Diego Ercolani
Assigned to **poppler-bugs**
**[Link to original bug (#24812)](https://bugs.freedesktop.org/show_bug.cgi?id=24812)**
## Description
I don't have much experience with pdf forms but I found a kind of d...## Submitted by Diego Ercolani
Assigned to **poppler-bugs**
**[Link to original bug (#24812)](https://bugs.freedesktop.org/show_bug.cgi?id=24812)**
## Description
I don't have much experience with pdf forms but I found a kind of ducument
bakered by Acrobat that doesn't be rendered correctly in okular that uses poppler as backend.
I opened a bug issue in bugs.kde.org (https://bugs.kde.org/show_bug.cgi?id=212394) but they told that this should be a backend (poppler) problem as the same issue is in every opensource pdf rendering engine that I tryied:
ghostscript
kpdf from kde3
xpdf
gimp
There are 2 problems:
-------------- 1st problem ---------------
ghostscript think that the font used by the document contains ArialMT:
gs -sDEVICE=x11 EstrattoConto_1256901690391.pdf
GPL Ghostscript 8.62 (2008-02-29)
Copyright (C) 2008 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file COPYING for details.
Processing pages 1 through 1.
Page 1
Can't find (or can't open) font file
/usr/share/ghostscript/8.62/Resource/Font/ArialMT.
Can't find (or can't open) font file ArialMT.
Can't find (or can't open) font file
/usr/share/ghostscript/8.62/Resource/Font/ArialMT.
Can't find (or can't open) font file ArialMT.
Scanning /usr/share/fonts/truetype for fonts... 482 files, 480 scanned, 471 new
fonts.
Loading ArialMT font from /usr/share/fonts/truetype/arial.ttf... 6354392
2943989 20226572 18829752 3 done.
>>showpage, press `<return>` to continue<<
while acrobat reader 8 properties says more characters but not ArialMT (I'll
include Acrobat properties screenshot) - immagine1.jpeg
The same for okular (see attached immagine2.jpeg)
--------------2nd problem (MORE IMPORTANT) ---------------------
The document contain a form that is compiled to create the pdf from java Adobe
LiveCycle Designer 8.
Okular shows that there are forms but doesn't show anithing but the page
template.... (see immagine3.jpeg)
while acrobat shows correctly the form with prefilled fields.
The document is a "statement of account" for credit cards so it's a kind of
document that is important to be readable....