RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1226260 - cannot write some non ascii characters in editable PDFs
Summary: cannot write some non ascii characters in editable PDFs
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: poppler
Version: unspecified
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Marek Kašík
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 1420851
TreeView+ depends on / blocked
 
Reported: 2015-05-29 10:19 UTC by janez.kosmrlj
Modified: 2021-12-01 07:27 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-12-01 07:27:13 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
input field (4.93 KB, image/png)
2015-05-29 10:19 UTC, janez.kosmrlj 		no flags Details
view (12.57 KB, image/png)
2015-05-29 10:20 UTC, janez.kosmrlj 		no flags Details
example document (1.19 MB, application/pdf)
2015-07-02 13:11 UTC, janez.kosmrlj 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 91058 0 'medium' 'RESOLVED' 'Unicode strings saved as literal strings' 2019-11-25 16:00:27 UTC

Description janez.kosmrlj 2015-05-29 10:19:21 UTC 
Created attachment 1031844 [details]
input field

Description of problem:
When i get a PDF which has input fields i can't write the Slovene character č (unicode 268 and 269). It is displayed in the input (pic1.png), but when i move on to the next field it is not visible anymore(pic2.png). When i try to edit the same field i see that the character is still there it' just not displayed. For this reason i still have to use Adobe Reader which is not supported anymore.

Version-Release number of selected component (if applicable):
3.8.3

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 janez.kosmrlj 2015-05-29 10:20:23 UTC 
Created attachment 1031846 [details]
view
Comment 3 Marek Kašík 2015-06-22 14:28:06 UTC 
Hi,

could you attach such a PDF here so I can have a look at it (especially at fonts specified in it).
Comment 4 janez.kosmrlj 2015-07-02 13:11:01 UTC 
Created attachment 1045509 [details]
example document
Comment 5 janez.kosmrlj 2015-07-02 13:13:52 UTC 
I attached a pdf i found on the internet (example document). 
I could also send you a document we use in our company, but don't want to publish this on the internet. If you wish, i could email it to you.
Comment 6 Marek Kašík 2015-07-22 11:38:16 UTC 
Thank you for the PDF.
Unfortunately this is a problem in the PDF specification itself. If the application which creates the PDF specifies a simple font (Type1 fonts, Multi Master fonts, TrueType fonts and Type3 fonts - according to PDF spec) to use in the text field then we have only 256 characters available (the set depends on used encoding). Unfortunately, some of the accented characters are not there so they are not shown (in the standard encodings used in PDFs). The fact that you see them when entering them into the field is caused by the fact that evince handles the widgets itself when edited (you can see that the font itself can differ).
Even Adobe Reader doesn't work for me on windows and linux here (but for me the 'š' character doesn't show up - it probably depends on set of fonts available).

My findings agrees with this comprehensive comment quite well (although it is more about direct editing of PDF but it is similar to this situation):

http://stackoverflow.com/questions/15964704/java-pdfbox-reading-and-modifying-a-pdf-with-special-characters-diacritics/15973614#15973614

Maybe using a CID font with a comprehensive CID to GID mapping would help but this needs to be done by the application creatng the PDFs (I'll check whether it would work this way in poppler/evince).
Comment 7 Marek Kašík 2016-01-14 15:06:57 UTC 
I'm giving this bug devel_ack- since PDF specification does not specify how to handle this situation.
I've filed a bug for a related issue I've found during looking at this problem, you can find it here: https://bugzilla.redhat.com/show_bug.cgi?id=1298616.

Regards
Comment 8 RHEL Program Management 2016-01-14 15:26:09 UTC 
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.
Comment 9 janez.kosmrlj 2016-03-11 14:14:16 UTC 
when can we expect a fix
Comment 13 Marek Kašík 2019-06-12 13:55:13 UTC 
Hi,

I'm moving this to Red Hat Enterprise Linux 8. I'm working on this feature but I have not finished it yet. It also needs to be accepted by upstream then so I'm not giving a deadline now.

Regards
Marek
Comment 17 RHEL Program Management 2020-11-01 03:02:41 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Comment 18 Marek Kašík 2021-06-01 11:42:01 UTC 
I'm moving this bug to RHEL 9.
Comment 21 RHEL Program Management 2021-12-01 07:27:13 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Note You need to log in before you can comment on or make changes to this bug.