registry team mailing list archive
-
registry team
-
Mailing list archive
-
Message #14355
[Bug 197537] Re: [MASTER] Can't read PDF file with CJK (Chinese/Japanese/Korean) text
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.
