On 7/23/07, Gail Banaszkiewicz <gbanaszk@...1686...> wrote:

At first it sounds as though fonts are actually not showing up at all for some platforms, but I'm wondering if the problem now is simply that the UI doesn't separate font family and variants beyond what CSS allows (so no small caps, outline, swoosh, etc).

My comments in that bug were done long ago. Since then, the entire text system was reworked completely at least twice, once by Fred and then by Richard. So if I wrote there that displaying all styles in a family works, it does not mean it really does now. My impression is that in SVN, all you can ever see in the styles list is the 4 standard styles (normal, bold, italic, bolditalic). But really, the best you can do is to test it :) Do you have font families with many non-standard styles? If not I can send you some.

On Mon, 23 Jul 2007 18:12:22 +0100, Gail Banaszkiewicz <gbanaszk@...1686...> wrote:

Hi everyone, I just wanted to clarify what exactly the problem described in this bug is:

904962 (http://sourceforge.net/tracker/index.php?func=detail&aid=904962&grou...)

At first it sounds as though fonts are actually not showing up at all for some platforms, but I'm wondering if the problem now is simply that the UI doesn't separate font family and variants beyond what CSS allows (so no small caps, outline, swoosh, etc).

If you can shed any light (and I bet bulia can at least), it will be much appreciated.

Thanks, Gail

That bug report looks familiar but I think things have changed a little since then.

Just to recap what we talked about a few weeks ago: currently (0.45.1, Linux) any font variant names not in the very limited CSS standard usually (though not quite always) *DO* now appear in the UI. However, they can not actually be used. If one of these variants - say, "shadowed" in Gill Sans - is selected the font actually rendered will just be the plain font. In the cases where the variant name is a compound - eg "Ultra Bold Condensed" - then only those parts which are recognised by the system will be used to select the font, in this case "Ultra" will be ignored but "Bold Condensed" will be rendered.

I'd really like to stress here that from a professional design point of view, the CSS standard is totally inadequate for text designs. There is nothing remotely typograpically unusual about "Ultra Bold Condensed", "Heavyface", "Extended #2", or any of the other dozen or so varients I see every day which have no CSS equivalent. Only very limited professional work on, for example, product labels, can be carried out using just the CSS font parameters. They should be regarded as a crippled "Are you sure you want to save using only CSS font styling"-type-of-feature and not an end point by any means.

Also, for some fonts (and I've not worked out the pattern as to which it is) styles which are not recognised seem to appear as repeated instances of the last recognised style. For example, my Adobe Jenson Pro lists "Regular" nine times, then "italic" nine times, then "bold" nine times, and then "Bold Italic" nine times. Each of these can be selected and does indeed produce the named variant.

Thomas

On Tue, 24 Jul 2007 14:50:34 +0100, Chris Lilley <chris@...157...> wrote:

(This is related to an implementation, not to what CSS can do).

TW> I'd really like to stress here that from a professional design point of TW> view, the CSS standard is totally inadequate for text designs.

Thats probably true, although the example you use to show it does not demonstrate that.

TW> There is TW> nothing remotely typograpically unusual about "Ultra Bold Condensed", TW> "Heavyface", "Extended #2", or any of the other dozen or so varients I see TW> every day which have no CSS equivalent.

Note that CSS can indeed describe a font which is ultrabold and condensed. The font-weight is probably 800 or 900 and the font-stretch is, well, condensed.

http://www.w3.org/TR/CSS2/fonts.html#font-styling

I really meant that the standard nomenclature of CSS is not expansive enough to be able to handle all the arbitrary names used in typography (old-style is an obvious ommision that's become very fashionable recently). It is certainly possible to set up a translation system from standard font naming to CSS naming/defining, but it is futile to think that this can be done for every case or that all the cases for which it can be done constitute a useful working sub-set for even quite ordinary typographical work. As such, the CSS representation of the fonts in a document must be regarded as one which will discard information and should not be the internal method of representing font variants.

To put it another way, if the names of a font and its variants are obtained from the OS then those are the names that need to be stored and used in the document unless platform portability is more important than having exactly the same font (although I can't imagine that happening very often); at that point a translation to CSS or any other standard can be attempted with the usual warnings about possible formating losses.

TW