= Transfering this bug from GNOME Bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=343564 = PDF documents created with Microsoft office with Japanese fonts do not render correctly (at all). As if the font was missing. Steps to reproduce: 1. Create a document in MS Office using Japanese characters. 2. Export as PDF 3. Open in Evince. Actual results: File is open with no text. Expected results: Rendered japanese fonts would be visible as when the document was created. Does this happen every time? Yes. Other information: Seems to be the same bug as http://bugzilla.gnome.org/show_bug.cgi?id=320866 Simple test documents created in OpenOffice work as expeceted. This problem also affects Xpdf making me thing it's a font issue. Output from evince is : evince Desktop/バリューコマース株式会社様 御見積書12.pdf Error: could not create truetype face some font thing failed Error: could not create truetype face some font thing failed Error: could not create truetype face some font thing failed Error: could not create truetype face some font thing failed .. Xpdf prints this : xpdf Desktop/バリューコマース株式会社様 御見積書12.pdf Error: Couldn't create a font for 'MS-Gothic' Error: Couldn't create a font for 'MS-PMincho' Error: Couldn't create a font for 'MS-PMincho' Error: Couldn't create a font for 'MS-PMincho' Error: Couldn't create a font for 'MS-PMincho' ... and so on repeating the same error. msttfontcore is installed. Problem persists with current dev tree versions of evince/xpdf. -------- Comment #3 from Nickolay V. Shmyrev (points: 19) 2006-06-01 12:39 UTC [reply] Hi, this looks like a bug with the PDF backend. Could you please follow these instructions to help get this bug fixed. Thank You. http://live.gnome.org/Evince/PopplerBugs#poppler
Created attachment 5786 [details] evince and xpdf failing.
It would be much more interesting having the pdf than a image of the pdf failing.
Ok, first of all, I HATE BUGZILLA !!!! Having said that, let's come to the point. Issue stated here is an evince bug, not a poppler one. Xpdf relied on xpdfrc file for font substitution while handling non-emmbedded fonts. Poppler still does, but now you have to explicitly call GlobalParams metod to read that file. In fact if you add in pdf/ev-poppler.cc something as simple as: #include <GlobalParams.h> in poppler include block and globalParams = GlobalParams (""); in pdf_document_init (PdfDocument *pdf_document), xpdfrc gets to be read (.xpdfrc in $HOME , if you have it, /etc/xpdfrc otherwise), and if that file contains correct entries those japanese pdfs are displayed correctly. Of course, only required entries are cidToUnicode and cMapDir, as the rest is handled by fontconfig (Cmaps are often installed with ghostscript, cidToUnicode files have to be taken from xpdf). For pdf examples check http://www.japanpen.or.jp/e-bungeikan/index.html on its subpages there are dozens of those. Oops, missed the fact that you transfed it FROM evince bugzilla, you probably should transer it back, I'm not planning to register to anoter bugzilla today.
A minor correction, when I wrote : "non-emmbedded fonts" I was talking of course about "non-embedded CID fonts"
Oops, another misstype, instead of: globalParams = GlobalParams (""); it should be: globalParams = new GlobalParams("");
Re-opened gnome / evince bug : http://bugzilla.gnome.org/show_bug.cgi?id=343564
The fix should be somewhere in the poppler, it's not applicatin task to care about cidToUnicode mask.
You're probably sort of right, but still there's a need for some config file with a path to CIDMaps. As it goes for cidtoUnicode mappings, as they are fixed (at least as far as I know) I think it would be a good idea to include them as static data to either poppler or evince. Does anybody know somthing about nametoUnicode file from Thai xpdf package, namely is it still required as those cidtoUnicode files ?
It doesn't seem yet that CID to unicode mappings xpdf files has been included in poppler since this bug was reported. Is there any other proposed solution? With CVS code japanese pdf's with non-embedded fonts are not readable.
Created attachment 7069 [details] [review] patch (for evince) to make evince work Well, I'm still using my little hack and files from xpdf. This is a patch for evince 0.6.0, I moved place where I inserted GlobalParams line, cause with gtk 2.10 it stopped working. All you need to do is apply patch, run autoconf and configure will do the rest. If it works in xpdf, with this patch it will work in evince.
This is fixed now in poppler CVS. Evince should not care about this. You will need to download and install the poppler-data package for this to work.
Ok, it works now, but... 1. As not all of us have working crystal balls, it would be good to document this change, as there was no /usr/share/poppler before, so adding a line about it in README seems like a good idea. 2. poppler 0.5.4 can't be autotooled - in configure.ac in one of PKG_CHECK_MODULES checks for glib instead of glib-2.0
And BTW, is parsing unicodeMap really necessary ? I don't now xpdf internals, but I suspect that those were needed cause xpdf was not internally unicode, as poppler is, I think it SHOULD work without it. Could somebody test that ?
Created attachment 10498 [details] incorrect image that evince displayed
Comment on attachment 10498 [details] incorrect image that evince displayed Very sorry, I've mistaken. this is not for this bug.
I'm confused. Is anything still required on this bug? If so, what?
What needs to be done (in my point of view, at least) is for evince to display a warning like "CJK font support is included in the non-free package poppler-data, which is currently not installed on your system" in these cases.
-- 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/114.
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.