Launchpad has imported 18 comments from the remote bug at http://bugs.freedesktop.org/show_bug.cgi?id=7093.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2006-06-01T16:57:57+00:00 Naoki-randomman wrote: = 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 Reply at: https://bugs.launchpad.net/poppler/+bug/197537/comments/0 ------------------------------------------------------------------------ On 2006-06-01T16:59:25+00:00 Naoki-randomman wrote: Created an attachment (id=5786) evince and xpdf failing. Reply at: https://bugs.launchpad.net/poppler/+bug/197537/comments/1 ------------------------------------------------------------------------ On 2006-06-02T00:00:50+00:00 Tsdgeos wrote: It would be much more interesting having the pdf than a image of the pdf failing. Reply at: https://bugs.launchpad.net/poppler/+bug/197537/comments/2 ------------------------------------------------------------------------ On 2006-06-03T10:09:23+00:00 Galtgendo wrote: 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. Reply at: https://bugs.launchpad.net/poppler/+bug/197537/comments/3 ------------------------------------------------------------------------ On 2006-06-03T10:17:53+00:00 Galtgendo wrote: A minor correction, when I wrote : "non-emmbedded fonts" I was talking of course about "non-embedded CID fonts" Reply at: https://bugs.launchpad.net/poppler/+bug/197537/comments/4 ------------------------------------------------------------------------ On 2006-06-03T10:25:25+00:00 Galtgendo wrote: Oops, another misstype, instead of: globalParams = GlobalParams (""); it should be: globalParams = new GlobalParams(""); Reply at: https://bugs.launchpad.net/poppler/+bug/197537/comments/5 ------------------------------------------------------------------------ On 2006-06-06T23:50:13+00:00 Naoki-randomman wrote: Re-opened gnome / evince bug : http://bugzilla.gnome.org/show_bug.cgi?id=343564 Reply at: https://bugs.launchpad.net/poppler/+bug/197537/comments/6 ------------------------------------------------------------------------ On 2006-06-07T00:22:02+00:00 Nickolay V. Shmyrev wrote: The fix should be somewhere in the poppler, it's not applicatin task to care about cidToUnicode mask. Reply at: https://bugs.launchpad.net/poppler/+bug/197537/comments/7 ------------------------------------------------------------------------ On 2006-06-12T16:02:06+00:00 Galtgendo wrote: 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 ? Reply at: https://bugs.launchpad.net/poppler/+bug/197537/comments/8 ------------------------------------------------------------------------ On 2006-09-12T08:01:56+00:00 David Gómez wrote: 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. Reply at: https://bugs.launchpad.net/poppler/+bug/197537/comments/9 ------------------------------------------------------------------------ On 2006-09-19T06:10:54+00:00 Galtgendo wrote: Created an attachment (id=7069) 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. Reply at: https://bugs.launchpad.net/poppler/+bug/197537/comments/10 ------------------------------------------------------------------------ On 2006-09-20T14:49:40+00:00 Kristian Hoegsberg wrote: 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. Reply at: https://bugs.launchpad.net/poppler/+bug/197537/comments/11 ------------------------------------------------------------------------ On 2006-09-22T04:41:17+00:00 Galtgendo wrote: 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 Reply at: https://bugs.launchpad.net/poppler/+bug/197537/comments/12 ------------------------------------------------------------------------ On 2006-09-22T04:59:05+00:00 Galtgendo wrote: 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 ? Reply at: https://bugs.launchpad.net/poppler/+bug/197537/comments/13 ------------------------------------------------------------------------ On 2007-06-28T19:25:04+00:00 Koji Otani wrote: Created an attachment (id=10498) incorrect image that evince displayed Reply at: https://bugs.launchpad.net/poppler/+bug/197537/comments/14 ------------------------------------------------------------------------ On 2007-06-28T19:27:42+00:00 Koji Otani wrote: (From update of attachment 10498) Very sorry, I've mistaken. this is not for this bug. Reply at: https://bugs.launchpad.net/poppler/+bug/197537/comments/15 ------------------------------------------------------------------------ On 2007-12-22T15:43:40+00:00 Brad Hards wrote: I'm confused. Is anything still required on this bug? If so, what? Reply at: https://bugs.launchpad.net/poppler/+bug/197537/comments/16 ------------------------------------------------------------------------ On 2009-01-27T06:02:14+00:00 Dimitrios Symeonidis wrote: 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. Reply at: https://bugs.launchpad.net/poppler/+bug/197537/comments/26 ** Changed in: poppler Importance: Unknown => Medium ** Bug watch added: GNOME Bug Tracker #343564 https://bugzilla.gnome.org/show_bug.cgi?id=343564 ** Bug watch added: GNOME Bug Tracker #320866 https://bugzilla.gnome.org/show_bug.cgi?id=320866 -- [MASTER] Can't read PDF file with CJK (Chinese/Japanese/Korean) text https://bugs.launchpad.net/bugs/197537 You received this bug notification because you are a member of Registry Administrators, which is the registrant for Debian. _______________________________________________ Mailing list: https://launchpad.net/~registry Post to : [email protected] Unsubscribe : https://launchpad.net/~registry More help : https://help.launchpad.net/ListHelp
