Joerg, I share your opinion about the detrimental effects of CSS on the spec, or rather, as Chris points out, of the manner in which CSS compatibility was introduced
"font-family" is especially nasty, not only because it can have a comma-separated list of (family-name|generic-family) items, but also (vale Dudley Moore) because the family-name elements can contain spaces. The existing code defines a Property class and ListProperty that extends it. parseProperty() prepares a ListProperty and starts the parsing by calling parseAdditiveExpr(), which returns a Property. If TOK_EOF is pending, check the ListProperty. If it is null, the just-generated Property is returned, else the Property is appended to the ListProperty, and the ListProperty is returned. If TOK_EOF is not pending, there is more of the expression to parse, so add the Property to the ListProperty and loop on the call to parseAdditiveExpr() to parse the next value. On the face of it, this parser cannot deal with a comma-separated list at all, except as a list of args to a function call. The looping behaviour is for space-separated values. I am at a bit of a loss to explain the error, though. I would expect to see a "syntax error" PropertyException. Maybe I missed something in the parser. Maybe all that follows is redundant. My approach is to define a PropertyValue interface, implemented by each of the property value types, and PropertyValueList which extends LinkedList and implements PropertyValue. The elements of the LinkedList are PropertyValues. (This is close to the existing arrangement, where ListProperty extends Property, and the elements of ListProperty are instances of Property.) Modify PropertyParser.parse() to return a PropertyValue, and change the basic parse loop. Like the existing code, prepare a PropertyValueList and start the parsing, receiving a PropertyValue. If EOF is pending after the call to parseAdditiveExpr(), and the PropertyValueList is empty, return the PropertyValue, else add the PropertyValue to the PropertyValueList and return that. However, when EOF is not pending, check for COMMA pending. If so, we are parsing a comma-separated list, presumably. Discard the comma, add the PropertyValue to the PropertyValueList, and loop on the call to parseAdditiveExpr(). If COMMA is not pending, we are parsing a space-separated list, so call parseSublist(Property) with the just-returned Property as the argument which will become the first element of the sublist. The parseSublist() call returns a PropertyValueList when the expression is exhausted, or when a comma separator is encountered. This sublist is appended to the parent PropertyValueList. This allows two types of list in the expression to be distinguished. A PropertyValueList returned by the parser contains, at the top level, comma-separated elements. If any of these elements, including the only element, are themselves PropertyValueLists, they contain space-separated lists of elements. The syntax of the expressions only requires, as far as I can see, these two levels. In the case of a font-family expression like, say, "Times New Roman, New Century Schoolbook, serif", the returned PropertyListValue would contain three elements: PropertyValueList, PropertyValueList, NCName, where the NCName string value is "serif". The PropertyValueList elements would each contain three elements: NCName, NCName, NCName. I.e., "Times" "New" "Roman" and "New" "Century" "Schoolbook". Presented with such a PropertyValueList, the font-family property can re-construct the font-family names. The spec explicitly allows such behaviour. "Font family names containing whitespace should be quoted. If quoting is omitted, any whitespace characters before and after the font name are ignored and any sequence of whitespace characters inside the font name is converted to a single space." (7.8.2 "font-family") The existing code can readily be modified in the same way. The parser currently returns a Property, which may be an instance of ListProperty. As mentioned above, the elements of a ListProperty are Property instances, therefore possibly ListProperty instances. What to do about the code generation, something which I am keen to remove, is beyond my ken, but I'm sure Karen or Keiron will find a way. Peter J.Pietschmann wrote: > Oleg Tkachenko wrote: > >> I'm trying the following object in fop 0.20.3: >> >> <fo:inline font-style="italic" font-family="Arial, Helvetica, Geneva" >> font-size="11.0pt">Tuesday, Mar. 5, 2002 12:33</fo:inline> >> >> And got error message: >> [ERROR]: unknown font Arial, Helvetica, Geneva,normal,normal so >> defaulted font to any >> [ERROR]: defaulted font to any,normal,normal > > > I remember a post which basically said that font lists > are a last minute addendum to XSLFO imposed for CSS > compatibility. I *hate* CSS for the havoc it wrecked on > other otherwise quite sensible standards. The font list > attribute introduces another language with a rather > nontrivial grammar, which is incidentally incompatible > with the expression language used for other properties. > The parser in fop/expr doesn't obviously handle it, and > i didn't find evidence that the font-family attribute is > handled by another parser, the foproperties.xml declares this: > <property> > <name>font-family</name> > <inherited>true</inherited> > <datatype>String</datatype> > <default>sans-serif</default> > </property> > So my guess is the feature is not implemented. :-( --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
