Evince couldnot display chinese pdf files

[wlx]

upgrade from gutsy to hardy, does not get the problem in gutsy.

The pdf file that include chinese could not display, just echoed as some squares, but some of them displayed correctly.
I have installed poppler-data and xpdf-chinese-simplified packages, and xpdf and adobe reader can display the pdf file without any problem.

[Pedro Villavicencio (pedro)]

This bug has been filed here:

https://bugs.edge.launchpad.net/ubuntu/+source/poppler/+bug/209145

"The pdf file that include chinese could not display, just echoed as some squares, but some of them displayed correctly.
I have installed poppler-data and xpdf-chinese-simplified packages, and xpdf and adobe reader can display the pdf file without any problem."

http://launchpadlibrarian.net/13020571/chinese.pdf

Thanks,

[Albert Astals Cid (aacid)]

Works for me using poppler 0.8 and poppler-data 0.2 if you upgrade to this versions and still fails for you please reopen.

[Pedro Villavicencio (pedro)]

re submitted the pdf

[Pedro Villavicencio (pedro)]

Thanks for your bug report. This bug has been reported to the developers of the software. You can track it and make comments here: http://bugs.freedesktop.org/show_bug.cgi?id=15301

[Pedro Villavicencio (pedro)]

comment from upstream

"Works for me using poppler 0.8 and poppler-data 0.2 if you upgrade to this
versions and still fails for you please reopen.
"
setting this as fix committed, thanks.

[Yuren Ju (yurenju)]

Created an attachment (id=16318)
evince with poppler 0.8.2 and poppler-data 0.2

it's still buggy, evince with poppler 0.8.2, poppler-data 0.2 also has broken chinese font, see attachment.

[Yuren Ju (yurenju)]

Created an attachment (id=16319)
xpdf, chinese font display very well

here is xpdf screenshot, chinese font display very well

[Yuren Ju (yurenju)]

Created an attachment (id=16320)
test sample pdf file

here is a test sample pdf file, xpdf can display chinese correct, but evince with poppler 0.8.2 and poppler-data 0.2 can't.

[Albert Astals Cid (aacid)]

Right, there is a problem when using the cairo backend. Splash backend works fine.

[alienheartbeat (reckless-symmetry)]

Same problem with kpdf 0.5.9 / poppler 0.6.4
in mixed pdfs. displays the english fine, but displays garbage for the chinese.
System is a clean install of Kubuntu 8.04

xpdf works fine.

kpdf 0.5.6 / poppler 0.5.4 on Kubuntu 7.04 worked fine.

Am filing here as I assume the problem is also poppler, and so should not open a separate bug report.
If I should open a separate bug report, let me know.
If you want screenshots, let me know.
If you want tea and biscuits, let me know.

Have not tried poppler 0.8 - am not sure how.
Not confident I know how.

[alienheartbeat (reckless-symmetry)]

I have to eat my words and withdraw the comment above.

After re-reading Pedro Villavicencio comments above,
I re-checked what was installed and compared the 7.04 and 8.04 systems,
and discovered poppler-data was not on the 8.04 system.
So I installed it, and as if by miracle, Chinese appeared.

I should note that there was no poppler-data on the 7.04 system - and the Chinese worked.

I should also note that how a humble user would know he/she must install poppler-data to read Chinese remains unresolved.
Lucky there is launchpad to find this stuff out!

[Mozbugbox (mozbugbox)]

I believe this problem is caused by the PMingLiU font embedded in the particular pdf file. PMingLiU is famous on abuse truetype hint and cause freetype some trouble.

Freetype has to do some hacky magic to handle the specific font. Apparently, when the font is embedded/subset in a pdf file, freetype fail to detect PMingLiU and hence render the font in a broken way.

see: http://osdir.com/ml/fonts.freetype.devel/2006-11/msg00021.html

either freetype need to be fixed with partial PMingLiU detection or poppler need to substitute the PMingLiU with another font.

