![](https://secure.gravatar.com/avatar/386a116d129cdc597f2bb6210bbaff7a.jpg?s=120&d=mm&r=g)
On Tue, Oct 23, 2018 at 11:58 AM Marcel Krüger
---- On Tue, 23 Oct 2018 11:21:33 +0200 luigi scarso < luigi.scarso@gmail.com> wrote ----
On Tue, Oct 23, 2018 at 10:53 AM Marcel Krüger
wrote: Hi, another bug in LuaTeX: If LuaTeX tries to calculate the size of a CFF
table where the second entry in the table is a real number,
`pack_real` is called with `work_buffer+i` for a small `i`. This causes aliasing issues because `work_buffer` writes into `work_buffer` using `sprintf`. So the output from `pack_real` modifies `work_buffer` before the digits are read completely, causing LuaTeX to complain about a "invalid character".
An example to reproduce the issue:
Run the following plainTeX document with the attached version of `LOGO10.otf` (the font was created by reordering the Private table entries and has an invalid checksum, but this is ignored by LuaTeX) hm, not sure about invalid checksum... can you try to fix it with ttx ? (be careful, change the name of the new otf ie CFFFont name etc) --luigi
I already tried, but tty always stores the BlueValues first. I originally triggered this when I had a font which had fractional BlueValues which are replaced by whole So fixing the checksum would need some other tool or manual calculation, but I do not think it is worth it: LuaTeX does not care (I regularly use auto-generated fonts with all checksums set to zero without problems) Also there are no checksums in the actual CFF part, only in the OTF wrapper which is mostly ignored anyway.
ok, I will check. My ttx looks ok \directlua{ font.current(font.define{ name='logo', embedding='subset', encodingbytes=2, format='opentype', filename='LOGO10a.otf', characters={ [0x41] = { width = 1000, height = 1000, depth = 1000, index = 0x2, } }, }) } A \bye -- luigi