Bug 15301

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.

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.

Created attachment 16319 [details]
xpdf, chinese font display very well

here is xpdf screenshot, chinese font display very well

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.

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

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.

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.

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. 

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:

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

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

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

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

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.

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