10000 [CFF2] Unhandled exception · Issue #1474 · fonttools/fonttools · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
8000

[CFF2] Unhandled exception #1474

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
miguelsousa opened this issue Jan 29, 2019 · 5 comments
Closed

[CFF2] Unhandled exception #1474

miguelsousa opened this issue Jan 29, 2019 · 5 comments
Assignees
@readroberts

Comments

@miguelsousa
Copy link
Collaborator

cff2_vf.otf.zip

$ ttx -t CFF2 cff2_vf.otf 
Dumping "cff2_vf.otf" to "cff2_vf.ttx"...
Dumping 'CFF2' table...
ERROR: Error in charstring 3
ERROR: Unhandled exception has occurred
Traceback (most recent call last):
  File "fontTools/ttx.py", line 398, in main
    process(jobs, options)
  File "fontTools/ttx.py", line 372, in process
    action(input, output, options)
  File "fontTools/misc/loggingTools.py", line 375, in wrapper
    return func(*args, **kwds)
  File "fontTools/ttx.py", line 269, in ttDump
    newlinestr=options.newlinestr)
  File "fontTools/ttLib/ttFont.py", line 228, in saveXML
    self._saveXML(writer, **kwargs)
  File "fontTools/ttLib/ttFont.py", line 283, in _saveXML
    self._tableToXML(tableWriter, tag, splitGlyphs=splitGlyphs)
  File "fontTools/ttLib/ttFont.py", line 314, in _tableToXML
    table.toXML(writer, self)
  File "fontTools/ttLib/tables/C_F_F_.py", line 42, in toXML
    self.cff.toXML(writer)
  File "fontTools/cffLib/__init__.py", line 156, in toXML
    font.toXML(xmlWriter)
  File "fontTools/cffLib/__init__.py", line 2322, in toXML
    self.decompileAllCharStrings()
  File "fontTools/cffLib/__init__.py", line 2336, in decompileAllCharStrings
    charString.decompile()
  File "fontTools/misc/psCharStrings.py", line 966, in decompile
    decompiler.execute(self)
  File "fontTools/misc/psCharStrings.py", line 292, in execute
    token, isOperator, index = charString.getToken(index)
  File "fontTools/misc/psCharStrings.py", line 1040, in getToken
    token, index = handler(self, b0, self.bytecode, index)
  File "fontTools/misc/psCharStrings.py", line 37, in read_smallInt2
    b1 = byteord(data[index])
IndexError: string index out of range
@justvanrossum
Copy link
Collaborator
justvanrossum commented Jan 29, 2019 •
edited
Loading

See #1451 and #1456. Could it be that that font was compiled with a version of fonttools before those bugs were fixed? The font is corrupt in exactly the same way as what the bug fixed in #1456 could have caused.

@readroberts
Copy link
Collaborator

I think this is something new: I get the same stack dump with that head of the fonttools master branch, which has the aforementioned fixes. Will look at this.

@readroberts
Copy link
Collaborator

I see that gid 3 is a bad charstring: it ends with a byte that it supposed to be the first byte of a two byte charstring. psCharstrings.py tries to get the second byte, and there isn't one -> IndexError. This immediately follows a hintmask, which is odd - not a lot of reason to change hintmasks at the end of a charstring. I also see that this font was made in July 2018, when any hinting was in very early days. Even though this is a bad charstring, I vote for protecting psCharstrings against this. The function getToken() already returns None for a value if there aren't enough bytes to to get the first byte, but is missing the check for the case where it needs to access a second byte.

@readroberts
Copy link
Collaborator

Now that I have fixed the font ( which is a test font in the afdko), I argue against protecting psCharstrings against this error. The test font had some garbage data added to the end of the charstring because of bugs in July 2018 in merging charstring hint data. However, in general, you get this problem only when you have a malformed charstring, with some data truncated from the end of the charstring, and it would be bad to silently truncate the charstring at the start of the bad data. I think that "ERROR: Error in charstring X' is more appropriate. This should also be a very rare error.

@miguelsousa
Copy link
Collaborator Author

Bad charstring. Closing.

@miguelsousa miguelsousa mentioned this issue Aug 12, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@readroberts readroberts

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@miguelsousa @readroberts @justvanrossum
0