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

Bug #197537 reported by shanen (Shannon Jacobs) on 2008-03-02
This bug affects 34 people
Affects Status Importance Assigned to Milestone
Ubuntu Japanese Kaizen Project
Jun Kobayashi
Ubuntu Translations
Fix Released
language-selector (Ubuntu)
poppler (Ubuntu)

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?


The evince is 2.20.1 using poppler 0.6 (cairo)

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

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

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("");

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

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 an attachment (id=10498)
incorrect image that evince displayed

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

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

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?


The evince is 2.20.1 using poppler 0.6 (cairo)

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.

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

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

Pedro Villavicencio (pedro) wrote :

no response, closing the bug.

Changed in poppler:
status: Incomplete → Invalid
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

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
ibotty (ibotty) wrote :

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

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.

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

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

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

Dimitrios Symeonidis (azimout) wrote :

shanen, have you installed poppler-data?

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.

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.


Thank you.

aa55aa55 (aiamama) wrote :

more screenshots

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.

aa55aa55 (aiamama) wrote :

last screenshot..

Happy programming/hacking..

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.

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/

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?

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/

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:


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:


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.

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.


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

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.

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
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:
and http://launchpadlibrarian.net/13836537/applicationJP.pdf

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

(b)Results of testing.

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


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


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

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.

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.

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.


#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)

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)

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)

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.

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.

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.

YannUbuntu (yannubuntu) wrote :

Thank you !

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 )

















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

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

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) on 2010-04-01
Changed in language-selector (Ubuntu):
milestone: ubuntu-10.04-beta-2 → ubuntu-10.04
Arne Goetje (arnegoetje) on 2010-04-28
Changed in language-selector (Ubuntu):
milestone: ubuntu-10.04 → later
status: In Progress → Triaged
Rolf Leggewie (r0lf) on 2010-05-06
Changed in ubuntu-jp-improvement:
status: New → Confirmed
Arne Goetje (arnegoetje) on 2010-05-27
Changed in language-selector (Ubuntu):
milestone: later → maverick-alpha-3
Changed in poppler (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
Arne Goetje (arnegoetje) on 2010-07-22
Changed in poppler (Ubuntu):
status: Triaged → Invalid
Arne Goetje (arnegoetje) on 2010-07-22
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) on 2010-09-06
Changed in language-selector (Ubuntu):
assignee: Arne Goetje (arnegoetje) → nobody
status: In Progress → Triaged
Changed in poppler:
importance: Unknown → Medium
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

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

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) on 2011-02-06
Changed in ubuntu-translations:
importance: Undecided → High
status: New → Triaged
Changed in poppler:
importance: Unknown → Medium
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.

quequotion (quequotion) wrote :

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

Changed in poppler (Ubuntu):
status: Invalid → New
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,
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

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

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)

Download full text (3.1 KiB)

>>> www.pharmacyprescriptionweb.com.ua

- There is no reason to feel depressed if you, like so many other men today, have hit the rough spot of your sexual life when you cannot seem to be performing as well as you used to do. Your agitation and frustration are easily understood, and still you should know that with the modern development of worldwide pharmacological industries it is but natural that there is bound to be a solution for your own needs when it comes down to solving your erectile dysfunction problems.

- We suggest you getting erectile dysfunction drugs from our online drugstore cheaply, easily and without much to-do. You will always be taken care of and attended to with extreme care, and you will have the possibility of choosing from a wide range of erectile dysfunction products to find a solution that will best suit your particular needs.

- The whole world puts great trust in those famous diamond shaped pills, and if you are not an exception we would like to revise some basic points that speak in favor of putting your male health in the hands of those magical tablets.
Firstly, there is no need for regular therapy – those blue pills have to be taken directly before the planned sexual contact, and extra convenience shines through when you come to realize that the pills will not start working unless sufficient sexual stimulation is provided.

- Secondly, this erectile dysfunction solution is known for its extremely low adverse side effects profile, which makes it available for all age groups of patients. Besides, it really does not matter how old you are when it goes about taking erectile dysfunction pills – just make sure that you do not overdose, and they will work for you at their best!

- Finally, those fabulous pills do not only provide you with stable erection that can be maintained for as long as you need it – they also help you to achieve unheard sensitivity during the sexual act as well as make your genitals look much more sizey!

- Think of all those benefits of taking erectile dysfunction pills and the effect you can produce on your loved one – and do not hesitate to make your order and / or refills right away!

--- > www.pharmacyprescriptionweb.com.ua < ---


   If you want to bang her tonight
 without problems with making your tool stiff, without lack of stamina and with lots of her hot moans. Try it. Just pop one pilule, bought in our web-store and experience super boost tonight!
 - - -
--------- www.pharmacyprescriptionweb.com.ua
 - - -


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

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.

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.

Oscar Blanco (orblancog-b) wrote :

I had to install:

ttf-umefont ttf-mona

and do:

$ sudo fontconfig-voodoo -f -s ja_JP

output is not excellent, but characters are visible.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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