Hi, So I finally understand how to use my system fonts with Context (the --reload thing was not working), in order to use URW fonts, especially Nimbus Roman ones (I know there are TexGyre versions but that's not the point). * Here is my code : % engine=luatex \starttypescript [serif] [nimbus] [name] \definefontsynonym [Serif] [n021003l] \definefontsynonym [SerifBold] [n021004l] \definefontsynonym [SerifItalic] [n021023l] \definefontsynonym [SerifBoldItalic] [n021024l] \stoptypescript \definetypeface[basic][rm][serif][nimbus] \setupbodyfont[basic,12pt] \starttext blah blah blah \stoptext * When I compile this with Context, I get the following error : !LuaTeX error (file /usr/local/tex/texmf/fonts/data/default/Type1/n021023l.pfb): Parsing CFF DICT failed. (error=-3) ==> Fatal error occurred, no output PDF file produced! MTXrun | fatal error, return code: 70 It happens with other italic URW fonts, such as Palladio. * Googling a bit the error message, I found a similar error message but with Xetex (http://www.tug.org/pipermail/xetex/2008-March/009000.html ):

...

OK, I think I have figured out what's wrong. The italic version of the font has an empty StemSnapV array in its PS Private data, and this stumbles xdvipdfmx which assumes every operator should be preceded by some operands. Particularly I think this is a bug in xdvipdfmx: although the specification doesn't say explicitly that dictionary keys with no value are allowed, other tools (e. g. TTX or FontForge) seem to have no problems with this situation.

So my opinion is that the CFF_ERROR_STACK_UNDERFLOW error should not be triggered at the line 305 of cff_dict.c, if stack_top is 0.

Thanks for your analysis of the issue. You are right, it is unclear from the CFF spec whether an operator like StemSnapV should be allowed with no operands; it doesn't really make any sense, but on the other hand it should be harmless.

* So I searched in the luatex code to find the culprit, source/texk/web2c/luatexdir/font/writecff.c, where you might include a similar hack as in xdvipdfmx (http://scripts.sil.org/svn-view/xdvipdfmx/TRUNK/src/cff_dict.c?view=markup ) Thanks