View Issue Details

IDProjectCategoryView StatusLast Update
0000032luatexluatex bugpublic2008-06-24 11:53
ReporterTacoAssigned ToTaco 
PrioritylowSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version0.25.3 
Target Version0.30.0Fixed in Version0.27.0 
Summary0000032: CID font output of LuaTeX is too thin
DescriptionReported by Yue Wang:
As I mentioned a month ago, I think there is a problem in dvipdfmx
code which makes the CID embeded font in the output pdf too thin to
read.

Because LuaTeX/XeTeX(xdvipdfmx) all use dvipdfmx source code to deal
with the CID fonts embedding, So nowadays all the pdf file output by
TeX seems problematic.

Today I have some free time and make some sample pdf files for you.

I use the cairo and word2007 output for comparasion. All files are in
the attachment now.

It seems that the LuaTeX output is the thinnest of the three, as can
be seen from the jpg file.
Steps To ReproduceThe simsun.ttc comes from Windows XP, but the problem is generic.
TagsNo tags attached.

Activities

2008-05-05 14:10

 

samples.tar.gz (296,993 bytes)

2008-05-05 14:11

 

compare.JPG (283,546 bytes)

Taco

2008-05-08 11:27

administrator   ~0000017

This is taken care of by #1245. The following explanation is by ChoF:

> I tried to check the font description object for the embedded chinese font
> SimSun. After uncompressing with the utility "pdftk", I could notice that the
> three PDF files have different "StemV" value:
>
> cairo.pdf: /StemV 80
> luatex.pdf: /StemV 167
> word2007.pdf: /StemV 0
>
> I attached uncompressed "luatex.pdf". Try to change the StemV value in
> the 2758th line from 167 (Bold) to 80 (Regular; as cairo.pdf). Then you may
> get the same result as cairo.pdf (in Adobe Reader 8).
>
> Now, I am going to explain how DVIPDFMx choose the "StemV" value. In the case
> of CFF (PostScript) font, "StemV" is determined by "StdVW" value in the font file.
> Otherwise Regular(Normal) value 88 is used.
>
> Since there is no StdVW value in TrueType fonts, DVIPDFMx uses the following
> estimation (in tt_aux.c) using the values in the OS/2 table.
>
> stemv = (os2->usWeightClass/65)*(os2->usWeightClass/65)+50
--------

The actual cause was that luatex was still using the values from pdftex, and pdftex takes a third of the 'period' glyph a /StemV. But in CJK fonts, period is likely to be half of (or even a whole) em, much too wide!

Taco

2008-05-08 11:34

administrator   ~0000018

I'll set this to resolved. My patch is a hack, but the whole font backend needs cleanup and when we get around to doing that, this issue simply has to be taken into account as well.

Issue History

Date Modified Username Field Change
2008-05-05 14:10 Taco New Issue
2008-05-05 14:10 Taco Status new => assigned
2008-05-05 14:10 Taco Assigned To => Taco
2008-05-05 14:10 Taco File Added: samples.tar.gz
2008-05-05 14:11 Taco File Added: compare.JPG
2008-05-08 11:27 Taco Note Added: 0000017
2008-05-08 11:34 Taco Note Added: 0000018
2008-05-08 11:35 Taco Status assigned => resolved
2008-05-08 11:35 Taco Resolution open => fixed
2008-06-24 11:53 Taco Fixed in Version => 0.27.0
2008-06-24 11:53 Taco Status resolved => closed