John Hudson wrote,
> >Uniscribe is a windows application and Microsoft tests it. Both
> >Microsoft and Apple provide tools to font developers which validate
> >fonts. TTF/OTF fonts have a rigid structure, if a font passes either
> >Microsoft's or Apple's font validators yet a system crashes, it's the
> >system that's got the problem.
> To be fair to the poor system engineers, the current font validation tools
> from MS and Apple are not exhaustive in their testing and also include
> suppositions based on pre-OT manufacturing practicesd. Microsoft are
> developing new validation tools.
That's good news. Improved validation tools will be most welcome.
Meanwhile, for developers using Windows platforms, the old
TTFDUMP.EXE file is still quite helpful in finding some kinds
of errors, even though it is confused by some of the new
table formats, especially some nuances of OpenType tables.
The FLINT program, which validates font hinting instructions,
also goes through each glyph in the font attempting to display
the glyph at various sizes. This can be helpful not only for
detecting problems with the hinting instructions, but also
for spotting any data corruption in the glyph outline data.
Microsoft's font signing tool, MSSIPOTF.DLL, validates a great
deal of information in the font, including but not limited to
checksums and table lengths.
These three tools used in combination are very useful to font
developers who are trying to make sure that their products
conform to the font specifications.
John Hudson knows about all of the above and is quite right
that there is room for improvement in the font validation
David Starner replied to John Hudson's letter:
>>To be fair to the poor system engineers,
> To be honest to the system engineers, dealing with foreign data
> without compromising system integrity is one of the basic
> principles of system engineering. Crashes on fonts really
> shouldn't be acceptable.
My sentiments exactly. Font developers need to test their products,
of course, but if a system crashes because of a bad instruction in a font,
it's generally the system's fault.
If an application tells the computer to divide one by zero and the
computer gets its silly little head twisted into never-never-land
because it tries to compute the answer... Well, if Person A tells
Person B to go jump in a lake, is it Person A's fault when Person B
Windows font installer does make some kind of check on fonts as they
are being installed now, and a particularly bad font won't even be
offered as a choice for installation.
Bad fonts do exist and they exist for various reasons, including
carelessness and/or ignorance on the part of the font developer.
Other reasons that bad fonts exist is because many older font
editing software packages had internal errors, or their authors
misunderstood the font specs, or the font specs changed since
the software was released. This kind of thing is pretty much
beyond the ability of many font developers to detect and correct.
Those of us who try to build fonts according to specs do whatever
we can to verify the integrity of our products. It's a maxim that
type designers are underpaid, though. (If you don't believe this,
just ask anyone on the OpenType list <smile>.) So, we often don't
own set-ups with all the different platforms and versions needed
to fully test products. In addition to existing validators, we rely
heavily on users for feedback and bug reports.
This archive was generated by hypermail 2.1.2 : Thu Jul 18 2002 - 23:43:38 EDT