[Fontconfig] Marking glyphs as deliberately blank, per font

[Nicolas Mailhot]

Le vendredi 27 novembre 2009 à 16:16 -0500, Behdad Esfahbod a écrit :

> And I asked for his input.

It was a good time for me to do so, as I spend all the year looking into
font packages, and don't always take the time to provide feedback on
what I see.

> Unfortunately though the problems seem to be much more fundamental
> than I 
> thought.  Nicolas is right to the point with problems he brings up. 
> I'm not 
> sure I agree with solutions he proposes though.

I'm sorry if I was not convincing enough

> Alternative solutions, for example, include:
> 
>    - Write XSL converters from his proposed simple syntax to
> fontconfig format,

I was doing xslt before the fontconfig master conf file was split, it
works for advanced packagers, everyone else refuses to touch it. So if
there needs to be xslt processing it should be hidden from fontconfig
users

>    - Write a GUI / TUI tool to generate fontconfig confs.

A gui/tui would be great but is that something that much easier to do
than cleaning up the config syntax? The history of such config file
generators is not very good, and usually you need to clean up the config
syntax anyway so humans have a chance to understand problems when the
generated config is not working.

> The point being: we all know XML is too verbose to write manually. 
> That's by 
> design though.  The solution is to not write it manually...

I disagree there. XML is too verbose to get it right or human friendly
is a urban myth which is resurrected every time a developer does not
want to make this effort. But the web was largely created using manual
XML-y syntax (before editors were available) and is a clear proof
human-friendly syntax is possible (there are other examples such as
docbook). However such human-friendliness can only be achieved if a lot
of time is spent trying to understand how humans will need to use the
file, while developers like to map their application quirks directly to
XML.

I've always considered the original xml fontconfig syntax brilliant, you
could point someone to the sans preference list for example and he would
have no problem editing it without reading any manual file.

The problem is that we've started to do more and more with fontconfig
since then, and all the small additions that happened over the years,
while making it possible to do more, progressively transformed a
fontconfig file from something consistent and simple and easy to read in
something a lot less obvious. And that is easy to write now, with
hindsight, seeing what the use-cases in the field are, and were config
writers stumble. It is not a criticism of the people that did those
additions, hindsight his wonderful but you only get it after mistakes
are made.

So fontconfig syntax is IMHO ripe for a re-factoring, to simplify it,
improve consistency, and hide all the low-level stuff that seeped in
through and that fontconfig users should really not have to care about.

(it is not different from what you've done with HarfBuzz-ng, a config
file is a software ↔ human API, and APIs need reworking from time to
time)

> Anyway, I'm afraid I can't pay too much attention to this right away
> as I have 
> to get back to finishing HarfBuzz and other long overdue projects.

I hope that whenever you, or another fontconfig developer, has the time
to work on the subject, he'll take some time to reflect on what I wrote
this week.

-- 
Nicolas Mailhot