Problematic sanity check in OpenTypeFileInput.cpp OpenTypeFileInput::ReadOpenTypeSFNTFromDfont() leads to problems embedding .dfont fonts on El Capitan about pdf-writer HOT 4 CLOSED

Makes sense.
sounds like the major part of testing here is to figure out they really got a mac resource file.
can this be taken care of without these tests?

Gal.

from pdf-writer.

A resource-based font packaged in resources in the data fork (as opposed to the traditional resource fork of classic Mac font suitcases) will always have the filename extension ".dfont". For fonts, we can assume that if the filename ends with ".dfont", and the header values at the beginning of the file look sane (according to documentation and common sense), and the parsed resource map has entries for the 'sfnt' resource(s) we're looking for, and the metadata (offset, length, etc.) for those resources look sane, then we can load the 'sfnt' container(s) from those resources.

from pdf-writer.

Sounds good. i reckon if i can get to sfnt that should be fine, so just be careful with reading etc. comment out and be careful with reading.

k.
I'll try to get to this soon.
i welcome pull requests :) too.

Gal.

from pdf-writer.

checked in commit which has a safe read of the font file, while avoiding the problematic tests

from pdf-writer.