Subsetting causes IndexOutOfBoundsException

[randomrand...@yahoo.com.au]

Hi,
I was testing out using the sfnttool to subset a font, and I came across this error:

Exception in thread "main" java.lang.IndexOutOfBoundsException: Index attempted
to be read from is out of bounds: 100f5
        at com.google.typography.font.sfntly.data.ReadableFontData.readUByte(Unknown Source)
        at com.google.typography.font.sfntly.data.ReadableFontData.readUShort(Unknown Source)
        at com.google.typography.font.sfntly.table.core.CMapFormat4.retrieveGlyphId(Unknown Source)
        at com.google.typography.font.sfntly.table.core.CMapFormat4.glyphId(Unknown Source)
        at com.google.typography.font.tools.subsetter.RenumberingCMapTableSubsetter.computeMapping(Unknown Source)
        at com.google.typography.font.tools.subsetter.RenumberingCMapTableSubsetter.subset(Unknown Source)
        at com.google.typography.font.tools.subsetter.Subsetter.subset(Unknown Source)
        at com.google.typography.font.tools.sfnttool.SfntTool.subsetFontFile(Unknown Source)
        at com.google.typography.font.tools.sfnttool.SfntTool.main(Unknown Source)

 
I was wondering what could be causing this error? I have attached the font involved.

Cheers

[Stuart Gill]

Hi,

Thanks for submitting this. I haven't had a chance to debug this yet but from looking briefly at this I wonder if the font doesn't have a malformed CMap table. I'll try to look at it next week.

Could you tell me what where the command line parameters you were using?

Thanks,

Stuart

[Raph Levien]

Yes, the font is invalid:

Segment=28 unicode-start=ffff end=ffff range-offset=65535 delta=1 End

This is a "range-offset" value that points well beyond the end of the cmap. A lot of consumers of this font might ignore such a flaw. OpenType Sanitizer also complains (although strangely this seems to be a warning rather than an error):

WARNING at /home/raph/ots-read-only/src/ots.cc:216: bad search range

WARNING at /home/raph/ots-read-only/src/ots.cc:231: bad range shift

WARNING at /home/raph/ots-read-only/src/cmap.cc:160: bad id_range_offset

WARNING at /home/raph/ots-read-only/src/cmap.cc:160: bad id_range_offset

WARNING at /home/raph/ots-read-only/src/hdmx.cc:29: the table should not be present when bit 2 and 4 of the head->flags are not set

WARNING at /home/raph/ots-read-only/src/kern.cc:108: bad search range

WARNING at /home/raph/ots-read-only/src/kern.cc:117: bad range shift

Hope this helps,

Raph

[Raph Levien]

The font is invalid but according to the OTS source code it's a common problem. In production in Chrome, it will silently zero out the offending value in this particular case.

Here's the relevant code, from src/cmap.cc:

    if (ranges[i].id_range_offset & 1) {

      // Some font generators seem to put 65535 on id_range_offset

      // for 0xFFFF-0xFFFF range.

      // (e.g., many fonts in http://www.princexml.com/fonts/)

      if (i == segcount - 1u) {

        OTS_WARNING("bad id_range_offset");

        ranges[i].id_range_offset = 0;

        // The id_range_offset value in the transcoded font will not change

        // since this table is not actually "transcoded" yet.

      } else {

...

Depending on how far down this road you want to go, it might make sense to add special-case code to handle this case.

Raph

[randomrand...@yahoo.com.au]

Ah, that makes sense now - thanks. I saw it happen with a few fonts - I'm surprised that it's quite common for them to share this issue.

[Stuart Gill]

If you see the same error in a few fonts then it's likely that there's a tool somewhere that's doing this. Now, whether it's doing it because the tool developer made a mistake or because the tool developer was working around a bug in a font using program/OS (that may have been fixed a decade or more ago) is hard to tell without some archaeological work.

I'll file this as an issue in the bug tracker and later I'll have a look and see what I can do to mitigate it.

Stuart

[Brian Stell]

As Billy Wilder, Andrew W. Mellon, and Oscar Wilde are reported to have said: "No good deed goes unpunished"

We should probably make the default behavior fail and require a flag to ignore normal 'safety' settings.