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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Le Ven 30 octobre 2009 16:02, Paul Flo Williams a écrit :

Welcome Paul,

And thank you for this very interesting message

> I guess I've got two fault reports to raise already, but I wanted to check
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

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.;a=history;f=bin/repo-font-audit

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

Fedora-fonts-list mailing list

[Index of Archives]     [Fedora Users]     [Font Configuration]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux