View Issue Details

IDProjectCategoryView StatusLast Update
0000200luatexluatex bugpublic2010-03-16 21:00
ReporterTaco Assigned Tohhenkel  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Target Version0.60.0Fixed in Version0.52.0 
Summary0000200: Problem with CFF fonts having em-size other than 1000
DescriptionFrom 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.


[2] (especially the last post)

(with attached test.tar.gz)
Additional InformationFrom 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}

\test\input tufte\par

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
TagsNo tags attached.


2009-03-27 13:53


test.tar.gz (20,793 bytes)

2009-03-27 14:08 (22,048 bytes)


2009-04-06 11:15

administrator   ~0000135

Moved to a later target release. LuaTeX could actually do this by actively scaling the font (and keeping it Type0)


2009-05-07 10:48

administrator   ~0000202

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.


2009-08-01 14:11

administrator   ~0000251

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.

Hans Hagen

2009-09-17 09:50

manager   ~0000262

this is another example:

the goudy font ...

- put it in the tree
- run luatools --generate


\font\test=oflgoudystm at 12pt

\ruledhbox{\test test}



luigi scarso

2009-09-20 03:29

developer   ~0000263

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

pr-IM_FELL_Double_Pica_PRO_Roman.pdf: fontforge
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


2009-09-20 07:42

reporter   ~0000264

I just noticed some bugs with what it writes, but the python backend of my ant-variant at 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:
Take into account that some of the fields in the FontDescriptor are buggy, though the FontBBox seems good.


2009-09-20 11:02

reporter   ~0000265

I think I fixed the abovementioned bugs in my code and so have replaced the test2.kt.pdf as well.


2009-12-02 14:22

administrator   ~0000366

Moved to an even later target, sorry, no time


2010-03-13 08:03

administrator   ~0000476

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.


2010-03-13 18:32

administrator   ~0000483

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.

Issue History

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