Hin-Tak Leung

Book of Kells look very decent on android chrome - maybe the problem is windows or MSIE :-)

I am trying very hard not to engage in any specifics here - the basic "smoke test" of 6000 fonts: the rasterization part takes 9 hours; the glyf table test was about 9 or 10 days. Even just setting the tests going (and ignoring/not-reading the outcome) is a lot of time. I would not have any time to do any real work ( or even have a life) if I try to answer any question from any of the authors of even just the 6000 fonts I test things on.

So a few general points:

- the bundled CHM file is auto-generated from the actual error code status list; it is actually quite difficult to add a test or add a few tests (as I did with CFF and SVG) without filling in a corresponding help section, because the compiler complains. So read the CHM file first, as it is written by the same people/person who wrote the test. Hopefully he/she explained why some issue is considered troublesome and warrant a warning. I am quite happy to include additional paragraphs from people if people feel like they can explaining issues better.

- on W1110, I thought it was fairly clearly written - there is "what the spec allows", and there is "older legacy systems (printers)".  If you think your font will never ever be used for printing, or on older systems, then obviously you could ignore it. I don't really understand why the issue needs dragging on and out. But remember 'web font' does not mean "screen-rendering only" as the user's printer needs to be able to cope too, if he/she decides to print from the Web browser.

- farming off issues to font engines or font editors seems irresponsible. Yes, font engines can cope with a lot of weird shit; and yes, many font editors can auto-correct or warn on issues.

But - font engines (both on screen in the major ones, and printers) are not created all equal, or up to spec. There are part of the spec which are well-written and therefore well-implemented by most rendering engines; there are part which are ambiguous, and people have different opinions - for this a "font checker" should warn ; and there are undocumented behaviors (where different font engines are free to behave differently). yes, if you create a font that is meant to work with one platform - e.g. Windows, and *not* ever print from windows, then you can ignore a lot of that too.

Relying on Font editor to auto-correct /warn is quite impractical - a font editor, particularly the interactive kind, need to have a guaranteed response time - it must save your work fully within say, 2 minutes after you press the "save" button; while it can and should check for common problems, a dedicated "font checker" that will spend as much time and do as thorough a report on any possible issues, without needing to worry about responsiveness, and in turn, you only run once in a while and let it takes as long as it will take to do a check, is a good thing.

Out of the 300 fonts that windows ships, about 10% took longer than 20 minutes to run the full check. The longest is 7 hours with one of the CJK fonts. There are small changes e.g. In prep or cvt which affects every glyph - yet you do not want to wait 7 hours for your font editor to check, every time you touch either prep or cvt. so you run a check only when you think is needed.

That's a good thing to separate the role of font editor vs the role of font checker - one optimises for responsiveness, the other for thoroughness.

On printing/printers, the cheaper ones might do better if you specialises in making shitty web fonts. The drivers for cheap printers basically do hires screen-dumps, while the more expensive printers take the fonts from the OS as they are.

So if your font is crap and happens to work okay on screen, you get better result in cheap printers. By "better" I mean "closer to screen display".