View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000032 | luatex | luatex bug | public | 2008-05-05 14:10 | 2008-06-24 11:53 |
| Reporter | Taco | Assigned To | Taco | ||
| Priority | low | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.25.3 | ||||
| Target Version | 0.30.0 | Fixed in Version | 0.27.0 | ||
| Summary | 0000032: CID font output of LuaTeX is too thin | ||||
| Description | Reported 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 Reproduce | The simsun.ttc comes from Windows XP, but the problem is generic. | ||||
| Tags | No tags attached. | ||||
|
2008-05-05 14:10
|
|
|
2008-05-05 14:11
|
|
|
|
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! |
|
|
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. |
| 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 |