[Mozbugbox (mozbugbox)]

Freetype detects PMingLiU by family name (truetype/ttobjs.c: tt_face_init(), ) apparently, when writing an embedded TTF, poppler did not save the family name.

[Sebastien Bacher (seb128)]

the new version is available in ubuntu now

[Mozbugbox (mozbugbox)]

Look deeper into the problem, it seems that the PMingLiU is correctly identified by freetype.

However, in fofi/FoFiTrueType.cc, hinting information are not saved when writing TTF files. Since PMingLiU requires hinting programs in order to be rendered properly, poppler displays the PMingLiU font badly with the hinting.

Poppler should save the hinting related truetype tables: fpgm, cvt, prep as described in the OpenType specification when writing TTF fonts.

[wlx (wangliangxu)]

Same problem in intrepid beta.
poppler-data have installed.

[wlx (wangliangxu)]

xpdf can display the chinese, but evince could not.

[Alan Tam (at)]

I can read the chinese after installing poppler-data in my intrepid install (contrary to earlier reports).

Even though it works, I am dissatisfied with this "solution", especially since the name "poppler-data" is not meaningful enough. In fact, most other "X-data" packages are direct/indirect dependency from the "X" package. This induces us not to think the action "installing poppler-data will solve a problem in the poppler package".

It would be much better if it is called poppler-pdf-international-extra.

[wlx (wangliangxu)]

could not see chinese with evince use the attach pdf file on ubuntu intrepid I uploaded before.

http://launchpadlibrarian.net/13020571/chinese.pdf

[Adamson H (adamson)]

http://launchpadlibrarian.net/13020571/chinese.pdf is displayed correctly with poppler-data installed. However, this pdf file
http://launchpadlibrarian.net/19751825/dell440.pdf with embedded Chinese Fonts cannot be properly displayed.

[Pedro Villavicencio (pedro)]

could you send it upstream since you know what doesn't display correct? i've no idea about chinese characters sorry.

[wlx (wangliangxu)]

Yes, it is working now, great.

[wlx (wangliangxu)]

http://launchpadlibrarian.net/13020571/chinese.pdf
http://launchpadlibrarian.net/19751825/dell440.pdf
Both of them are displayed correctly now.

[Pedro Villavicencio (pedro)]

great, thanks for the confirmation.

[Alan Tam (at)]

I am not sure why wlx can display both correctly.
I think the difference that one works and one doesn't is exactly equivalent to the upstream bug. <https://bugs.freedesktop.org/show_bug.cgi?id=15301>

Even a person who doesn't know Chinese is likely to tell the difference.
* <http://bugs.freedesktop.org/attachment.cgi?id=16318>
* <http://bugs.freedesktop.org/attachment.cgi?id=16319>

I noticed more people experiencing the same problem.
* <http://linuxdesktop.cn/2007/11/27/xpdf.html>
* <http://www.linuxsir.org/bbs/thread259224.html>

Comment 8 in the link has probably a correct diagnosis of the problem, pending to be fixed by upstream.
Using xpdf instead or recompiling poppler with splash backend seems to be workarounds.

[Adamson H (adamson)]

dell440.pdf does not display correctly in Document Viewer; please take a look at the attached screen captured file.

[Adamson H (adamson)]

However, dell440.pdf looks okay in Foxit Reader under Windows XP. Please look at the attached jpeg file.

[wlx (wangliangxu)]

Yes, evince could display chinese fonts in the both two pdf files, and could not display chinese normally in the second pdf file, but it seems it is a font problem (not sure), so maybe it is another bug?

[feixiaoguang (morpheus-xiao)]

