Summary: | Lacking PDF forms i18n support | ||
---|---|---|---|
Product: | poppler | Reporter: | Pedro Villavicencio <pvillavi> |
Component: | general | Assignee: | poppler-bugs <poppler-bugs> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | aspotashev, julien |
Version: | unspecified | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Pedro Villavicencio
2007-10-18 11:59:23 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'. 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. 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 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.