Re: CSS fonts only?

On 15/03/2008, Christopher Fynn <cfynn gmx net> wrote:
> Gail Carmichael wrote:
>  > Hi Christopher (and others)!
>  > Basically what I am saying is that the enumerations defined here
>  > <>, like
>  > the variant, for example, have a specific subset of values.  I just
>  > happened to notice that the defined values are pretty much equivalent to
>  > allowable CSS text attributes.
>  > In Inkscape, we use the PangoFontDescription pretty extensively.  It is
>  > how font information is stored in memory while the program is running,
>  > for example.  The problem is that some fonts have, say, a swash variant,
>  > which cannot be described with CSS text attributes, and also cannot be
>  > described with any of these enumerations in Pango in terms of the
>  > PangoFontDescription.  Instead, the regular face of a font family is
>  > used (as a default fall-back), and "fancy" fonts are thus not accessible
>  > in Inkscape.
> Gail
>  My guess is the best way to handle this w Pango would be through OpenType
>  features & lookups i.e. to include the swash variant glyphs in the base font
>  and have those accessed through OpenType features and lookups - which could
>  be either contextual or user selected. Having *separate* alternative "fancy"
>  fonts with swash / small caps / etc. fonts is the old way of doing things - if
>  you think about it that way, is much more limited.
>  For user selected / discretionary OT features the application (Inkscape)
>  would need some kind of interface /menu through which the user could
>  apply the features she wanted to.
>  WRT CSS - there has been some serious discussion off and on over several years
>  (on the OpenType list, CSS related lists and other places) about specifying - or
>  applying OpenType features through CSS.
>  regards
>  - Chris
>  > Hope that clarifies what I am trying to say.  It would be cool to pretty
>  > much just add more values to the enumerations (and supporting code) so
>  > more varieties of fonts could be described.  I wanted to know what you
>  > guys thought of that possibility - is there some technical or
>  > philosophical reason, as can sometimes happen, for not doing so?
>  > Thanks
>  > Gail

Swash variants is something that can be handle through OpenType
features. Although we still need the interface and the API to apply

Even when that's done there are plenty of fonts out there that have
Swash variants, or Caption, Heading, Display, Bubble, Outline, and
whatever exotic variant that cannot be handle with OT features. Look
at Adobe Font Foolio for example. Some of its font families have
Caption, Display and Subhead variants. We need a way to handle those.
For example Adobe Jenson Pro has 4 variants for Regular. fc-list will give:
Adobe Jenson Pro,Adobe Jenson Pro Subh:style=Subhead,Regular
Adobe Jenson Pro:style=Regular
Adobe Jenson Pro,Adobe Jenson Pro Disp:style=Display,Regular
Adobe Jenson Pro,Adobe Jenson Pro Capt:style=Caption,Regular
These have different pairs of preferred names and legacy names, yet
are rendered as the same. Something can be fixed there.

The OT 1.5 specifications added two more nameID to support these
non-CSS variants, or non-weight-width-slope (non-WWS) variants, to
make it easier by splitting them into different font families. But
that will only take place in future fonts. People need to be able to
use today's fonts today.


Denis Moyogo Jacquerye

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]