> From: "Benjamin C. W. Sittler" <bsittler@mailhost.nmt.edu>
> | On Fri, 26 Jan 1996, Chris Wilson (PSD) wrote:
> |
> | >... The draft says "..., and spaces in font family names
> | > are replaced with dashes." This makes me as an implementor believe that
> | > spaces are only allowed when they are translated to dashes, quoted or not
> | > (i.e., even quoted spaces would be translated to dashes). The examples do
> | > not quote, either, which makes me not think about using quotes to protect
> | > spaces within individual family names.
> |
> | This is probably a bit of X-Windows-centric language that was left in the
> | draft accidentally. Under X, for example, one would handle "Lucida Sans
> | Bold" as a reference to the font "lucidasans-bold". Under MS Windows or
> | MacOS, it would probably be interpreted as the modifier "bold" applied to
> | the font "Lucida Sans" instead.
> ---
>
> Actually, the X names *do* preserve whitespace in the names, as in:
> -adobe-new century schoolbook-medium-r-normal--34-240-100-100-p-181-iso8859-1
> the dashes are used to separate fields in a formatted presentation of
> the font data. I thought the font name structure was a standard, but I
> may be wrong.
You're right. There's no good reason I can see to convert dashes to
spaces. Besides being unreadable, Times-Roman has to be converted *back*
to "Times Roman" when the stylesheet is parsed. Not a good idea, in my
view.
Benjamin C. W. Sittler