Re: Comments on Working Draft 26-July-96

Bert, thanks for replying in such detail.

A few clarifications, where my comments were not clear...

> there is currently almost no control over the way large initials
> align with the text.

I think if you specify number of lines rather than size, the language
is no more complex, but the result may look much better, as the intent of
the user is made explicit.  If you use a size, people will use sizes like
58pt, knowing this generates a 3-line drop cap with the font they are using.
On another device, it may well not work properly...

>>  You should allow a string here as well as the fixed keywords.
> 
> The font name cannot be specified in CSS1, only the family name and
> the font properties.

Sorry, I wasn't clear.  I meant to suggest allowing a string for a font
property to match, so that you can use Frederick Slanted or Lydian Cursive.

>  > 5.2.1 Font encoding
> 
> Unreadable Web pages is exactly what this section tries to avoid. If
> that is not clear, than we do indeed need a better example. I'll see
> if I can add the complementary example: how to get Greek text.

I think that would help a lot.

>  > 5.2.3 Font Family
>  >     Last paragraph -- If you want to get taken seriously by the
>  >     pre-press industry, don't say that Helvetica looks almost identical
>  >     to Univers!!  They are closer to each other than Univers and Times.
> 
> But they do look similar, don't they?

Well, to someone untrained in typography they do :-)  `Similar' is a
relative term, of course.
> We can change that sentence.

I think that might be a good idea.  I know it sounds minor, but sometimes
God is in the details.

>  > 5.2.4 font-weight
[...]
> don't have more than nine (another restriction in CSS1 that the Font
> WG will remove). (Btw. the draft you're looking at only has seven, the
> next will have nine.)

If you're going to try and remove it by using the PANOSE numbers that are
available in some TrueType fonts, note that most of the fonts that are
sold in the design world today do not have them.  In other words, although
most font formats may support them, that's like saying that most forms
of transport do not use gasoline, so gasoline is not important in the world
economy.  Most fonts that are sold today for use in design are in the Type 1
format.  And that's where CSSn will have to make an impact if it is going
to be used in publishing.  Or that's how I see it, anyway.

>  >     (3) what happens if there is no bold weight, and the style sheet
>  > 	asks for one?
> It will be specified in the upcoming draft. Latest ideas are to use
> the normal font instead.

It might be better to allow artifical emboldening or a different colour.

> The CSS1 properties of TrueType fonts (at least those for OS/2 &
> Windows) can often be determined automatically. For other fonts
> somebody (or a program loaded with heuristics) will have to provide
> the information.

Again, the important formats at first are likely to be Type 1 on Macintosh,
followed by Type 1 on Windows, followed by other formats.  Since many
non-Adobe Type 1 font vendors explicitly forbid font embedding, and others
are changing their licence agreements to forbid it as soon as they hear
about the dangers of piracy, font substitution may well be used more than
one might otherwise have thought.

I realise that Microsoft's Internet Explorer is likely to be the browser
used by many or most people to test their CSS1 styles, but if you go to
a marketing or design agency, the chances are that they'll be using it on
the Macintosh.  Some of the design applications are migrating to Windows,
and the latest Fractal Painter actually shipped on Windows before Mac, so
things are changing, but it will take a while.

A lot of words, sorry.  I am not a Macintosh user myself, particularly,
but I think that Mac/Type 1 compatibility is very important in this area.

>> 5.2.5 font style
>>     You might have a font like Monotype Blado with only italic [...]
> Then it looks like Monotype Blado will have only one font-style: normal,
> and no italic or oblique.

Er, no, it only has an Italic.  It can be used with Bembo, for example.

>>     There seems to be a typo with a || in the syntax.
>>     Why can't I combine normal with small-caps???
> 
> It's not a typo, you can really only have either normal, or one or
> more of the others. Normal + small-caps is a contradiction.

I didn't realise tht the || meant something different from |, sorry.

How do I specify that within an H2 using small-caps, <em> is
to use italic, but within an H2 using italic small-caps, <em> is to
use normal small-caps?

> However, small-caps will be split off, leaving `normal|italic|oblique'
> for the font-style.

Oh, if that answers my question about h2/em, that's fine.

