Re: What would be considered a fault in font encodings?

Le Ven 30 octobre 2009 16:02, Paul Flo Williams a écrit : Welcome Paul, And thank you for this very interesting message whether I'd done anything stupid in all the above, and I wondered whether loading a font into FontForge and raising errors upstream would be part of the normal workflow of a font packager? Are there any reports from FontForge that are thought to be too pedantic to bother with? Fonts are a technical/artistic object. To be honest, the technical quality of FLOSS fonts vary wildly and some are very poor. This is due to many factors: A. the requirements are complex and evolving — the font standards are complex and evolving (opentype, unicode, cid tables, etc). If one does not allocate resources to maintenance, a font file will slowly become irrelevant, even if it was perfect to start with. But all to often, authors release fonts as abandon-ware — the technical environment changes: today's screens and printers are not the same as a decade ago, the font libs have been replaced in all OSes and do not care about the same elements as before — font usage changes too: languages that were irrelevant before (because no software could manage them) are now widely used, gimp/inkscape/scribus means complex documents can now be produced by more than the small minority that can afford Adobe prices (and can buy font collections) B. FLOSS font authors are poorly equipped to deal with them — many font authors have an artistic, not technical background — many font authors still create fonts in isolation (the lone brilliant artist myth), and therefore do not benefit from the support and structuring larger organizations can provide — the tooling, frankly, sucks (I believe this is also the case proprietary side, foundries manage thanks to better organization) C. FLOSS hackers did not help a lot. Hackers have very low font needs: code is ASCII only, does not need scaling, does not need font effects, so a simple bitmap monospace ascii font with a single regular face will make them happy. Many of them do not understand to this day the complexity required to satisfy the needs of other "normal" users. So they write countless video players or mail apps, but very few of them even think about the text rendering part. We do have several examples that show technically excellent complex FLOSS fonts are possible (DejaVu, SIL fonts, etc) but they are very much the exception. I believe distributions could play a key role here by helping font authors to identify the problems in their fonts, what the low hanging fruits are, what are the conventions worth following. They should also help relay font author wishes tooling-side, and help relay font lib writers wishes font author-side. This is what they already routinely do for code; there is no reason they could not do it for other technical objects such as fonts (plus they need to do it: if we continue to rely on the GNOME Foundation, Red Hat, or Google, to buy expensive closed fonts, and re-license them, there is no way we'll be able to compete with desktops that include much wider font offerings by default in the long term). But, this is a could. Lots of work needs to be done for this to happen. We need to identify the technical problems that need fixing. We need to write tests to find them in fonts. We need to communicate the results to font authors. We need to document the usual way to fix each of them. As a first step, I've spent the last months writing an auditing script in my free time. Yesterday I did a fist mailing based on this script. http://git.fedorahosted.org/git/fontpackages.git?p=fontpackages.git;a=his... It is by no means complete or perfect. There are many problems I do not test for. Some tests (such as fontlint) are woefully inadequate: fontlint will error on problems we do not really care about (because they're so prevalent font libs learnt to workaround them), but only warn about metadata problems that can be fixed easily and are inter-operability problems (how do you share a document that references a particular font, if its name is not the same on every system?). Fontlint will also generally forget to tell you what the consequences of X or Y are and how one could fix it. Still, it is way better than we had before. Before, we had nothing. Unfortunately, the feedback so far has been negative and hostile. People who packaged a static font blob thinking it needed no maintenance do not like discovering it needs some. Sometimes they are aggressive because upstream vanished and so they feel they can not do anything. Sometimes they have problems understanding the messages the script output. It is very hard to overcome inertia and bad habits. The current font situation is bad but doing nothing and shooting the messenger is always an attractive proposition. I could really use help to improve the wording of my audit messages, so they are clearer to the people who get on in their inbox and they do not feel aggressed by them. This seems very simple, but it is incredibly important to get things to change. If you are interested to make floss fonts better, and have some time to donate, there is a lot of work to do. As you noted one first step could be to triage fontlint output, and make it more useful. (add explanations, review error criticity, try to output something scripts can easily be fed, etc). The number of people working on the subject right now is really to low to make quick progress. Any new contributor would make a huge difference. -- Nicolas Mailhot -- Nicolas Mailhot