Re: [css3-fonts] Variants (Ligatures, Capitalization, Digits)

I don't actually see any need to separate swash and contextual swash, as far
as UI switches. I have never missed the lack of separate switches in the
apps I have been using this in.

In the "additional ligatures" example, what is shown as discretionary is
actually a perfect example of historical. I'm not denying that it was set
that way in the font, just saying that is a poor choice (by the font vendor
as well). John Daggest can feel free to contact me off-list so I can suggest
a better example from what you have on hand (or make one for you).

I also have some comments on Christoph's comments....

On Wed, Mar 9, 2011 at 9:02 AM, Christoph Päper <christoph.paeper@crissov.de
> wrote:

> Thanks for incorporating some of my earlier notes and suggestions.
>
> John Daggett:
> > * Section 6.4 subscript, superscript, ordinal description
>
> This actually might work.
>
> * Section 6.5 Ligatures
>
> “nums” matches “caps”, so why not “ligs”? :)
>
> People will probably want to use
>
>  font-variant-ligatures: none;
>
> and
>
>  font-variant-ligatures: all;
>
> For defaults specified by the font ‘auto’ seems more natural than ‘normal’,
> but the latter is usually used for shorthand resets.
>

I agree on the above, for the most part.


> I have said before <
> http://lists.w3.org/Archives/Public/www-style/2010Mar/0049.html> that I
> don’t think the current design of this feature is sound and we should rather
> use something user-friendly like
>
>  font-variant-ligatures: all | additional | common | none | auto/normal
>
> and leave users with special needs with ‘font-feature-setting’.
>

I prefer it as currently stated, as discretionary ("additional") vs
historical are independent items and not hierarchical.



> You would, at first glance, need something more verbose to make
> ‘font-variant’ being a shorthand possible (6.11), at least if you wanted to
> be able to set everything within the shorthand. At second thought,
> ligatures, capitals and digits don’t share keywords, even if you leave out
> “-ligatures”, “-caps” and “-nums”.
>
> * Section 6.6 Capitalization
>
> I have outlined my concerns earlier. This time I only want to suggest a
> change from
>
> | <caps-value> = small-caps | all-small-caps | petite-caps |
> all-petite-caps
> |              | titling-caps | unicase
>
> to
>
>  <caps-value> =  all? [ small-caps | petite-caps | titling-caps ]
>               | unicase
>
> If ‘all’ is specified with ‘small-caps’ or ‘petite-caps’, OT feature
> ‘c2sc’/‘c2pc’ is applied and if that is impossible, as a fallback,
> ‘text-transform’ is set to ‘lowercase’.
> If ‘all’ is specified with ‘titling-caps’, ‘text-transform’ is set to
> ‘uppercase’ (since there is no corresponding OT feature).
>
> If ‘text-transform’ is set to ‘uppercase’, ‘font-variant-caps’ is reset in
> a way that the OT feature ‘titl’ becomes activated.
>
> * Section 6.7 Numerical formatting
>
> I also still believe ‘font-variant-caps’ and ‘text-transform’ should
> interact with ‘font-variant-numeric’, i.e. <numeric-figure-values>:
> If ‘text-transform’ is set to ‘uppercase’ (directly or indirectly),
> ‘font-variant-numeric’ is reset in a way that the OT feature ‘lnum’ becomes
> activated.
> If ‘text-transform’ is set to ‘lowercase’ (directly or indirectly),
> ‘font-variant-numeric’ is reset in a way that the OT feature ‘onum’ becomes
> activated.
>
> And I still believe the value names are not well chosen, and neither are
> they in Open Type:
>
>  “lining”       (+lnum, -onum)
>  “casing”       (+onum, -lnum)
>  “proportional” (+pnum, -tnum)
>  “monospaced”   (+tnum, -pnum)
>
>  “oldstyle”     (+onum, +pnum)
>  “tabular”      (+tnum, +lnum)
>   …
>

Where are you getting that mapping of feature combinations to labels? I do
not recall any such thing from OpenType, and it isn't in the CSS 3 fonts
spec... I'm sure I'm missing something here. The definition of "oldstyle"
seems odd in requiring proportional....

Cheers,

T


-- 
“Puritanism: The haunting fear that someone,
 somewhere, may be happy.”
 —H.L. Mencken

Received on Wednesday, 9 March 2011 22:54:50 UTC