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
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.
Some of the fonts that came with CorelDRAW have small caps and swash variants; I can send them if you'd like.
I wrote this inquiry because Richard was under the impression that perhaps we are searching for an issue of fonts actually not showing up on other systems (works fine on Windows for us), but based on my own impression of the bug, my own testing, and your confirmation, I am sure we are only talking about a UI issue at this point. Solving this is not so terribly difficult, as outlined in an email last week; we only need to set up our own rules for separating font family name and style to determine the actual variant. This is the direction I have been taking thus far.
Gail
bulia byak wrote:
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 Monday, July 23, 2007, 10:38:35 PM, Thomas wrote:
TW> Just to recap what we talked about a few weeks ago: currently (0.45.1, TW> Linux) any font variant names not in the very limited CSS standard usually TW> (though not quite always) *DO* now appear in the UI. However, they can not TW> actually be used. If one of these variants - say, "shadowed" in Gill Sans TW> - is selected the font actually rendered will just be the plain font. In TW> the cases where the variant name is a compound - eg "Ultra Bold Condensed" TW> - then only those parts which are recognised by the system will be used to TW> select the font, in this case "Ultra" will be ignored but "Bold Condensed" TW> will be rendered.
(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
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.
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
participants (4)
-
bulia byak -
Chris Lilley -
Gail Banaszkiewicz -
Thomas Worthington