Re: [Fonts]Proposal for XML-based font configuration
Keith Packard writes: please let me know if using libxml is a bad idea; it seems a bit easier to use than expat. expat, with its SAX like API. is easier to use if you want to parse XML files which don't obey a precise schema/DTD, or if you absolutely need to process elements of the file before reading the file is finished. libxml is easier to use if you have a schema/DTD, and want to transform the XML file's contents into a set of C structs. Which is your case here. Bruno ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Proposal for XML-based font configuration
Around 7 o'clock on Jan 22, Juliusz Chroboczek wrote: Writing a parser for a well-designed language is a trivial exercice, whether you use yacc/lex or write it by hand (as Real Men do). I don't think that giving up the elegance of a human-readable language for the perceived convenience of being able to use off-the-shelf tools is a sane trade-off. The language may well be human readable, which is certainly a feature, however, it suffers from two significant problems: 1) Human readable does not immediately translate into human writable. In particular, one must learn the syntax of the language before one can modify the file. Using an existing syntax eliminates this step. 2) Programmatic modification of the file is difficult, and often loses most of the formatting and comments. Given that we expect to expose this interface to people not using it on a daily basis, we should anticipate that most configuration will be done with tools other than a simple text editor. I'm willing to make things slightly harder for the expert user to permit less familiar users to take advantage of the functionality through external configuration tools. External configuration is already a problem; KDE 3 includes sophisticated Xft configuration mechanisms and has done so by incorporating large parts of the Xft source code into their library. I can't easily extend the capabilities of my library without significantly impacting their tool. I think a well designed XML DTD will be nearly as easy to use as the existing Xft configuration language; certainly the semantics are the same, only the syntax has changed. Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Proposal for XML-based font configuration
Around 12 o'clock on Jan 22, Markus Kuhn wrote: I strongly agree. XML is an abdomination and practically all people who think that XML is the solution to their problem have neither understood XML nor their problem. While XML does currently enjoy perhaps too much popularity, I submit that this case may well fit the model. I have one application that needs to read and understand the full content of the font configuration file, for that the current Xft config file syntax is sufficient. Howver, on top of that, I'm gaining many separate applications that need to read *and write* the file. Many of these needn't understand the entire semantics of the file but all of them need to make sure that the resulting file can still be read by the font configuration library while making changes to parts that they do understand. My alternative to XML is to build configuration file editing capabilities into the font configuration library. That would take significantly more work while at the same time limiting applications to a C interface. One requirement would be to preserve the original formatting and comments of the configuration file; the current parser discards that information while XML does it automatically. I don't find the XML syntax that objectionable for something I expect to edit only once or twice during system configuration; less experienced users will never see the format and will instead take advantage of higher level tools than emacs (or perhaps just some new e-lisp code customized for font configuration :-). Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Proposal for XML-based font configuration
On Tuesday 22 January 2002 04:31, Keith Packard wrote: Around 2 o'clock on Jan 22, Gioele Barabucci wrote: I'd also write dir/etc/X11/fonts/TTF/dir... Ok, now that I believe I can preserve whitespace in those spots, I've redone things as follows: I think that alias familyTimes/family preferfamilyTimes New Roman/family/prefer defaultfamilyserif/family/default /alias could be rewritten as alias familyTimes/family !-- you should really find an abjective which best describes prefer (IMHO verbs are ugly in XML -- family preferred=yesTimes New Roman/family family default=yesserif/family /alias or better (exploiting the fact that order matters in XML) alias original_familyTimes/original_family similar_familyTimes New Roman/similar_family similar_familyMy Own Times New Roman/similar_family default_familyserif/default_family /alias -- Gioele Barabucci (Gb]) ) mailto:[EMAIL PROTECTED] ) http://www.gioelebarabucci.com ) ) I've been and now I've gone ) ) /Magic Pie^Oasis ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Proposal for XML-based font configuration
In migrating the font configuration mechanism out of Xft and into a separate library, I have an opportunity to redefine the configuration language to make it easier for external agents to parse and modify. I've decided to give XML a try and see how it looks; other applications have started migrating to this for configuration and it has a lot of appeal. Please find enclosed the proposed DTD and a sample font configuration file. They have only been run through xmllint --valid; I have not started on any related C code. For those of you with more XML experience than I (that shouldn't be hard, I just printed the XML spec this morning), please let me know if I'm doing things in silly or unconventional ways. Also, please let me know if using libxml is a bad idea; it seems a bit easier to use than expat. If this transition goes well, I may propose that the XFree86 server configuration file be transitioned to XML as well; the ability to have external agents edit the file without needing a complete understanding of the syntax should be very useful. Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab !-- This is the Document Type Definition for font configuration files -- !ELEMENT fontconfig (dir | cache | include | include_if | match | alias)* !-- Add a directory that provides fonts -- !ELEMENT dir EMPTY !ATTLIST dir dir CDATA #REQUIRED !-- Define the per-user file that holds cache font information. If the filename begins with '~', it is replaced with the users home directory path. -- !ELEMENT cache EMPTY !ATTLIST cache file CDATA #REQUIRED !-- Reference another configuration file; note that this is another complete font configuration file and not just a file included by the XML parser. Set 'ignore_missing' to 'yes' if errors are to be ignored. If the filename begins with '~', it is replaced with the users home directory path. -- !ELEMENT include EMPTY !ATTLIST include ignore_missing (no|yes) no file CDATA#REQUIRED !-- Aliases are just a special case for multiple match elements They are syntactically equivalent to: match test name=family string value=[family]/ /test edit name=family mode=prepend string value=[prefer]/ ... /edit edit name=family mode=append string value=[accept]/ ... /edit edit name=family mode=append_last string value=[default]/ ... /edit /match -- !ELEMENT alias (prefer?, accept?, default?) !ATTLIST alias family CDATA #REQUIRED !ELEMENT prefer (family)* !ELEMENT accept (family)* !ELEMENT default (family)* !ELEMENT family EMPTY !ATTLIST family family CDATA #REQUIRED !ENTITY % expr 'number|string|name|matrix|boolean_or|boolean_and|eq|not_eq|less|less_eq|more|more_eq|plus|minus|times|divide|not|if' !-- Match and edit patterns. If 'target' is 'pattern', execute the match before selecting a font. if 'target' is 'font', execute the match on the result of a font selection. -- !ELEMENT match (test*, edit*) !ATTLIST match target (pattern|font) pattern !-- Match a field in a pattern if 'qual' is 'any', then the match succeeds if any value in the field matches. if 'qual' is 'all', then the match succeeds only if all values match. -- !ELEMENT test (%expr;) !ATTLIST test qual (any|all)any name CDATA#REQUIRED compare (eq|not_eq|less|less_eq|more|more_eq) eq !-- Edit a field in a pattern The enclosed values are used together to edit the list of values associated with 'name'. If 'name' matches one of those used in a test element for this match element: if 'mode' is 'assign', replace the matched value. if 'mode' is 'assign_replace', replace all of the values if 'mode' is 'prepend', insert before the matched value if 'mode' is 'append', insert after the matched value if 'mode' is 'prepend_first', insert before all of the values if 'mode' is 'append_last', insert after all of the values If 'name' doesn't match any of those used in a test element: if 'mode' is 'assign' or 'assign_replace, replace all of the values if 'mode' is 'prepend' or 'prepend_first', insert before all of the values if 'mode' is 'append' or 'append_last', insert after all of the values -- !ELEMENT edit (%expr;)* !ATTLIST edit name CDATA#REQUIRED mode (assign|assign_replace|prepend|append|prepend_first|append_last) assign !-- Elements of expressions follow -- !ELEMENT number EMPTY !ATTLIST number value CDATA #REQUIRED !ELEMENT string EMPTY !ATTLIST string
Re: [Fonts]Proposal for XML-based font configuration
Around 1 o'clock on Jan 22, Giovanni Pensa wrote: I simply love Lisp in XML. Lisp people really hate it. I felt it would be better to use XML for expressions than embed a separate expression parser in the upper levels. There has been a long debate on Attributes vs. Elements. I think that, while you are free to do as you feel, text should be implemented as text nodes (that is, as content of elements) unless there's a good reason to make it an attribute value; and the only reasons I do are: IDs, URIs and enumerations. One (probably specious) reason was that I figured white space was more likely to be preserved correctly within an attribute than with an element. Given the xml:space attribute, perhaps this isn't an issue. Can I ensure that white space remains unmolested within family names? Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Proposal for XML-based font configuration
On Tuesday 22 January 2002 01:16, Giovanni Pensa wrote: alias family=Times preferfamily family=Times New Roman//prefer defaultfamily family=serif//default /alias I'd write familyTimes New Roman/family. I'd also write dir/etc/X11/fonts/TTF/dir... -- Gioele Barabucci (Gb]) ) mailto:[EMAIL PROTECTED] ) http://www.gioelebarabucci.com ) ) I've been and now I've gone ) ) /Magic Pie^Oasis ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Proposal for XML-based font configuration
Around 2 o'clock on Jan 22, Gioele Barabucci wrote: I'd also write dir/etc/X11/fonts/TTF/dir... Ok, now that I believe I can preserve whitespace in those spots, I've redone things as follows: Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ?xml version=1.0? !DOCTYPE fontconfig SYSTEM fonts.dtd !-- /etc/fonts.conf file to configure system font access -- fontconfig !-- Find true type fonts in this directory -- dir/usr/X11R6/lib/X11/fonts/truetype/dir !-- Accept deprecated 'mono' alias, replacing it with 'monospace' -- match target=pattern test qual=any name=familystringmono/string/test edit name=family mode=assignstringmonospace/string/edit /match !-- Load per-user customization file -- include ignore_missing=yes~/.fonts.conf/include !-- Alias well known font names to available TrueType fonts -- alias familyTimes/family preferfamilyTimes New Roman/family/prefer defaultfamilyserif/family/default /alias alias familyHelvetica/family preferfamilyVerdana/family/prefer defaultfamilysans/family/default /alias alias familyCourier/family preferfamilyCourier New/family/prefer defaultfamilymonospace/family/default /alias !-- Provide required aliases for standard names -- alias familyserif/family preferfamilyTimes New Roman/family/prefer /alias alias familysans/family preferfamilyVerdana/family/prefer /alias alias familymonospace/family preferfamilyAndale Mono/family/prefer /alias /fontconfig !-- This is the Document Type Definition for font configuration files -- !ELEMENT fontconfig (dir | cache | include | include_if | match | alias)* !-- Add a directory that provides fonts -- !ELEMENT dir (#PCDATA) !ATTLIST dir xml:space (default|preserve) 'preserve' !-- Define the per-user file that holds cache font information. If the filename begins with '~', it is replaced with the users home directory path. -- !ELEMENT cache (#PCDATA) !ATTLIST cache xml:space (default|preserve) 'preserve' !-- Reference another configuration file; note that this is another complete font configuration file and not just a file included by the XML parser. Set 'ignore_missing' to 'yes' if errors are to be ignored. If the filename begins with '~', it is replaced with the users home directory path. -- !ELEMENT include (#PCDATA) !ATTLIST include ignore_missing(no|yes)no xml:space (default|preserve) preserve !-- Aliases are just a special case for multiple match elements They are syntactically equivalent to: match test name=family string value=[family]/ /test edit name=family mode=prepend string value=[prefer]/ ... /edit edit name=family mode=append string value=[accept]/ ... /edit edit name=family mode=append_last string value=[default]/ ... /edit /match -- !ELEMENT alias (family, prefer?, accept?, default?) !ELEMENT prefer (family)* !ELEMENT accept (family)* !ELEMENT default (family)* !ELEMENT family (#PCDATA) !ATTLIST family xml:space (default|preserve) 'preserve' !ENTITY % expr 'number|string|name|matrix|boolean_or|boolean_and|eq|not_eq|less|less_eq|more|more_eq|plus|minus|times|divide|not|if' !-- Match and edit patterns. If 'target' is 'pattern', execute the match before selecting a font. if 'target' is 'font', execute the match on the result of a font selection. -- !ELEMENT match (test*, edit*) !ATTLIST match target (pattern|font) pattern !-- Match a field in a pattern if 'qual' is 'any', then the match succeeds if any value in the field matches. if 'qual' is 'all', then the match succeeds only if all values match. -- !ELEMENT test (%expr;) !ATTLIST test qual (any|all)any name CDATA#REQUIRED compare (eq|not_eq|less|less_eq|more|more_eq) eq !-- Edit a field in a pattern The enclosed values are used together to edit the list of values associated with 'name'. If 'name' matches one of those used in a test element for this match element: if 'mode' is 'assign', replace the matched value. if 'mode' is 'assign_replace', replace all of the values if 'mode' is 'prepend', insert before the matched value if 'mode' is 'append', insert after the matched value if 'mode' is 'prepend_first', insert before all of the values if 'mode' is 'append_last', insert after all of the values If 'name' doesn't match any of those used in a test element: if 'mode' is 'assign' or 'assign_replace, replace all of the values
Re: [Fonts]Proposal for XML-based font configuration
Keith Packard: KP I have an opportunity to redefine the configuration language [...] KP I've decided to give XML a try and see how it looks; [...] Keith, please, don't. The former configuration language was human-readable and human- writeable. This is not the case of your new XML thingie. While there do exist human beings who can read XML on sight, all known occurences are Ph.D. students and lose this knack as soon as they submit. Writing a parser for a well-designed language is a trivial exercice, whether you use yacc/lex or write it by hand (as Real Men do). I don't think that giving up the elegance of a human-readable language for the perceived convenience of being able to use off-the-shelf tools is a sane trade-off. Regards, Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
