- 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
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 UTC