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 _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
