View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000200 | luatex | luatex bug | public | 2009-03-27 13:53 | 2010-03-16 21:00 |
| Reporter | Taco | Assigned To | hhenkel | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Target Version | 0.60.0 | Fixed in Version | 0.52.0 | ||
| Summary | 0000200: Problem with CFF fonts having em-size other than 1000 | ||||
| Description | From Khaled: OpenType Postscript fonts having em-size other than 1000 don't show correctly with adobe reader (I tested version 8), see the attached test suit. Other viewers as Xpdf and libpoppler or muPDF based one show them correctly, but ghostscript don't show any text at all. This also happens with XeTeX (xdvipdfmx) and is suggested to be related to the way CFF fonts are embeded[1][2]. I'm not sure if this is really a bug, such fonts seem to be problematic and only adobe products seem to generate correct PDFs of them. Regards, Khaled [1]http://www.tug.org/pipermail/xetex/2009-February/012149.html [2]http://dev.typophile.com/node/46451 (especially the last post) (with attached test.tar.gz) | ||||
| Additional Information | From ChoF: I checked your test.pdf in Adobe Reader 9, and realized what the problem is. But the PDF file was generated by LuaTeX. So I tested the attached font with tex as follows: 1. mytest.tex: \special{pdf:mapline upm2048cff upm2048cff <upm2048cff.otf <ascii.enc} \font\test=upm2048cff \test\input tufte\par \bye 2. upm2048cff.tfm: Just copied ptmr7t.tfm 3. ascii.enc: Copied 7t.enc and changed entries from 0x00 to 0x1f to /.notdef. 4. mytest.dvi: Just run 'tex mytest' 5. mytest.pdf: Just run 'dvipdfmx mytest'. The font handling code of dvipdfmx is the same as xdvipdfmx. But the pdf result "mytest.pdf" can be seen in Adobe Reader 9, even though the character spacing is weird. (with attached mytest.zip) | ||||
| Tags | No tags attached. | ||||
|
2009-03-27 13:53
|
|
|
2009-03-27 14:08
|
|
|
|
Moved to a later target release. LuaTeX could actually do this by actively scaling the font (and keeping it Type0) |
|
|
The last note from ChoF: On Mar 29, 2009, at 2:57 AM, Khaled Hosny wrote: > On Sat, Mar 28, 2009 at 05:06:46PM +0900, Jin-Hwan Cho wrote: >> 1. XeTeX may read upm2048cff.otf directly and xdvipdfmx write in the >> CIDFontType0C >> format. In this case, I could see the around two times bigger font. >> >> 2. I used TeX in the last sample, and generated PDF with dvipdfmx. In >> this case the font >> is written in the Type1C format. In this case, I could see the right >> sized font. > > Not sure if this is useful, but Adobe's InDesign seems to write the > fonts in Type1C format (at least this what "pdffonts" say). Attached a > PDF generated by InDesign, if it is of any help. Surely as I expected. Because the font was written in the Type1C format, we have no problem in viewing the contents with Adobe Reader 9 and Leopard's Preview. Then there is only one way, that is, not to use the CIDFontType0C format. But how can we avoid this format in the case of non-latin fonts? I think that because of this reason, Jonathan didn't do anything even though he already knew this problem very well. Best regards, ChoF. |
|
|
A potential approach to this issue is to run a check as soon as the lua table is passed back into luatex. Then, if it is such a font with CFF glyphs and a non-1000 upm, split it into a virtual font with X segments of 256 entries, each with its own private 8-bit encoding. Those segments are then to be handled as 'normal' Type1C fonts. |
|
|
this is another example: http://www.theleagueofmoveabletype.com/ the goudy font ... - put it in the tree - run luatools --generate \starttext \font\test=oflgoudystm at 12pt \ruledhbox{\test test} \ruledhbox{test} \stoptext |
|
|
Here is another example: use fontforge Executable based on sources from 17:32 GMT 14-Sep-2009-ML. and make a pdf with FellType font FeDPrm27C.otf pr-IM_FELL_Double_Pica_PRO_Roman.pdf: fontforge Fonts name type emb sub uni object ID ------------------------------------ ----------------- --- --- --- --------- Times-Bold Type 1 no no no 45 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 5 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 8 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 11 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 14 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 17 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 20 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 23 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 26 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 29 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 32 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 35 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 38 0 The font has em size : 2048 , no problem with acroread 9 |
|
|
I just noticed some bugs with what it writes, but the python backend of my ant-variant at http://code.google.com/p/kompostilo/source/browse/trunk/python/kt/pdf.py has never given me any trouble with unconventional em-size settings. * One thing that may be pertinent is that I am writing the /W array in font units, and maybe luatex is using em/1000 units. I do use em/1000 units for the bounding box (which I am computing from the subsetted rather than full font, to sharpen the Select tool in Adobe Reader); at that level probably it is supposed to be em/1000 units in all the fields. * It also may matter that I am using fontforge to convert the font to CID-keyed CFF format, rather than try to figure out how to make the font myself. When I have tried using fontforge to extract fonts from luatex-made PDFs, the ones with unusual em-sizes have come out distorted, with ridiculously large em-sizes; at first I thought I was looking at empty glyph slots, but actually it was because the glyphs were orders of magnitude too small to see in fontforge's font view. When I extract fonts from PDFs that I produced or that fontforge itself produced, they come out as expected. Fontforge doesn't use CID-keying for its embedding, so for an example with CID-keying there is this pdf made with my software: http://home.comcast.net/~crudfactory/test2.kt.pdf Take into account that some of the fields in the FontDescriptor are buggy, though the FontBBox seems good. |
|
|
I think I fixed the abovementioned bugs in my code and so have replaced the test2.kt.pdf as well. |
|
|
Moved to an even later target, sorry, no time |
|
|
I tried by manually editing a pdf document: multiplying all the upm-derived values in the fontdescriptor by 2.048 while dividing the the Tm scale by 1/2.048 seems to do the trick. |
|
|
Hartmut fixed this, in rev 3488. As of this revision, there is a special correction to the embedded cff and the font scale if the font to be output has opentype_format and the units_per_em differs from zero. Note: <tfmtable>.units_per_em has to be passed back to luatex from the lua font loading code for this to work. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-03-27 13:53 | Taco | New Issue | |
| 2009-03-27 13:53 | Taco | Status | new => assigned |
| 2009-03-27 13:53 | Taco | Assigned To | => Taco |
| 2009-03-27 13:53 | Taco | File Added: test.tar.gz | |
| 2009-03-27 14:08 | Taco | File Added: mytest.zip | |
| 2009-04-06 11:15 | Taco | Note Added: 0000135 | |
| 2009-04-06 11:15 | Taco | Target Version | 0.40.0 => 0.50.0 |
| 2009-05-07 10:48 | Taco | Note Added: 0000202 | |
| 2009-08-01 14:11 | Taco | Note Added: 0000251 | |
| 2009-09-17 09:50 | Hans Hagen | Note Added: 0000262 | |
| 2009-09-20 03:29 | luigi scarso | Note Added: 0000263 | |
| 2009-09-20 07:42 | bschwartz | Note Added: 0000264 | |
| 2009-09-20 11:02 | bschwartz | Note Added: 0000265 | |
| 2009-12-02 14:22 | Taco | Note Added: 0000366 | |
| 2009-12-02 14:22 | Taco | Target Version | 0.50.0 => 0.60.0 |
| 2010-03-13 08:03 | Taco | Note Added: 0000476 | |
| 2010-03-13 18:32 | Taco | Note Added: 0000483 | |
| 2010-03-13 18:32 | Taco | Status | assigned => resolved |
| 2010-03-13 18:32 | Taco | Resolution | open => fixed |
| 2010-03-13 18:32 | Taco | Assigned To | Taco => hhenkel |
| 2010-03-16 20:59 | Taco | Fixed in Version | => 0.52.0 |
| 2010-03-16 21:00 | Taco | Status | resolved => closed |
