Poppler renders some characters in forms as "fi" instead of showing the correct glyph or nothing (if the font doesn't contain necessary glyphs). This can be reproduced by opening the form from https://bugzilla.gnome.org/show_bug.cgi?id=756805 and typing "šč" into a text field. Actual result is "fifi". I've found that there are 2 minor bugs which if fixed improves the situation a little. The first one is that there is a misplaced continue statement in "CharCodeToUnicode::mapToCharCode()". It should be called on the parent loop instead of the nested one. After fixing this, there are no characters shown which should be the case if it doesn't find them. The second one is that "Annot::Layout()" calls "ccToUnicode->mapToCharCode(&uChar, &c, 2)" with wrong parameter. The last one should be "1" because the uChar is Unicode and hence the &uChar is an array with just one member, not 2. After fixing this, at least the "š" is shown. See the attached patches.
Created attachment 119072 [details] [review] Find correct glyph or return 0
Created attachment 119073 [details] [review] Fix showing of some non-ASCII characters
"It should be called on the parent loop instead of the nested one. After fixing this, there are no characters shown which should be the case if it doesn't find them." Why? Doesn't "if (j==sMap[i].len) {" exactly do what your new variable does?
I think Albert is right. Instead of adding the variable to make the continue statement, probably just changing the continue to a break statement should work.
Created attachment 119132 [details] [review] Find correct glyph or return 0 You are right, the break is enough.
Both patches pushed, tahnks!
I can now write "š" into the form from attachment 313655 , but I can't write "ě", "č", "ř", "ď", "ť", "ň". And maybe some others. Is that expected? poppler-0.41.0-1.fc24.x86_64
A working link to the sample form: https://bugzilla.gnome.org/attachment.cgi?id=313655 The characters are no longer converted to "fi", they simply disappear when being rendered.
(In reply to Kamil Páral from comment #7) > I can now write "š" into the form from attachment 313655 , but I can't write > "ě", "č", "ř", "ď", "ť", "ň". And maybe some others. Is that expected? This is expected because the other characters are not part of PDFDocEncoding.
Thanks, Marek. Is there some chance of having this "fixed" (i.e. worked around the same way Adobe Reader does it - by taking a system font and attaching it to the pdf document) in a foreseeable future? Because currently most of government- or bussiness-related pdf forms (in my country) can't be filled out on Linux, the only way is to run Windows and Adobe Reader. And that's a strong reason for people to say they can't use Linux, which makes me sad. I understand those pdf forms are not well created, they should have contained the correct font covering all needed glyphs. But I can complain as much as I want to the form authors (I did, many times) - as long as it works for 99% of people, they're not going to waste their time on this.
(In reply to Kamil Páral from comment #10) > Thanks, Marek. Is there some chance of having this "fixed" (i.e. worked > around the same way Adobe Reader does it - by taking a system font and > attaching it to the pdf document) in a foreseeable future? Because currently > most of government- or bussiness-related pdf forms (in my country) can't be > filled out on Linux, the only way is to run Windows and Adobe Reader. And > that's a strong reason for people to say they can't use Linux, which makes > me sad. I understand those pdf forms are not well created, they should have > contained the correct font covering all needed glyphs. But I can complain as > much as I want to the form authors (I did, many times) - as long as it works > for 99% of people, they're not going to waste their time on this. I would like to work on this but I don't have time for it now. If I'll find some time for it (or time of my colleagues) I'll look at it but I can not promise anything.
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.