[tex-live] LuaTeX crashes when loading some of URW fonts

[Taco Hoekwater]

On 07/12/2010 04:10 PM, Khaled Hosny wrote:
> LuaTeX crashes when attempting to load any of the following three fonts:
> GaramondNo8-Ita.ttf
> LetterGothic-BolIta.ttf
> NimbusRomNo9L-MediItal.ttf

I can't reproduce those exact crashes with the texlive binary
(x64_64-linux). However, in my case the texlive binary crashes on
A030-Bol.ttf and URWGothicL-BookObli.ttf, and a self-compiled
binary crashed on NimbusRomNo9L-Regu.ttf.

Even though the crashes are somewhat random, I do think I have
found what is causing them. Ttx output shows the following:

[taco at boo urwfonts-1.41]$ grep bXHeight *.ttx | grep -v \"0\"
A028-Med.ttx:      <bXHeight value="6"/>
A030-Bol.ttx:      <bXHeight value="164"/>
AntiqueOlive-Ita.ttx:      <bXHeight value="24"/>
CenturySchL-BoldItal.ttx:      <bXHeight value="198"/>
Dingbats.ttx:      <bXHeight value="1"/>
GaramondNo8-Ita.ttx:      <bXHeight value="125"/>
GaramondNo8-MedIta.ttx:      <bXHeight value="9"/>
LetterGothic-BolIta.ttx:      <bXHeight value="71"/>
Mauritius-Reg.ttx:      <bXHeight value="11"/>
NimbusMonL-BoldObli.ttx:      <bXHeight value="5"/>
NimbusMono-Reg.ttx:      <bXHeight value="2"/>
NimbusRomanNo9-MedIta.ttx:      <bXHeight value="162"/>
NimbusRomNo9L-MediItal.ttx:      <bXHeight value="40"/>
NimbusRomNo9L-Regu.ttx:      <bXHeight value="133"/>
NimbusSanL-BoldItal.ttx:      <bXHeight value="4"/>
StandardSymL.ttx:      <bXHeight value="7"/>
U001Con-BolIta.ttx:      <bXHeight value="6"/>
U001-Ita.ttx:      <bXHeight value="1"/>
U001-Reg.ttx:      <bXHeight value="24"/>
URWBookmanL-LighItal.ttx:      <bXHeight value="31"/>
URWClassico-Ita.ttx:      <bXHeight value="8"/>
URWClassico-Reg.ttx:      <bXHeight value="2"/>
URWGothicL-BookObli.ttx:      <bXHeight value="194"/>
URWPalladioL-BoldItal.ttx:      <bXHeight value="15"/>

The panose bXheight parameter is supposed to be between 0 and 7, and
luatex is actually counting on that to convert the number into a string.
This failure to accept rubbish input is a bug that I will commit a
crude fix for in a moment, but nevertheless, this font set is broken as
well: it appears there is a random value in the bXHeight fields of a
lot of the fonts (only StandardSymL makes any sense).

Best wishes,
Taco