Re: font-family and font names list

["Peter B. West" <pb...@powerup.com.au>]

  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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org