[MASTER] Can't read PDF file with CJK (Chinese/Japanese/Korean) text

Bug #197537 reported by shanen (Shannon Jacobs)
230
This bug affects 35 people
Affects Status Importance Assigned to Milestone
Poppler
Unknown
Medium
Ubuntu Japanese Kaizen Project
Fix Released
Medium
Jun Kobayashi
Ubuntu Translations
Fix Released
High
Unassigned
Debian
Fix Released
Unknown
language-selector (Ubuntu)
Fix Released
Medium
Unassigned
poppler (Ubuntu)
Invalid
Low
Unassigned

Bug Description

Binary package hint: evince

After opening a PDF file full of Japanese text, all of the Japanese is missing. Layout appears to be correct, but nothing there.

My system is fully enabled for Japanese and seems to handle it for all of the other purposes that I've tested, but there's obviously something wrong with evince in this case.

I copied the file in question over to Windows and confirmed that it is valid there. However, the content is from my bank, and I'm not going to attach it in a public place... Is there some way for me to collect diagnostic output to send instead?

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=7.10
DISTRIB_CODENAME=gutsy
DISTRIB_DESCRIPTION="Ubuntu 7.10"

The evince is 2.20.1 using poppler 0.6 (cairo)

Revision history for this message
In , Naoki-randomman (naoki-randomman) wrote :

Created an attachment (id=5786)
evince and xpdf failing.

Revision history for this message
In , Albert Astals Cid (aacid) wrote :

It would be much more interesting having the pdf than a image of the pdf
failing.

