Created attachment 116655 [details] 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.
Created attachment 116656 [details] [review] Save Unicode strings as hexadecimal strings This patch fixes the mentioned problem for me.
Looking more on this, it is possible that the problem is the font specified in the PDF (LiberationSans with FirstChar 32 and LastChar 255) which doesn't includes the mentioned characters. I've filled this because acroread is able to show the string correctly when it is stored as hexadecimal string, so maybe it is still worth to apply?
Yes, this is simply a duplicate of the multiple "can't save non ascii text on forms" bugs we have. And the gut feeling is that the bug is that we're simply doing something wrong with the fonts, like setting ascii encoding or something, never had enough time to look at this.
The problem is actually in PDF specification. It doesn't specify how to deal with non-ascii text in forms. All simple fonts (chapter 5.5) use 8bit codes which is not enough so they can not be used generally (including all the 14 base fonts). One possibility here seems to use a CID font. Or try to go beyond the 8bit constraint and try to find whether the font you use has the the glyphs for the Unicode characters you use when rendering text. Btw, this comment summarises font problems arising when changing a text in PDF quite well: http://stackoverflow.com/a/15973614. Btw2, Adobe Reader stores text which includes non-ascii characters as unicode hexadecimal strings and ascii only text as normal strings. But it also changes font in the PDF to a CID font in the non-ascii case.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/523.
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.