Bug 12851 - Lacking PDF forms i18n support
Summary: Lacking PDF forms i18n support
Status: RESOLVED FIXED
Alias: None
Product: poppler
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-18 11:59 UTC by Pedro Villavicencio
Modified: 2009-09-20 15:56 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Pedro Villavicencio 2007-10-18 11:59:23 UTC
This bug has been reported here:

"There's a character encoding problem filling out forms with localized Evince. The Norwegian characters aren't displayed like they should."

"The large text field below the text "Hvilken vare eller tjeneste klages det på?" in the test case contains the text "Ny bærbar PC kjøpt hos Elkjøp" but this text is rendered as "Ny bÊrbar PC kj¯pt hos Elk¯p"

"The wrongly rendered text is what I put in there, using the new support for PDF forms in poppler. All other Norwegian characters in the PDF, which means the text put in by the form's author (the static text), are rendered correctly."

http://launchpadlibrarian.net/10052805/Klageskjema%20bokmal-1..pdf
http://launchpadlibrarian.net/10052807/evince-print.pdf
Comment 1 Julien Rebetez 2007-10-27 08:06:44 UTC
Here are some preliminary findings :

If I force the fields in the document to use the Helvetica font (which is used to render all the others norvegian text in the document), then the fields content is correctly rendered.

Now, the fields in the document use an Arial font (which has usesMacRoman set, don't know if it matters) and the problem appears in Gfx when trying to map the unicode value to the code rendered by the font.
For example, if I enter the character U+00F8 (ø) in a text field, in Gfx.cc:3293, when calling out->drawChar, it will map the code 'f8' to the unicode 'af' when using Arial (and therefore render a '-' instead of 'ø'). When using helvetica, it simply maps 'f8' to 'f8'.
Comment 2 Michael Vrable 2008-02-13 22:07:47 UTC
This should now be fixed in the development version of poppler (as of commit fb996c46e3c6b56a2c67819620000bcd804aacd6, which adds better support for Unicode and handling different font encodings).  Tested with the document attached to the bug report, and it looks to work.
Comment 3 Alexander Potashev 2009-05-26 12:19:32 UTC
I have a similar problem: Russian text is not being rendered in forms at all (in Okular, KDE document viewer)

KDE bug report: https://bugs.kde.org/show_bug.cgi?id=193234
Comment 4 Albert Astals Cid 2009-09-20 15:56:51 UTC
I'm closing the bug because i've tried to do what KDE bug 193234 says and it doesn't work either in Adobe Reader so i don't think it's our bug, just that that particular PDF is not designed for russian input


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.