You are aware that up to 8% of Caucasian males and 1% of Caucasian females have some degree of red-green color blindness? It is one of the most widely-known and common X-linked inherited illnesses. "X-linked" as in located on the X chromosome - males has one and female two, so female can be carrier without being affected.
So one always have to be careful about relying on color to convey information - for example, if you use green-on-red for emphasis, it might have the opposite effect: a substantial part of the general population simply see it as redacted.
I am also of the opinion that legibility comes first - ornamental to the extent of sacrificing legibility isn't.
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.
This seems to be asking the wrong people - you may get a better answer asking say, the libreoffice people or the TeX people. And possibly without asking anybody, just reading libreoffice's source code.
People who tried to implement the ooxml spec, to match word, probably know the answer. And that would be the libreoffice people.
It is intelligent font + dumb rendering vs dumb font + intelligent rendering (sort of). So in a way, yes. Instead of getting the display system to move and shift the curves intelligently, Bill Gates offload the responsibility of font looking nice on all resolution to the font designer.
Maybe not entirely Bill's fault - Apple was in it as well, and Adobe could be blamed for withholding the rendering of postscript in the type manager, and not license it cheaply also...