Thanks for your kindly support.
I want to setup the LINUX system from the hard disk (since I have a windows XP already ,and I have the iso file of the LINUX in my hard disk, and I don't have the LINUX Compress Disk).
Any suggestion? thank you.

-----邮件原件-----
发件人: <email address hidden> [mailto:<email address hidden>] 代表 wlx
发送时间: 2008年11月21日 0:51
收件人: <email address hidden>
主题: [Bug 209145] Re: Evince couldnot display chinese pdf files

Yes, evince could display chinese fonts in the both two pdf files, and
could not display chinese normally in the second pdf file, but it seems
it is a font problem (not sure), so maybe it is another bug?

--
Evince couldnot display chinese pdf files
https://bugs.launchpad.net/bugs/209145
You received this bug notification because you are a direct subscriber
of a duplicate bug.

Status in Poppler: Confirmed
Status in “poppler” source package in Ubuntu: Fix Released

Bug description:
upgrade from gutsy to hardy, does not get the problem in gutsy.

The pdf file that include chinese could not display, just echoed as some squares, but some of them displayed correctly.
I have installed poppler-data and xpdf-chinese-simplified packages, and xpdf and adobe reader can display the pdf file without any problem.

__________ Information from ESET NOD32 Antivirus, version of virus signature database 3630 (20081121) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature database 3632 (20081121) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________________________________________________
�Ͽ���������������http://cn.mail.yahoo.com

[Mackenzie Morgan (maco.m)]

That's not related to this bug. Please ask in the Answers section of
Launchpad.

[Mozbugbox (mozbugbox)]

Created an attachment (id=20712)
Force HINTING for tricky fonts which require hinting.

The patch tries to do what the freetype2 did to tricky fonts which need hinting in order to render properly. See:

http://cvs.savannah.gnu.org/viewvc/freetype/freetype2/src/truetype/ttobjs.c?view=markup

[Alan Tam (at)]

The patch works for https://bugs.freedesktop.org/attachment.cgi?id=16320
but doesn't work for http://launchpadlibrarian.net/19751825/dell440.pdf

[Sam Lin (itrs-lin)]

(In reply to comment #10)
> The patch works for https://bugs.freedesktop.org/attachment.cgi?id=16320
> but doesn't work for http://launchpadlibrarian.net/19751825/dell440.pdf
>

because some embedded font doesn't carry faimily_name info in font face so the matching doesn't work.

mentioned here:
http://freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_FaceRec

I'm wondering if we can just use compromised selection to use FT_LOAD_NO_AUTOHINT to replace FT_LOAD_NO_HINTING. (this works for tricky fonts)

[Xiang (hsiang-liu)]

still not work in ubuntu 10.04

$ evince --version
GNOME Document Viewer 2.30.0

[Steven McCoy (dsbunny)]

Current workarounds for Lucid:

1) Google Chrome, minimum version 6.0.458 and enable the PDF plugin with "about:plugins".
2) Adobe Acrobat Reader 9.0 from Canonical partner repository.

Tested with documents from DahSingBank (attached)

[ddreamer (ddreamer)]

In ubuntu 10.04 with installation of poppler-data and xpdf-chinese-traditional, the Chinese characters are still broken in Evince 2.30.3 and in Okular 0.10.2. However, xpdf can show them correctly. It is evident with the file provided in #24 by Steven McCoy. This issue has seemed to last for years. Why can't it be fixed?

[ddreamer (ddreamer)]

I even replaced "<string>sans-serif</string>" at the fourth line from the bottom of /etc/fonts/conf.d/49-sansserif.conf with "<string>AR PL UKai TW</string>". But the problem persisted.

[ddreamer (ddreamer)]

Anybody sees this problem?

In my Ubuntu 10.04, the above-mentioned http://launchpadlibrarian.net/19751825/dell440.pdf still can't be displayed correctly with Evince and Okular, even after methods mentioned in #25 and #26.

[Mpsuzuki (mpsuzuki)]

Hi,
I'm quite sorry for making you irritated about this issue for a long time.