>     <acronym>HTML</acronym>
>     ACRONYM {
>         text-transform: lowercase;
>         font-style: small-caps }
> 
> but the danger is that one property may be working while the other
> fails, leaving exactly the wrong result in the output. A way of
> ensuring that the two operations are interdependent seems called
> for. I think you interpreted `small-caps' to be that atomic operation?

Yes, I did.

>  >     Good algorithms for generating small caps from a normal face are
>  >     * make the cap height be the same as that of "i", or set it to
>  >       the x-height + 1/3 of (cap height - x height).
>  >       Note that ascender height and cap height are significantly different
>  >       for Old Style (and some other) fonts.
>  >     
>  >     * make the letters 10% wide
> 
> Something like that will explicitly be allowed in the new text.
> 
oops, 10% wide should have read 10% wider, sorry.

>  > misc font:
>  >     Where do values such as Condensed and Expanded fit in? 

> These variants currently cannot be selected from CSS1.
Oh.  I think that's unfortunate, although maybe with OpenType that won't
be a problem any more?

>> 5.4.1 word spacing
>> 
>>   A percentage of the default would be a good thing to have available here,
>>   inherited as for line height.  Note that 1 em is a very strange value
>>   for word spacing -- 1 en would be a better example.

God in the Details again -- I suggest using 0.3 em as an example word space.

>>   Most typographic software allows the specification of three values here.
>>   (1) minimum word space
>>   (2) preferred word space
>>   (3) maximum word space
> It's on our list for the CSS High-Quality Printing extensions.

Actually I think this should be done for the screen.
At the very least, change the word spacing example!  Word spacing that
is too wide reduces legibility, according to all the studies I've seen.
See Robert Bringhhurst or Colin Whieldon.

If not, at the very least you should not permit letter spacing to be
used for justification unless the style sheet calls for it.  A newspaper
might want to do this in order to use absurdly narrow columns, and give
that Authentic Look :-), but otherwise the single most important factor
in legibility is letter spacing.  (more important than word spacing).

>> 5.4.2 letter spacing

> I'm not sure we need a property to turn automatic ligatures off. [...]

If you expect them to be automatic, then I suggest a note to the effect
that if display ligatures sich as ffi are used, the display agent should
normally suppress them if letterspacing is in effect.  Otherwise you get
d   i   ffi   c   u   l    t    examples.  You can't expect the author
to insert zero-width fillers here if the font on their system doesn't
have ligatures -- why would they think of it?

> We didn't want to go into too much detail as to what the formatter is
> allowed to do to justify lines.

Probably a good approach, I agree.  However, programmers are not always
typographers, so some guidance may be a good idea.  Hence, I suggested
mentioning that letter spacing should not normally be used for justification.
On paper, you can alter the spacing by a small amount -- say, 1/1000 of
an inch.  On the screen, you can't.  At least, not yet!

>> 5.4.4 vertical align

> You think it would be useful to add a keyword for centering on
> capitals?

Yes, because it's useful to be able to include an image that's a decorative
bullet used like T · H · I · S (where · is centred on the cap-height, or
slightly above it).

>> 5.4.5 text transform

>>   On another note... I suggest adding `invert', converting upper to lower
>>   and lower to upper.

> We already have uppercase, lowercase and capitalize. Adding invert is
> no problem, but is it really useful?

It's useful with caps/smallcaps.  I don't know if there are any other uses.
Perhaps if you make the small-caps atomic, as you mentioned above, invert
wouldn't be needed at all.  It's probably not that important.

>>   How do left and right justification work for Hebrew text, or other
>>   right-to-left languages?  Are they interpreted backwards?  I assume so.
> 
> In general, left means left and right means right, so left-aligned
> Hebrew text would be just that: left-aligned text. It doesn't change
> its meaning to `end-aligned'.

It might be worth making that explicit.  I would have implemented it
differently, had I been writing code, and yet still been within the spec
I think.

>> 5.5.3 border-url
>> 
>>   Why only 1 image and not 8?  Most border fonts have 8 characters that
>>   are used for the border -- one for each corner, and one for each side.
>>   For that matter, why can't I specify a font and a string?
> 
> Using characters for the border is a whole different model. Using 8
> images is quite possible but again something for the longer term.

Perhaps, but I think that's a shame.  On the other hand, CSS is already
quite large, so I can see your point.  The border font approach is one
that Quark and PageMaker users are presumably already comfortable with,
judging by the number of border fonts on sale...

Of course, then people would want tee-pieces and crossroads for drawing
tables...

> (I've seen `disc' in American texts as well, including in Netscape's
> attributes. Are you sure this a British versus American distinction?)

Yes.  I don't know why Netscape uses DISC.

>> 6.1 length units
>> 
>>   ``Child elements inherit the computed value, not the relative value''
>> 
>>   Except for line spacing (and word spacing and letter spacing if you
>>   allow percentages there)
> 
> Line-spacing does inherit the computed value (it has a numerical
> factor as well, in case you want to inherit the relation, instead of
> the value). For word-spacing and letter-spacing we would have to look
> at this rule again.

Elsewhere there's a note that a percentage linespacing gets inherited as
a factor, I thought.  Oh, I see what you mean.  Well, maybe word-spacing
should also be a factor.  I read it that way because of the 1 em example.

Some systems use the old Monotype/Intertype model, where space size is
a multiple of 18ths or 36ths of an em, with the default being a third
of an em.

>>   Relative units -- If you have xheight, why not also cap-height,
>>   ascender-height, descender depth and underline-position?
> 
> I don't think they are used for determining the thickness of a border,
> the size of a margin, etc. like ex is.

Well, underline _thickness_ is clearly used for determining a border
thickness!  Cap height is used for a line hight in titling/headers.
An adjustment by ascender/descender height (as appropriate) is used in
optical balancing of headlines.  But perhaps that's for later.

>>   What about en (0.5 em)?
> 
> No real problem, but since 2en=1em, en doesn't seem to add much.

No, but it's a more natural unit for many things, I think.

>>   What about Fournier and Cicero Points for use in Europe?
> Will anybody implement them?
Probably -- we programmers love that sort of thing...
But perhaps it is best not to use them.  I can hardly complain of cultural
supremacy if you are in France and I am in Canada! :-)

>>   finally, why on earth is pica spelt pc and not pica/picas?
> 
> Unfortunately, there seems to be no abbreviation for pica that is
> universally accepted. I've seen both pc and pi. We could drop pc and allow
> pica/picas...

Troff uses P.  I definitely prefer pica/picas.

Thanks again for taking the time to read my comments, and to reply to them.

Lee

Received on Thursday, 5 September 1996 12:49:15 UTC