Bug 15301 - Evince couldnot display chinese pdf files
Summary: Evince couldnot display chinese pdf files
Alias: None
Product: poppler
Classification: Unclassified
Component: cairo backend (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: poppler-bugs
QA Contact:
Depends on:
Reported: 2008-04-01 07:38 UTC by Pedro Villavicencio
Modified: 2018-08-21 10:37 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:

evince with poppler 0.8.2 and poppler-data 0.2 (72.77 KB, image/png)
2008-05-02 20:47 UTC, Yuren Ju
xpdf, chinese font display very well (59.60 KB, image/png)
2008-05-02 20:48 UTC, Yuren Ju
test sample pdf file (129.31 KB, application/pdf)
2008-05-02 20:50 UTC, Yuren Ju
Force HINTING for tricky fonts which require hinting. (1.41 KB, text/plain)
2008-12-01 01:28 UTC, Bug Fly

Description Pedro Villavicencio 2008-04-01 07:38:19 UTC
This bug has been filed here:


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


Comment 1 Albert Astals Cid 2008-04-01 11:04:39 UTC
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.
Comment 2 Yuren Ju 2008-05-02 20:47:06 UTC
Created attachment 16318 [details]
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.
Comment 3 Yuren Ju 2008-05-02 20:48:59 UTC
Created attachment 16319 [details]
xpdf, chinese font display very well

here is xpdf screenshot, chinese font display very well
Comment 4 Yuren Ju 2008-05-02 20:50:26 UTC
Created attachment 16320 [details]
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.
Comment 5 Albert Astals Cid 2008-05-04 04:35:02 UTC
Right, there is a problem when using the cairo backend. Splash backend works fine.
Comment 6 Bug Fly 2008-08-07 07:10:05 UTC
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.

Comment 7 Bug Fly 2008-08-07 19:26:02 UTC
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.
Comment 8 Bug Fly 2008-08-25 20:54:20 UTC
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. 
Comment 9 Bug Fly 2008-12-01 01:28:35 UTC
Created attachment 20712 [details]
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:

Comment 10 Alan Tam 2009-01-25 01:53:55 UTC
The patch works for https://bugs.freedesktop.org/attachment.cgi?id=16320
but doesn't work for http://launchpadlibrarian.net/19751825/dell440.pdf
Comment 11 Sam Lin 2010-02-23 00:49:48 UTC
(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:

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)

Comment 12 suzuki toshiya 2010-08-31 04:40:00 UTC
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:
Comment 13 Sam Lin 2010-09-12 05:44:28 UTC
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.
Comment 14 GitLab Migration User 2018-08-21 10:37:22 UTC
-- 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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.