The latest FreeType2 is changed to enable the hinting for the nameless
TrueType fonts embedded in PS/PDF, so I guess the situation may be
improved if you upgrade FreeType2 to the latest revision on GIT
(after 2010-Aug-28, version 2.4.2 is insufficient). For the background
info, please find discussion in poppler mailing list:
http://lists.freedesktop.org/archives/poppler/2010-August/006303.html

[Sam Lin (itrs-lin)]

I tried the latest git of the freetype2 but it doesn't solve the issue.
I suspect the hinting enabled in freetype2 is forced disabled in cairo font engine.

[poloshiao (poloshiao)]

The following report is related to a pdf file which will appear broken chinese charachters while reading with Evince.
This pdf file was shown first at following URL on 14 Oct, 2010 by the author TuoXian:
http://linux400.dfes.tpc.edu.tw/lifetype/index.php?op=ViewArticle&articleId=45&blogId=1
I help translate it into English and post it here.
Our genuine wish is that the developer team of Evince may solve these problems and let those newbies
read the pdf documents with Evince showing normal chinese charachters without needing any patch.
This is the URL of the said PDF file: ftp://163.20.82.24/pub/other/98三年級課表.pdf which was a real timetable used in our school last year.
It was documented with word 2000 and then transformed into PDF through PDFcreator by our colleague.
It became a big trouble to popularize the ubuntu OS in school because it will appear broken chinese charachters with Evince because all teachers and executive authorities should refuse to use these kinds of PDF documents.
It is also a strange experience that we can read normally with okular under ubuntu 9.10 or before. We are eager to know the reason why it appears broken under okular then from 10.04 and on.
We upload the PDF file as a detached file timetable.pdf as follows.
It will be marvelous if you may solve this harassed problem so that everyone, including the newbies, can read the PDF documents easily with Evince.

[Yuan Chao (yuanchao)]

Let me add some supplements:
* bytecode interpreter (BCI) in FreeType (FT) used to have sw patent issue so disabled by default
* Now the patent is expired so enabled by default since FT 2.4 (http://www.freetype.org/patents.html)
* BCI is used for hinting (grid fitting) to display creep glyphs
* auto-hint/autofit is a walk-around to fine tune on rendering to have similar result to "native" hint (hint w/ BCI)
* Tricky fonts use BCI instructions to place (re-use) radical strokes to save space
  (instead of each time outlining the whole glyph)
* Tricky fonts are unfortunately widely used in official and educational documents for they are shipped w/ windows.
* autohint/autofit can't "invent" the position/scaling info for tricky fonts and results in "broken" glyphs.
   (sorry it's hard to tell if you don't understand chinese characters as all strokes are there, just in wrong position)
* autohint/autofit is exclusive to BCI hinting and must be disabled for tricky fonts.
* libpoppler needs to be compiled against "FT with BCI enabled" to be able to render tricky fonts correctly.
   (it's then a distro issue instead of individual packages)

[sgarwang (sgarwang)]

Hello Yuan,

Could you please try test above file and list your environment if possible?

It seems re-build libpoppler does not fix this issue.

Using Ubuntu 10.04 with the updated libfreetype (2.4.2), assuming BCI is enabled, with poppler-date updated too,
build poppler-0.16.4, you can still see this issue even use its demo program under poppler-/glib/demo/.

Rebuild epdfview and open this file the issue still exists too.

Thanks!

[sgarwang (sgarwang)]

Sorry for false alarm. The issue seems fixed after using libfreetype (2.4.4).
We confirmed both 2.4.2 and 2.4.4 all BCI enabled. Not sure how 2.4.4 fix it. Is this related with ASCII and BIG5?
Thanks!

[Rex Tsai (chihchun)]

libfreetype 2.4.4 has included the tt_check_trickyness patch. https://savannah.nongnu.org/bugs/?31645

[Rex Tsai (chihchun)]

This issue have a better solution in 2.4.6 - https://launchpad.net/bugs/844601.

[Gitlab-migration (gitlab-migration)]

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