Revision history for this message
In , Rafał Mużyło (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.

Revision history for this message
In , Rafał Mużyło (galtgendo) wrote :

A minor correction, when I wrote :
"non-emmbedded fonts" I was talking of course about "non-embedded CID fonts"

Revision history for this message
In , Rafał Mużyło (galtgendo) wrote :

Oops, another misstype, instead of:
globalParams = GlobalParams ("");
it should be:
globalParams = new GlobalParams("");

Revision history for this message
In , Naoki-randomman (naoki-randomman) wrote :
Revision history for this message
In , Nickolay V. Shmyrev (nshmyrev) wrote :

The fix should be somewhere in the poppler, it's not applicatin task to care
about cidToUnicode mask.

Revision history for this message
In , Rafał Mużyło (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 ?

Revision history for this message
In , David Gómez (davidge) 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.

Revision history for this message
In , Rafał Mużyło (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.

Revision history for this message
In , Kristian Hoegsberg (krh-bitplanet) 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.

Revision history for this message
In , Rafał Mużyło (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

Revision history for this message
In , Rafał Mużyło (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 ?

Revision history for this message
In , Koji Otani (sho-bbr) wrote :

Created an attachment (id=10498)
incorrect image that evince displayed

Revision history for this message
In , Koji Otani (sho-bbr) wrote :

(From update of attachment 10498)
Very sorry, I've mistaken.
this is not for this bug.

Revision history for this message
In , Brad Hards (bradh) wrote :

I'm confused. Is anything still required on this bug? If so, what?

Revision history for this message
shanen (Shannon Jacobs) (shanen) wrote : Can't read PDF file with Japanese text

Binary package hint: evince

After opening a PDF file full of Japanese text, all of the Japanese is missing. Layout appears to be correct, but nothing there.

My system is fully enabled for Japanese and seems to handle it for all of the other purposes that I've tested, but there's obviously something wrong with evince in this case.

I copied the file in question over to Windows and confirmed that it is valid there. However, the content is from my bank, and I'm not going to attach it in a public place... Is there some way for me to collect diagnostic output to send instead?

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=7.10
DISTRIB_CODENAME=gutsy
DISTRIB_DESCRIPTION="Ubuntu 7.10"

The evince is 2.20.1 using poppler 0.6 (cairo)

Revision history for this message
Emmet Hikory (persia) wrote :

I believe the display of Japanese PDF by evince is now working in hardy, as long as multiverse poppler-data package is installed. Could you please check to see if http://tokyodebian.alioth.debian.org/pdf/debianmeetingresume200803.pdf causes the same display issues as the PDF from your bank?

If the behaviour is the same, please test the bank PDF against a Hardy Alpha liveCD, after installing the poppler-data package from multiverse to see if this bug may be closed.

Revision history for this message
shanen (Shannon Jacobs) (shanen) wrote :

Not sure what this test file is supposed to look like... There is some Japanese that does appear when look at the file, but other parts are almost surely garbled and missing text. I'll try to test both of them on another machine later, but it will probably take me a couple of days. This Sharp is kind of iffy on Ubuntu anyway. (I'm even afraid to note that I note that I haven't seen the white screen of death for several days for fear of invoking another one...)

Revision history for this message
Pedro Villavicencio (pedro) wrote :

Thanks for your report, Since it's a non public information and it contains bank information, may you please look for another pdf that shows the issue? otherwise we cannot help to get this fixed, thanks in advance.

Changed in evince:
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
Pedro Villavicencio (pedro) wrote :

Can be this bug that's affecting you? https://bugs.freedesktop.org/show_bug.cgi?id=7093 may you confirm? thanks.

Revision history for this message
Pedro Villavicencio (pedro) wrote :

no response, closing the bug.

Changed in poppler:
status: Incomplete → Invalid
Revision history for this message
Pedro Villavicencio (pedro) wrote :

re opening the bug, Emmet checked the upstream bug and it's the correct one, also linking to it, thanks everybody.

Changed in poppler:
assignee: nobody → desktop-bugs
status: Invalid → Triaged
Revision history for this message
shanen (Shannon Jacobs) (shanen) wrote :

Not sure which way you're handling this, but the bug is still present in the default document viewer as of today. However, my workaround was to install the xpdf viewer, and it handles the Japanese without any problems.

Changed in poppler:
status: Unknown → Confirmed
Revision history for this message
ibotty (ibotty) wrote :

i had a similar problem and it went away by installing (on intrepid) poppler-data. might be a try.

Revision history for this message
In , Dimitrios Symeonidis (azimout) 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.

Revision history for this message
Dimitrios Symeonidis (azimout) wrote : Re: Can't read PDF file with Japanese text

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.

I have made the same comment upstream (in debian and freedesktop)...

Revision history for this message
shanen (Shannon Jacobs) (shanen) wrote :

Well, I just checked the latest Japanese file, and it's still broken, and xpdf still works properly.

Revision history for this message
shanen (Shannon Jacobs) (shanen) wrote :

Whoops. I forgot to note that I'm running Ibix 8.10 now, and with all of the latest updates.

Revision history for this message
Dimitrios Symeonidis (azimout) wrote :

shanen, have you installed poppler-data?

Revision history for this message
shanen (Shannon Jacobs) (shanen) wrote :

With poppler-data installed it shows garbage characters all over the place. Some of them were graphic characters, and others looked like numbers from Unicode. Seems like xpdf is still the solution.

Thanks for the suggestion.

Revision history for this message
aa55aa55 (aiamama) wrote :

At first, some boring(;-) background for why I write this comment and attachment...

I had the same problem. and I was not informed of the CAUSE of this problem. So, I came by bug tracking system. And about 1 day later I was informed from this bug tracking system and a kind person that this was related with poppler-data package, and I installed the poppler-data package.

and partly this problem was fixed. But still remained very many blank letters.

I think the remained blank letters are caused NOT by the poppler-data BUT by the writer of the document (or AT LEAST, the SYSTEM(in the MS Windows OS, and the default and proprietary font For Korean, the GULIM font that OpenSource Operating System cannot provide by default.) that produced the pdf file).

But, the EVINCE program has some mistakes TOO.
These are as follows.

the Evince did not informed this Problem to the innocent user of Evince software that this problem.
the Evince should have informed to the user, if he/she was to read CJK PDF file, the poppler-data package
should be required.
the Evince was mute for this problem.

In contrast, the Adobe Reader program informs to the user about some missing font, and the processing package, and guides to install the appropriate package, when he/she attempts to open the CJK or Indic language PDF files.

the name 'evince' and its related package 'poppler-data' has no similarity or hint that those are related.

At least evince package should have information about the poppler-data as at least 'suggested'
or appropriately 'required' dependency for CJK language user environment.

Evince should not mute for the missing fonts when opening documents.
It should inform the user that "Some (GULIM for example) fonts are missing for correctly viewing this document".

That's all.

PS: the PDF document is open document. you can freely get it at the site below.

http://www.kr.freebsd.org/doc/KoreanFreeBSDHandbook/

Thank you.

Revision history for this message
aa55aa55 (aiamama) wrote :

more screenshots

Revision history for this message
aa55aa55 (aiamama) wrote :

more screenshots ..
and... You should think that....
the native CJK language using people is more than the native English/European language using people.
Thanks again.

Revision history for this message
aa55aa55 (aiamama) wrote :

last screenshot..

Happy programming/hacking..

Revision history for this message
David Gómez (dabisu) wrote :

I confirm this bug (no japanese fonts in pdf) gets solved installing poppler-data.

So it seems the fix consists in adding a new dependency to evince and/or japanese localization packages.
A simple fix, yet this bug has been opened 2 years. In 9.10, i still need to install poppler-data manually (and
got no hints of why there is no fonts in the document, only if you lauch evince from a console, you will see
there are missing font errors)

Please, fix it. Ubuntu should stop treating japanese, chinese, korean, etc. like second class citizens.
Just look at some bugs in 9.10: http://ubuntuforums.org/showthread.php?t=1317694. This is not
professional and gives Ubuntu a very bad image. Sorry for the rant, but i just had the feeling that you
guys at Ubuntu are not taking seriously this bugs.

Revision history for this message
madbiologist (me-again) wrote :

Unfortunately poppler-data is in multiverse since it includes copyrighted (and patent pending) technologies by Adobe.

However, this seems like good news in the right direction from Adobe: http://lwn.net/Articles/354360/

Revision history for this message
madbiologist (me-again) wrote :

@aa55aa55 - The output of fc-match gulim is:

DejaVuSans.ttf: "DejaVu Sans" "Book"

Do you have that font available on your system? Are the missing characters of the gulim font supposed to display as Korean, or as Roman (English)? From your statement in comment 14, I think it sounds like they should be Korean?

Note that I don't have support for Asian languages installed on my system. Could you please type fc-match gulim into a terminal on your system and let us know what the output is?

Revision history for this message
Qianqian Fang (fangq) wrote : Re: [Bug 197537] Re: [MASTER] Can't read PDF file with CJK (Chinese/Japanese/Korean) text

if we can separate the copyrighted stuff from the raw data, we
might just get around this.

Can anyone explain which part of the poppler-data are patented?

madbiologist wrote:
> Unfortunately poppler-data is in multiverse since it includes
> copyrighted (and patent pending) technologies by Adobe.
>
> However, this seems like good news in the right direction from Adobe:
> http://lwn.net/Articles/354360/
>
>

Revision history for this message
Qianqian Fang (fangq) wrote :

madbiologist wrote:
> Unfortunately poppler-data is in multiverse since it includes
> copyrighted (and patent pending) technologies by Adobe.
>
> However, this seems like good news in the right direction from Adobe:
> http://lwn.net/Articles/354360/
>
>
here are some discussions I found related to the cmap data
in the poppler-data package:

http://issues.apache.org/jira/browse/LEGAL-36
http://markmail.org/message/itzg3ppfw2phbttm

the confusing bit is the "patent pending" in the
adobe license file.

searching all adobe's CJK patents, nothing seemed
related to the cmap data:
http://www.google.com/patents?q=adobe+cjk

Revision history for this message
ZhengPeng Hou (zhengpeng-hou) wrote : Re: [Bug 197537] Re: [MASTER] Can't read PDF file with CJK (Chinese/Japanese/Korean) text

poppler-data

This package consists of encoding files for use with poppler. The
encoding files are optional and poppler will automatically read them
if they are present. When installed, the encoding files enables
poppler to correctly render CJK and Cyrrilic properly. While poppler
is licensed under the GPL, these encoding files have different license,
and thus distributed separately.

On Sun, Jan 31, 2010 at 2:27 PM, Qianqian Fang <email address hidden> wrote:
> if we can separate the copyrighted stuff from the raw data, we
> might just get around this.
>
> Can anyone explain which part of the poppler-data are patented?
>
>
> madbiologist wrote:
>> Unfortunately poppler-data is in multiverse since it includes
>> copyrighted (and patent pending) technologies by Adobe.
>>
>> However, this seems like good news in the right direction from Adobe:
>> http://lwn.net/Articles/354360/
>>
>>
>
> --
> [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 Ubuntu
> CJK Testers, which is a direct subscriber.
>

Revision history for this message
shanen (Shannon Jacobs) (shanen) wrote :

I wanted to check the status of this ancient bug, but on this particular machine I only have a VMware Player with Ubuntu as a guest OS. It runs, but I am unable to get the Japanese support to work properly for Japanese input now that I have upgraded it to the newest version of Ubuntu. I can confirm that some of the Japanese display is definitely broken now, but I can't check the status for the PDF files specifically. It will not allow me to switch to Japanese input mode, which is necessary to find the PDF files for testing.

Perhaps some parts of the problem would be fixed by installing the XPDF package on this machine, but my main conclusion is that I should not have to do such things, and I am agreed with the comments that Ubuntu seems to be going backwards. However, for me, the new problems with the sound are much more significant, and completely a show stopper in terms of recommending Ubuntu to anyone at this time. I'll go check the status of that bug report, but I know that the sound problems are unresolved on several machines that I have tested.

I want to close on a constructive note, but the only thing I can think of is to suggest that Ubuntu needs to consider a better financial model. I suggest something like what I describe in the blog entry at the URL below this paragraph. The goal is to align Ubuntu's new features with what the users want and need. In this case, they should be getting funding for fixing this specific bug, but in the more general case, they need to include feature-related funding for proper regression testing to avoid such massive failures as completely breaking the sound system... I have been using Ubuntu for several years now, and I mostly like it, but it is getting more broken with each new release. This is bad.

http://eco-epistemology.blogspot.com/2009/11/economics-of-small-donors-reverse.html

Ubuntu people: Are you listening? Ubuntu is NOW on the road to failure. Can you turn things around?

Revision history for this message
Hideki Yamane (henrich) wrote :

Hi, I'm maintainer poppler-data package in Debian.
It is now in main in Debian, since it is under BSD-style license.

Revision history for this message
Hideki Yamane (henrich) wrote :
Revision history for this message
madbiologist (me-again) wrote :

Thanks Hideki,

Info regarding the poppler-data package moving to Debian main with the upload of 0.4.0-1 can be found at http://packages.qa.debian.org/p/poppler-data/news/20091230T131724Z.html , thanks to a CMap licence change by Adobe.

A launchpad request for Ubuntu has been created at https://bugs.launchpad.net/ubuntu/+source/poppler-data/+bug/515078

Changed in debian:
status: Confirmed → Fix Released
Revision history for this message
YannUbuntu (yannubuntu) wrote :

Dear all, thank you for your efforts on this bug.
I updated my Ubuntu9.10 now and I still can't read the files mentionned in Bug #197188:
http://launchpadlibrarian.net/12338195/Example%20of%20PDF%20that%20cant%20be%20read%20except%20by%20XPDF.pdf
and http://launchpadlibrarian.net/13836537/applicationJP.pdf

Revision history for this message
westwind (sgr02061) wrote : [Bug 197537] Re: [MASTER] Can't read PDF file with CJK (Chinese/Japanese/Korean) text

I'm tested The pdf documents reported a new problem "can't read text string co
ntained CJK (Chinese/Japanese/Korean) after added some custom Japanese font pa
ckages released via ubuntu Japanese team.

and... reported 2 pdf documents are both able to read about Japanese font text
.

[Detail info.]

(a)Install list of Japanese font packages into ubuntu 9.10 system.

(a-1)"ttf-umefont" (Ume Font)
(a-2)"ttf-konatsu" (Konatsu Font)
(a-3)"ttf-manafont"(Mona Font)

#Above fonts are can install additional Installer:"ubuntu-ja-setup-helper"(Sel
ect and install popular packages for Japanese users) in Japanese edition remix
 CD.

(b)Results of testing.

Able to read the ja text that uneble to when Only installed "poppler-data".

(b-1):http://launchpadlibrarian.net/12338195/Example%20of%20PDF%20that%20cant%
20be%20read%20except%20by%20XPDF.pdf

From reporting Document viewer ("File"->"Property"), this document uses 2 kind
s of "Century" font and 2 kinds of "Arial" font, and all fonts is not built in
.

This PDF may assumes already installed Century font (sometimes non-free) in br
ower machine (bundled MS-findows Japanese edition and WS-Word for Japanese edi
tion uses this font)

This document author may be to only (and so unaware) consider for MS-Windows u
sers browsing.

(At making this Document, the author uses easy authoring tool works on MS-Wind
ows)

(b-2):"http://launchpadlibrarian.net/13836537/applicationJP.pdf"

This document uses "MS-mincho" and "Century", and all fonts is not built in.

"MS-mincho" is Japanese font for MS-Windows system only, so other OS system co
uld not use for diplay.

This document author may be to only consider for MS-Windows users browsing.

(At making this Document, the author uses authoring works on MS-Windows, and t
arget assumes to MS-WORD)

[End of detail info.]

Limited about "can't read ja text", one of cause this BUG, Japanese user of ub
untu not well known if Additional installer:"ubuntu-ja-setup-helper" not execu
ted, any ja font will may not read pdf files that have none-built-in fonts.

#I'm also included in above "not well known" users...

Revision history for this message
YannUbuntu (yannubuntu) wrote :

Thanks for your feedback westwind.
I can't reproduce your solution:
- I installed "ttf-umefont", "ttf-konatsu" and "ttf-mona" (that installed "xutils" by dependancy also) from the Universe repository. -> unable to read the documents with Evince
- then I reloaded the fonts (sudo fc-cache -f -v) -> unable to read the documents with Evince
- then I restarted my session -> unable to read the documents with Evince
- then I added the Japanese team repositories (http://archive.ubuntulinux.jp/ubuntu karmic main , and http://archive.ubuntulinux.jp/ubuntu-ja karmic-non-free ), and updated my package list -> no different version of the above fonts packages

So finally I am still unable to read the documents with Evince.
Hope this can help.

Revision history for this message
YannUbuntu (yannubuntu) wrote :

hi again,
after playing with ubuntu-ja-setup-helper (which is quite dangerous by the way, it uninstalled me thunderbird and other things), I managed to read the documents with Evince. By looking in my Synaptics history, I uninstalled the packages one by one, and it seems that the package "poppler-data" (Karmic version: 0.2.1-5) allows me to read the documents.
I then uninstalled all the fonts-related packages (the 3 above, and ttf-kochi-gothic, ttf-kochi-mincho, otf-ipafonts, gsfonts-x11, opfc-..., ttf-ipamonafont), and I still can read the docs. If I uninstall poppler-data, I can't read the docs any more.

In conclusion: it looks like "poppler-data" was not installed by default on Karmic, and that it allows me to read the docs.

Hope this helps.

Revision history for this message
westwind (sgr02061) wrote :

To YannUbuntu & other subscribers:

Sorry to my late reply.

About "I can't reproduce your solution" told by YannUbuntu:

My test sequence is starting to below install after installed and stay "popple
r-data (0.2.1-5)":

*"ttf-umefont (404-2)"
*"ttf-konatu (24-3)"
*"ttf-ipamonafont (release1.0.8-0ubuntu0ja3)"

*"xutils (1:7.4+3ubuntu10)"
*"opfc-modulehp-ipamonafont-source (1.1.1+1.0.8-0ubuntu0ja1)"

---
Install Log for making test bed.

Original log by "Synaptic(0.62.7.ubuntu6)" Japanese message edition; massage a
re translated ja to en.
Time stamps are JST (UCT+9).

-
Commit Log for Tue Feb 2 10:26:41 2010

Upgraded below packages:
 :
(Upgraded each packages after installing from Japanese remix CD-ROM)
 :

-
Commit Log for Tue Feb 2 12:58:22 2010

Installed below packages:
poppler-data (0.2.1-5)

-
Commit Log for Fri Feb 5 02:27:30 2010

Installed below packages:
opfc-modulehp-ipamonafont-source (1.1.1+1.0.8-0ubuntu0ja1)
ttf-ipamonafont (release1.0.8-0ubuntu0ja3)
ttf-konatu (24-3)
ttf-umefont (404-2)
xutils (1:7.4+3ubuntu10)

---

And now, after uninstall "ttf-umefont","ttf-konatu" and "ttf-ipamonafont" ("po
ppler-data" and others are still installed), blow sample PDFs (shown by YannUb
untu) able to display successfully.

http://launchpadlibrarian.net/12338195/Example%20of%20PDF%20that%20cant%20be%2
0read%20except%20by%20XPDF.pdf
http://launchpadlibrarian.net/13836537/applicationJP.pdf

#Some other PDF documents also tested successfuly, but these PDF including the
 association name clearly. Can I upload for future testing?

Candidate samples (Mar. 1st, 2010)
http://www.city.iwakuni.yamaguchi.jp/html/sinseisyodown/syuuzei/ininnjyo.pdf
http://www.westjr.co.jp/news/newslist/article/pdf/20100210_22_2_22_kanazawa.pd
f
http://www.westjr.co.jp/ICSFiles/afieldfile/2010/02/25/20100225_toyama.pdf

Revision history for this message
YannUbuntu (yannubuntu) wrote :

I feel that for you too the "poppler-data" could also be the key ?

Can someone confirm if the "poppler-data" package is installed by default in a fresh Ubuntu install ? (the standard one, not the Japanese Team remix)

Revision history for this message
westwind (sgr02061) wrote :

Now confirming of "poppler-data" that package is also key at default settings and install status ubuntu.
(Install image downloaded from http://www.ubuntu.com/getubuntu/download/ ; download location is "Japan")

At language locale set to "ja" and only apply system update patches, evince can not display "http://launchpadlibrarian.net/12338195/Example%20of%20PDF%20that%20cant%
20be%20read%20except%20by%20XPDF.pdf". (->Before install "poppler-data"; 2010 Mar.02nd 00:32a.m.(JST+9))

(to be continue to next post)

Revision history for this message
westwind (sgr02061) wrote :

(continued from previous)

After installing "poppler-data", evince can display correctly (->After installed "poppler-data"; 2010 Mar.02nd 00:41a.m.(JST+9)).

Other system locales (eg. "en", "zh", etc...) are not tested yet.

Revision history for this message
YannUbuntu (yannubuntu) wrote :

Thank you for your feedback.

So a "workaround" for this bug would be "install poppler-data package" ? (needs to be confirmed with all example files)

In this case, a definitive solution to this bug would be to automatically install poppler-data package when installing Japanese language in the system.

We need feedback from the developpers.

Revision history for this message
Arne Goetje (arnegoetje) wrote :

I have issued a Main Inclusion Request (Bug #530452). Once this is through, we will try to seed it to the Live CD.

Revision history for this message
YannUbuntu (yannubuntu) wrote :

Thank you !

Revision history for this message
westwind (sgr02061) wrote :

Now, I'm executing below locales matrix test at keeping same time updating(include ubuntu own; using 4 boot devices).

System locales at ubuntu:
en, ja, kr, zh-cn

Font locale included in pdf files:
ja, kr, zh-tw

#I can't find out "zh-cn" pdf files yet, so will use "zh-tw" PDFs alternately.

Files list of "zh-tw" (16 files under the http://www.doh.gov.tw/CHT2006/DM/DM2_p01.aspx?class_no=460&now_fod_list_no=10953&level_no=1&doc_no=74155 )

http://www.doh.gov.tw/ufile/doc/%E7%A9%A9%E5%AE%9A%E5%81%A5%E4%BF%9D%E8%B2%A1%E5%8B%99%E4%BB%A5%E7%A2%BA%E4%BF%9D%E5%B0%B1%E9%86%AB%E7%84%A1%E7%A4%99.pdf

http://www.doh.gov.tw/ufile/doc/01%E5%8F%B0%E7%81%A3%E5%81%A5%E4%BF%9D%E4%BF%97%E6%93%B1%E5%A4%A7%E7%A2%97.pdf

http://www.doh.gov.tw/ufile/doc/02%E5%BC%B1%E5%8B%A2%E6%B0%91%E7%9C%BE.pdf

http://www.doh.gov.tw/ufile/doc/03%E9%96%8B%E6%BA%90%E7%AF%80%E6%B5%81.pdf

http://www.doh.gov.tw/ufile/doc/%e6%b8%9b%e5%b0%91%e5%81%a5%e4%bf%9d%e8%97%a5%e5%83%b9%e5%b7%ae%20%e5%a2%9e%e9%80%b2%e6%b0%91%e7%9c%be%e7%94%a8%e8%97%a5%e6%ac%8a%e7%9b%8a.pdf

http://www.doh.gov.tw/ufile/doc/%e7%82%ba%e4%bb%80%e9%ba%bc%e6%9c%83%e6%9c%89%e3%80%8c%e8%97%a5%e5%83%b9%e9%bb%91%e6%b4%9e%e3%80%8d%ef%bc%9f.pdf

http://www.doh.gov.tw/ufile/doc/%e7%82%ba%e4%bd%95%e5%81%a5%e4%bf%9d%e8%97%a5%e8%b2%bb%e4%b8%80%e7%9b%b4%e6%88%90%e9%95%b7%ef%bc%9f.pdf

http://www.doh.gov.tw/ufile/doc/05%E6%95%B4%E5%90%88%E6%80%A7%E9%86%AB%E7%99%82.pdf

http://www.doh.gov.tw/ufile/doc/06%E8%B2%A1%E5%8B%99%E7%82%BA%E4%BB%80%E9%BA%BC%E7%9F%AD%E7%B5%80.pdf

http://www.doh.gov.tw/ufile/doc/07%E4%BA%92%E5%8A%A9%E6%BF%9F%E8%B2%A7%E5%88%A9%E4%BB%96%E7%A4%BE%E6%9C%83.pdf

http://www.doh.gov.tw/ufile/doc/08%E8%B2%BB%E7%8E%87%E8%AA%BF%E6%95%B4%E4%B9%8B%E5%BF%85%E8%A6%81%E6%80%A7.pdf

http://www.doh.gov.tw/ufile/doc/09%E5%81%A5%E4%BF%9D%E6%94%B9%E9%9D%A9.pdf

http://www.doh.gov.tw/ufile/doc/10_%E6%96%B9%E4%BE%BF%E5%B0%B1%E9%86%AB%E8%88%87%E9%81%8E%E5%BA%A6%E4%BD%BF%E7%94%A8%E9%86%AB%E7%99%82.pdf

http://www.doh.gov.tw/ufile/doc/11%E5%A4%9A%E7%94%A8%E5%AE%89%E5%AF%A7%E7%99%82%E8%AD%B7%E7%B6%AD%E8%AD%B7%E9%86%AB%E7%99%82%E7%92%B0%E4%BF%9D.pdf

http://www.doh.gov.tw/ufile/doc/12_%E6%84%9B%E5%BF%83%E6%8E%A5%E5%8A%9B%E7%94%9F%E5%91%BD%E6%8E%A5%E7%BA%8C.pdf

http://www.doh.gov.tw/ufile/doc/%E5%B0%8D%E9%86%AB%E6%94%B9%E6%9C%83%E6%8F%90%E5%87%BA%E4%B9%8B%E7%95%B6%E5%89%8D%E5%8D%81%E5%A4%A7%E9%86%AB%E7%99%82%E6%B0%91%E6%80%A8%E7%9A%84%E7%9C%81%E6%80%9D.pdf
---

Notice:
I can check only "ja" PDFs to correctly detail articles. "kr" & "zh-tw" PDFs are only able to check as draft browsing.

*Reason:
I'm not read Hangul at all, only see as enigmatic pictograms.
Kanji in "zh-tw" is Readable a little better, but unable to completely determine on correctly article or not as "zh-tw".

---
#It's a slowfooted operation like Galapagos Tortoise... ;-|

Revision history for this message
Arne Goetje (arnegoetje) wrote :

OK, MIR is through. But as we don't have any spare space on the LiveCD, we will implement this in language-selector instead. poppler-data should be pulled from the archive for every language.

Changed in language-selector (Ubuntu):
status: New → In Progress
assignee: nobody → Arne Goetje (arnegoetje)
importance: Undecided → Medium
milestone: none → ubuntu-10.04-beta-2
Arne Goetje (arnegoetje)
Changed in language-selector (Ubuntu):
milestone: ubuntu-10.04-beta-2 → ubuntu-10.04
Arne Goetje (arnegoetje)
Changed in language-selector (Ubuntu):
milestone: ubuntu-10.04 → later
status: In Progress → Triaged
Rolf Leggewie (r0lf)
Changed in ubuntu-jp-improvement:
status: New → Confirmed
Arne Goetje (arnegoetje)
Changed in language-selector (Ubuntu):
milestone: later → maverick-alpha-3
Changed in poppler (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
Arne Goetje (arnegoetje)
Changed in poppler (Ubuntu):
status: Triaged → Invalid
Arne Goetje (arnegoetje)
Changed in language-selector (Ubuntu):
status: Triaged → In Progress
Changed in language-selector (Ubuntu):
milestone: maverick-alpha-3 → ubuntu-10.10-beta
Arne Goetje (arnegoetje)
Changed in language-selector (Ubuntu):
assignee: Arne Goetje (arnegoetje) → nobody
status: In Progress → Triaged
Changed in poppler:
importance: Unknown → Medium
Revision history for this message
Fumihito YOSHIDA (hito) wrote :

Hi all, I want to marshal this bugs status.

It seems this bug's primary work had spread into below bugs.
 - https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/623825
 - https://bugs.launchpad.net/ubuntu/+source/evince/+bug/616321

I believe below status, and this bug is obsoleted/duped, isnt it?

1) the Poppler project's bug(freedesktop-bugs #7093) is solved by Adobe's new license policy. Its solved. And poppler-data has been MIRed.

2) the Ubuntu Japanese Kaizen Project's bug is solved by "Japanese Remix", that released with poppler-data in Lucid phases.

3) language-selector bug is dup of LP#623825.

Changed in ubuntu-jp-improvement:
assignee: nobody → Jun Kobayashi (jkbys)
importance: Undecided → Medium
status: Confirmed → Fix Released
Revision history for this message
fugounashi (fugounashi+launchpad) wrote :

 I had to manually install poppler-data for Japanese to appear in PDFs in evince in 10.4

Revision history for this message
otax (otax38) wrote :

I confirm exactly the post of Fugounashi.

Evince of 10.04 doesn't work correctly in japanese without poppler-data.
I had to add with Synaptic too.
The pdf was ok after that.

Changed in poppler:
importance: Medium → Unknown
Aron Xu (happyaron)
Changed in ubuntu-translations:
importance: Undecided → High
status: New → Triaged
Changed in poppler:
importance: Unknown → Medium
Revision history for this message
quequotion (quequotion) wrote :

Five years have passed and this bug is not fixed. (see duplicate #48708 from 2006)

Attached is a screenshot of the manual for my microwave in evnice.

All the layout and graphical elements are there, but there's no text on the page.

The package poppler-data solves this issue.

The only question is which package(s) should depend on it.

I vote for a recommendation in language-pack-ja and a dependency in libpoppler.

Revision history for this message
quequotion (quequotion) wrote :

This issue could be resolved if libpoppler included a dependency for poppler-data.

Changed in poppler (Ubuntu):
status: Invalid → New
Revision history for this message
Nobuto Murata (nobuto) wrote :

Hi quequotion,
in current development release Natty, language-selector installs poppler-data for Arabic, Chinese, Japanese, and Korean locales. Please refer Bug #623825.

From this comment,
https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/623825/comments/2
it seems not likely installing poppler-data through dependency in Ubuntu.

In Ubuntu, this ticket is a duplicate of Bug #623825, but this has other tasks.
Instead of marking duplicate, I will mark Fix Released against just Ubuntu tasks.

---------------
language-selector (0.27) natty; urgency=low

  * data/pkg_depends: Update for libreoffice and changed thesaurus/hyphenation
    package names. Update test cases accordingly.
  * data/pkg_depends: Add poppler-data for Arabic, Chinese, Japanese, and
    Korean. (LP: #623825)
 -- Martin Pitt <email address hidden> Fri, 18 Mar 2011 18:37:04 +0100

Changed in poppler (Ubuntu):
status: New → Invalid
Changed in ubuntu-translations:
status: Triaged → Fix Released
Changed in language-selector (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
David Monniaux (david-monniaux) wrote :

Problem still current in 10.10. The error message should state which package to install. The fix discussed above does not address the problem of people running Western locales but opening files containing Japanese characters (say, students of Japanese, or travellers to Japan who have received a city map with Japanese names!).

Revision history for this message
YannUbuntu (yannubuntu) wrote :

Dear all,
still experiencing the bug on Ubuntu 11.04 : updated packages, French system, I fully installed Japanese via language-selector, restarted the pc and restarted language-selector to finish installing language packages, and still poppler-data is not installed. (so I can't read some Japanese PDF like those in post #46)

Revision history for this message
shanen (Shannon Jacobs) (shanen) wrote :

god damn spammer. How is this sort of crap supposed to be reported?

Revision history for this message
westwind (sgr02061) wrote :

>god damn spammer. How is this sort of crap supposed to be reported?

I reported spammed #67 (wrote on 2011-09-30) to:

(1)WOT (Web of Trust):
(a forum comment) http://www.mywot.com/en/forum/7508--canadian-pharmacy-domains?comment=111180#comment-111180
(a comment on reputation ratings) http://www.mywot.com/en/scorecard/pharmacyprescriptionweb.com.ua/comment-29128410

(2)some divisions of Japanese gov. via organization agencies

Started similar spam reporting to some divisions of Japanese gov. too.

Revision history for this message
WR Franklin (g-launchpad-wrfranklin-org) wrote :

English document is displayed w/o fonts, but with this error:

Error: Unknown font tag 'F3'
Error: No font in show
Error: Unknown font tag 'F1'
Error: No font in show
Error: Unknown font tag 'F1'

okular and acroread display the document. Converting it to PS then back to PDF makes a document that works with evince.

I've read other postings that blame the PDF creator. For political reasons I can't complain to him.

So, I must use the free commercial program acroread instead of evince.

Revision history for this message
Oscar Blanco (orblancog-b) wrote :

I had to install:

ttf-kochi-gothic
ttf-kochi-mincho
ttf-sazanami-gothic
ttf-sazanami-mincho
ttf-umefont ttf-mona

and do:

$ sudo fontconfig-voodoo -f -s ja_JP

output is not excellent, but characters are visible.

Revision history for this message
In , Gitlab-migration (gitlab-migration) wrote :

-- 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.

Changed in poppler:
status: Confirmed → Unknown
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.