W3C home > Mailing lists > Public > www-style@w3.org > January 1996

Re: FW: Font-family specification

From: Benjamin C. W. Sittler <bsittler@mailhost.nmt.edu>
Date: Fri, 26 Jan 1996 16:24:59 -0700 (MST)
To: "Scott E. Preece" <preece@predator.urbana.mcd.mot.com>
Cc: cwilso@microsoft.com, www-style@w3.org
Message-Id: <Pine.SUN.3.91.960126162226.22224D-100000@dunn>
On Fri, 26 Jan 1996, Scott E. Preece wrote:

>    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
Received on Friday, 26 January 1996 18:52:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:53:43 GMT