Skip to content
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.

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

Corrupted font file handling #337

Open
fpirsch opened this issue Mar 16, 2018 · 4 comments · May be fixed by #704 or #648
Open

Corrupted font file handling #337

fpirsch opened this issue Mar 16, 2018 · 4 comments · May be fixed by #704 or #648

Comments

@fpirsch
Copy link
Collaborator

fpirsch commented Mar 16, 2018

The more different tables we parse in opentype.js, the more we come across corrupted font files.
Most of them are still usable with other software, but opentype.js currently throws errors and stops parsing the font.
Shouldn't we try to skip (sub)tables containing errors ?
Should we report errors in some way ? Maybe just keeping a log of ignored tables ?
What do you think ? @fdb @Jolg42 @Pomax and others ?

@Pomax
Copy link
Contributor

Pomax commented Mar 19, 2018

I would do an inventory on what opentype.js flags as error-worthy that other engines don't. I like graceful failing, so having the parse operation return an object that, compared to now, also contains parse error information would be nice. A list of "this is what's wrong" with "and this is what we would like to see happen in that case" would be super valuable (not just for parsing purposes, but also to give to users so they know what to expect).

Some tables are critical to font operation, but not critical to font metadata extraction, so a parse option would probably be useful, allowing people to specify either nothing (parse normally, error when normal-font-use-breaking parse errors occur), or pass a value that indicates that even if the font is broken, the parse run should simply skip to the next datastructure (record, subtable, table, etc).

Typically what you want to do when you hit a corrupt font is stop, and get yourself a fresh, proper copy of that font. But there are no doubt edge cases where that is either not an option, not worth it, or the intent is to actually extract data from a (partially) corrupt font.

@Jolg42
Copy link
Member

Jolg42 commented Mar 29, 2018

Sorry for the delay!
Indeed it depends on your usage of the library but if OpenType.js could continue the parsing of the font even if one table has an error it would be great!
I guess the library could return an array of errors with the location (table / sub-table) and a description.

@minsikim
Copy link

minsikim commented Apr 26, 2018

Maybe recieving a special parameter in load() and loadSync() like this

opentype.loadSync( url[, loadOptions ] )
opentype.load( url [, loadOptions] , callback)
//ex) loadOptions = 'ignore-partial-error'

would be a good idea!
(it would be great for me, just a suggestion :-) )

@Connum
Copy link
Contributor

Connum commented Nov 23, 2023

I'm currently working on restructuring the error handling to make it possible to load incomplete/corrupted font files as well as Type1/CFF fonts (see #643). There will be different error levels and you'll be able to define which levels to log and when to throw, so by default only unrecoverable errors will throw. You can check out the work-in-progress branch here:
https://github.com/Connum/opentype.js/tree/WIP/validation-error-handling

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment