InDesign users to be extinct like "lead" users, CSS coauthor cries!

joeclark's picture

A YouTube video of a presentation at Google by Håkon Lie and Michael Day has Lie declaring that InDesign users, particularly at newspapers, will soon be so passé they will be more comparable to the old guys who moved “lead” type.

The context is the ability of Prince, a software application, to output a “typeset” PDF from HTML+CSS. (Lie was coauthor of the original CSS spec.) While that claimed capacity was covered in an article I read, then and now my response is “I’ll be the judge of that.” The presenters’ insistence that HTML-CSS-Prince handles “most” requirements (more than 80%) will, I suspect, be antithetical to the real typographers who read this forum. I think we spend rather a lot of time on that other 20%.

howcome's picture

Joe Clark wrote: If I want exactly one weight, style, and width of Thesis, what exact font-family syntax do I use to specify it for all non-braindead browsers?

This is good use case for Web fonts, I believe. Here's some sample code that will tie a set of descriptors to one unique URL:

@font-face {
  src: url(http://www.example.com/thesis-smallcaps-whatever);
  font-family: "mythesis";
  font-style: italic;
  font-weight: 500;
  font-variant: small-caps;
}

And here is one way to refer to it from the shorthand 'font' property:

h2 { font: 500 italic small-caps 16pt/18pt "mythesis" }

Thomas Phinney's picture

> This is good use case for Web fonts

Surely it ought to be possible, for any font present on the user's system, to specify that font unambiguously.

Howcome points us to section 15.4.2, the "Full font name."
The "discussion" cited starts to scratch the surface of the problem, but doesn't actually try to solve it, not does it fully expose the complexity of the problem.

Even within a single platform, a given font can have multiple strings that have a legitimate claim to being the "full font name." Saying that the browsers should just defer to the OS is useless given that HTML and CSS are supposed to be cross-platform. I'm also of the understanding that most platforms can access multiple plausible strings for any given font.

Cheers,

T

howcome's picture

Thomas Phinney write: Saying that the browsers should just defer to the OS is useless given that HTML and CSS are supposed to be cross-platform.

One possible solution is to require all CSS implementations to open font files directly and not through the system. In this principle is established, the CSS specification could go on to describe, in some detail, how to map information from all major font formats into values suitable for selection by the 'font-*' properties.

Would this solve your problem? Do you see other solutions?

howcome's picture

I've posted a proposal on how to extend the 'font-variant' property to select alternate fonts here:

http://lists.w3.org/Archives/Public/www-style/2008Jan/0380.html

Thomas Phinney's picture

Howcome: Well, that would do it. I'm not sure it's necessary to *require* the CSS implementation to access the font files directly. I imagine it would be sufficient to specify precisely what processing applied to what bits of data in a font gets the desired result. Then if this info can be had from the OS, great, but if not, the CSS implementation will have to handle it.

Cheers,

T

howcome's picture

Thomas Phinney wrote: I imagine it would be sufficient to specify precisely what processing applied to what bits of data in a font gets the desired result.

And what should those rules be? That is, for a given font x, how do you find the string x' that can be used as a value on 'font-family'?

Mel N. Collie's picture

Thomas:: "a given font can have multiple strings that have a legitimate claim to being the “full font name.”
You're close enough now to see how hopeless it is to imagine a font's name containing all the information required, for any system or human, which needs to make font selection "'work', perhaps.

As Howcome says::
font-family: "mythesis";
font-style: italic;
font-weight: 500;
font-variant: small-caps;
...leaving out a few things from 'above', now being handled by the OS,, and a few things from 'below', not now available to the web designer, is that really the best you can do!? This one myth esis (sorry), is going to function properly every place it is called to perform? Since this is not good enough for everyone, everywhere, I'm waiting for you to set out on a much longer string of variables I 'ordered.'

Cheers!

joeclark's picture

Håkon’s proposal is a good start from a nonexpert. But it still doesn’t let me choose TheSansB HT6 SemiBold with tabular ranging figures and alternate single-storey a.


Joe Clark
http://joeclark.org/

howcome's picture

joeclark writes: Håkon’s proposal is a good start from a nonexpert.

I'd be happier without your compliments, Joe.

But it still doesn’t let me choose TheSansB HT6 SemiBold with tabular ranging figures and alternate single-storey a.

You can do all but the single-storey a. In general, CSS cannot apply styles to characters, only to elements. So, we need to find property values that can be applied to the whole element without causing unwanted side effects.

I assume this code:

p { font-variant-storey: single }

would be too general as it would apply to 'g' as well. Another option would be to introduce the functional notation which is used for some values:

p { font-variant-storey: single(a) double(g) }

In order to justify the cost it would be to introduce, specify, implement and test this feature we need to learn more about multi-storey characters. How many characters come in multi-storey varieties? In cyrillic? Other scripts? How do fonts label these alternates? How consistent is the labelling? Do font APIs offer this information to applications? Across all platforms?

k.l.'s picture

Håkon's proposal is a good start from a nonexpert. But it still doesn't let me choose TheSansB HT6 SemiBold with tabular ranging figures and alternate single-storey

Hi Mr Clark. Well, what could be better than directly referencing the font file, as suggested earlier by Mr Lie,

   @font-face {
      src: url(http://www.example.com/thesis-smallcaps-whatever);
      # additional properties which in combination identify this font

because: If you got a bunch of PST1 fonts which make stylistic alternate glyphs available in separate fonts (= styles), and if these separate fonts are identified by strings/abbreviations in the fonts' file name and menu names, and if the latter strings/abbreviation moreover are foundry-specific -- how please should CSS be able to identify the correct font by just looking for "two storey g" in any font variant?
Let's assume that CSS would support the 20 Stylistic Set features, it would not know more about them than their names: "Stylistic Set 1", "3", "6" etc. Neither applications nor CSS can know what each does. Alternate g is of that category. Unless there's a registered feature dedicated to one- or two-storey a's and g's, your example is a bit unrealistic. I think you expect more from CSS than even OT specs offer.  ;-)

Mel N. Collie's picture

"How many characters come in multi-storey varieties? In cyrillic? Other scripts? "
The need for alternates has simply never come up in any of the hundred or so client dealings I've had on this topic. It is similar, in my opinion, to concern for the adjustment of ones rear view mirror, after one has driven the car off of a cliff. As if, anyone would be following.

Though, I'd like to have the options capable of specifying type down to the smallest detail, alternated are simply not where to start. Without the option of a controlled pixelation, down to the exact x, y, and d of the type, kerning, tracking, alternates, ligatures, justification, hyphenation, leading, optical sizing, and to some extent, style selection, are just adding mud to the swamp, in text, and much display type as well. . .

Cheers!

joeclark's picture

dberlow, thank you for giving us the benefit of your experience, which I assume you intend to trump other people’s use cases and requirements.


Joe Clark
http://joeclark.org/

BlueStreak's picture

In DBerlow's defense, it seems that some of the argument here is that to add anything, Howcome must cover everything and every possible scenario — that's just not fair.

joeclark's picture

Or we could just conclude that CSS is incapable of character-level typography (and intercharacter).


Joe Clark
http://joeclark.org/

John Hudson's picture

Joe: Or we could just conclude that CSS is incapable of character-level typography (and intercharacter).

But so have been a heck of a lot of 'typesetting' technologies. Linotype non-kerning f, anyone?

The trouble with something like your single-storey ɑ use case is that this kind of variant is very much font-specific and always has been, and even if one were to construct a general mechanism for 'storey variants', as Håkon imagines above, one is still going to be left with dozens of other kinds of design-specific variants that fall between the cracks of such a mechanism, that do not correspond to an anticipated variant class and specified property. In typography as in linguistics there are 'free variables', and these basically require the equivalent of that earliest of typesetting technologies: the case of individual sorts from which the typesetter can grab the appropriate form and insert it in the composing stick. Adobe's glyph palette is the most direct equivalent, but OpenType stylistic alternate layout features are only one level above this and not much easier to address in terms of cross-font behaviour and, hence, generalised mark-up.

howcome's picture

Thanks to all who have provided feedback in this forum. My tentative conclusion from our discussions is that referencing fonts in CSS is not «fundamentally broken», but that new variants in OpenType font warrants some new keywords on the 'font-variant' property. It also makes sense to split out individual properties along the lines of this proposal:

http://lists.w3.org/Archives/Public/www-style/2008Jan/0380.html

but the exact list of keywords can't be determined quite yet; it will depend on availability of fonts, and feedback from implementors.

I've enjoyed the discussions and look forward to more. Meanwhile, I'll try improvove support for fonts in the two products I'm involved in:

http://www.opera.com/
http://www.princexml.com/

Cheers,

-h&kon
http://people.opera.com/howcome

aluminum's picture

Thanks for working on that!

Miguel Sousa's picture

> My tentative conclusion from our discussions is that referencing fonts in CSS is not «fundamentally broken»

When Thomas used the expression «fundamentally broken» I think what he had in mind was that with CSS it's easy to reference a font that is part of a small family (e.g. font-family: Arial; font-style: italic; will get you Arial Italic), but when the font family has more than the usual 4 styles (Regular, Italic, Bold, Bold Italic), like Minion Pro or Myriad Pro for example, then referencing a specific font is no longer easy. And it gets even more complicated when you try to find a solution that works for all the browsers. Here's an example:

To reference Minion Pro Bold Italic, one would probably use the following code, right?
font-family: 'Minion Pro';
font-weight: bold;
font-style: italic;

If yes, then why do Safari and Firefox display different fonts, like so?

But things can get even more interesting. If one wants to reference Minion Pro Medium Cond(ensed) Italic Display this is the code you'll have to use for Safari,
font-family: 'MinionPro-MediumCnItDisp';
font-style: italic;

and this is the code you'll have to use for Firefox,
font-family: 'Minion Pro Med Cond Disp';
font-style: italic;

in order to get this:

If you don't agree that's broken, then why am I getting different results for the same code, and why do I have to use different code to get the same results? Sure, you can blame the browsers for not be doing the right thing, BUT what is the "right thing"? Which name strings in the font are the browsers supposed to use? Should they just pick-and-choose Name IDs (http://www.microsoft.com/typography/otspec/name.htm) as desired, or should the CSS spec give a clear guidance?

And in the example that tries to reference Minion Pro Medium Cond(ensed) Italic Display shouldn't the code be a lot more straight forward? Something like this, perhaps:
font-family: 'Minion Pro';
font-style: 'Medium Cond Italic Display';

> [...] new variants in OpenType font warrants some new keywords on the ’font-variant’ property [...] but the exact list of keywords can’t be determined quite yet; it will depend on availability of fonts

If by 'fonts' you mean 'free fonts', then that last sentence will be closer to the truth...
Fonts with OpenType layout features *ARE* available, and the keywords *CAN* be determined. The keywords can be based on the features already registered (http://www.microsoft.com/typography/otspec/featurelist.htm), and there are already hundreds of fonts that implement a lot of these features (e.g. Minion Pro, Myriad Pro, the ClearType collection, Palatino Linotype [in Win2000 and up], etc.). This thread has several examples of fonts with OT features: http://typophile.com/node/41231

howcome's picture

«Which name strings in the font are the browsers supposed to use?»

There is no requirement in CSS that browsers look inside the fonts, and noone has argued that they should have to do so. Browsers typically use system APIs to learn about the available fonts. So, it's better to ask system vendors about this, or look to the OpenType specification for guidance. It's outside the scope of the CSS specification.

«why do Safari and Firefox display different fonts?»

I don't know. What system are you using, which versions of the browsers? A good place to ask the question is in the www-style mailing list.

«Fonts with OpenType layout features *ARE* available»

Yes, but most people don't have them. In order to motivate browsers to add features, you must tempt them with lots of potential users. Remember that browsers vendors have hundreds of great ideas to choose from and only so few developers. They are unlikely to add features if only a small subset of users will notice.

John Hudson's picture

Yes, but most people don’t have [fonts with OpenType Layout features].

Anyone with MS Windows Vista or Office 2007 has several font families with typical OTL features for Latin, Greek and Cyrillic text typography. I don't think the problem is lack of potential users in terms of numbers of people, but lack of users who understand the potential, and they are unlikely to grasp that potential until they see standardised style mark-up syntax to access the layout features, just as most people wouldn't have understood the potential of CSS without seeing it: you had to invent it and evangelise it.

Miguel Sousa's picture

> Browsers typically use system APIs to learn about the available fonts.

Yes, but it's not just a matter of getting a list of all the fonts available but rather getting an unique and clear pointer to a given font on that list. Yes, it's up to the systems to implement the APIs, but on the other hand it's up to CSS to clearly say what 'font-family' corresponds to. Is it NameID#1 or NameID#16? If NameID#1, then what should be done in case the family has more than 4 styles?

As Thomas said, section 15.4.2 Full font name (http://www.w3.org/TR/1998/REC-CSS2-19980512/fonts.html#aname) only scratches the surface on this matter. There needs to be a clearer guidance from CSS, otherwise 'Full font name' might mean the font's NameID#1 in one browser, and NameID#16 in another, for example.

> So, it’s better to ask system vendors about this, or look to the OpenType specification for guidance.

The OT spec gives absolutely no guidance on this matter. It only describes what each name string is. It doesn't say which names or how many names should be used to get an exact (cross-platform & cross-browser) reference to a font. For example, some Adobe applications use NameID#6 in the documents they generate in order to have an unambiguous cross-platform reference to a font, while other apps use other NameIDs.

> Yes, but most people don’t have them. In order to motivate browsers to add features, you must tempt them with lots of potential users. Remember that browsers vendors have hundreds of great ideas to choose from and only so few developers. They are unlikely to add features if only a small subset of users will notice.

I know exactly what you mean as I have to deal with that fact in a regular basis. I wished InDesign had this and that but...

But browser support is not the matter here. Did you give up on the idea of CSS v3 just because no browser was supporting it at the moment? My point is, there's nothing stopping the W3C to specify the keywords now. Or are you waiting for each browser to come up with their own solution and then blame them for not following the spec (that was written *after* the fact)?

OpenType is here to stay, either you want it or not. The sooner CSS embraces it, the better for everyone. XAML already has http://msdn2.microsoft.com/en-us/library/ms745109.aspx Now, shouldn't all those style attributes be implemented through CSS? I think so. Can CSS do it? You tell me...

Dan Gayle's picture

There is no requirement in CSS that browsers look inside the fonts
Forgive me if I'm wrong, but broadly speaking aren't YOU the one suggesting the requirements? If the current requirements do not address a specific and isolated issue, why not address it?

An added benefit of so doing would be a further standardization of naming conventions for Open Type fonts. If all of the foundries know that the CSS spec will call for NameID#6, then all of the foundries will then make darn sure that the NameID#6 string is fully mapped out.

As the subject was originally about CSS specifying server-end fonts, the web designer/programmer will have access to the font files and access to all of the specific name ids associated with them. They could very easily find out exactly what the NameID#6 string is EXACTLY, then spec it up without worry.

The cascade could call for a specified font via the standardized name id, then fall back to a standard web font if some freak occurrence prevents the specified font from downloading and activating on the user end.

I like that idea, because I don't like having to string together an entire set of font properties that are already inherent in a font. Why call for Myriad Pro, but only the condensed version that happens to be an italic variant and only if it's the display weight instead of the file Myriad Pro Condensed Italic Display?

For a Word user, it might make sense. But we as Typophiles understand that every variant is a font in and of itself, not a magically bolder and slantier version of "the" font.

howcome's picture

«There needs to be a clearer guidance from CSS, otherwise ’Full font name’ might mean the font’s NameID#1 in one browser, and NameID#16 in another»

In an ideal world, what would you like CSS to say about this? Could you suggest some text that describes a good solution?

Miguel Sousa's picture

The suggestion below would certainly make section 15.2 Font specification a lot more clear, IMO.

font-family: Microsoft platform string NameID 1, from 'name' table (http://www.microsoft.com/typography/otspec/name.htm)

font-style: fsSelection, from 'OS/2' table (http://www.microsoft.com/typography/otspec/os2.htm#fss)

font-weight: usWeightClass, from 'OS/2' table (http://www.microsoft.com/typography/otspec/os2.htm#wtc)

font-stretch: usWidthClass, from 'OS/2' table (http://www.microsoft.com/typography/otspec/os2.htm#wdc)

So, for example, the font Minion Pro Bold Cond(ensed) Italic Caption could be described in CSS as:
font-family: "Minion Pro Cond Capt";
font-style: italic;
font-weight: 700;
font-stretch: condensed;

This solution would work well for referencing fonts based on the 'sfnt' format, which means all TrueType and OpenType (TT & CFF flavors) fonts. To map the same set of properties to a Type 1 font, some heuristics would be required.

howcome's picture

Thanks Miguel, it's good to have a concrete proposal.

I have a few questions.

If I run this on a linux with the font installed I get:

$ fc-list : family | grep -i 'minion pro cond capt'
Minion Pro,Minion Pro Cond Capt

That is, fontconfig reports two names: «Minion Pro» and «Minion Pro Cond Capt». I assume it gets «Minion Pro» from some other field in the same file, do you know which one?

Let's say the style sheet says:

font-family: "Minion Pro", sans-serif;
font-style: italic;
font-weight: 700;
font-stretch: condensed;

Which font should be selected?

John Hudson's picture

That is, fontconfig reports two names: «Minion Pro» and «Minion Pro Cond Capt». I assume it gets «Minion Pro» from some other field in the same file, do you know which one?

«Minion Pro Cond Capt» is the Font Family name (sfnt name table ID 1). This is the name of the 4-style family which would consist of

- Minion Pro Cond Capt Regular
- Minion Pro Cond Capt Italic
- Minion Pro Cond Capt Bold
- Minion Pro Cond Capt Bold Italic

«Minion Pro» is the OpenType Preferred Family name (name table ID 16) which allows applications to display a single, larger family composed of the 4-style families. The style linking between the members of the 4-style families remains the same, only the presentation to the user differs. The Preferred Family name is used in conjunction with the Preferred Subfamily name (ID 17).

[I think the term 'subfamily' is potentially misleading; this is really synonymous with style and is particular to a single font within the family, not some kind of sub grouping.]

It would be quite nice, I think, if CSS made it possible to specify either the Font Family (ID 1) plus Font Subfamily (ID 2, style) as in Miguel's example, or the Preferred Family (ID 16) plus Preferred Subfamily (ID 17). So the same font, Minion Pro Bold Cond(ensed) Italic Caption, could be spec'd as either

font-family: "Minion Pro Cond Capt";
font-style: italic;

or

font-family: "Minion Pro";
font-style: "Cond Italic Caption";

I don't know how feasible this is.

I presume the secondary properties

font-weight: 700;
font-stretch: condensed;

are only necessary as a fallback mechanism, e.g. if a default serif face is used instead of the specified font, in order to try to match the weight and width?

howcome's picture

This code:

font-style: "Cond Italic Caption";

is not feasible in CSS. The 'font-style' property only accepts keyword values, one of: normal, italic, oblique. The property works interoperably across browsers and changes to it will be resisted.

There is also a keyword-based property called 'font-stretch'. So, you would end up with something like

font-family: "Minion Pro";
font-style: italic;
font-stretch: condensed;
font-variant: caption; /* assuming we add the "caption" keyword */

Should the code above work? Should the code below work? Should they result in the same font?

font-family: "Minion Pro Cond Capt";
font-style: italic;
font-stretch: condensed;
font-variant: caption; /* assuming we add the "caption" keyword */

Miguel Sousa's picture

> I assume it gets «Minion Pro» from some other field in the same file, do you know which one?

It's both Microsoft NameID 16, like John said, and Macintosh NameID 1. Ideally, fonts in a large family will have these two strings match each other. If they don't match, fc-list will output both. The general format seems to be,
MacNameID1,MSNameID16,MSNameID1:style=MacNameID2,MSNameID17,MSNameID2

There's definitely something going on behind the scenes, because fc-list doesn't output all the NameID strings, even if they are present in the font. For example, according to the format above, the font MinionPro-BoldCnItCapt.otf would have been IDed as,
Minion Pro,Minion Pro,Minion Pro Cond Capt:style=Bold Cond Italic Caption,Bold Cond Italic Caption,Bold Italic
but what gets output is just,
Minion Pro Cond Capt,Minion Pro:style=Bold Italic,Bold Cond Italic Caption

And MinionPro-BoldIt.otf outputs as,
Minion Pro:style=Bold Italic
but by the format above it would have been,
Minion Pro,(font has no MSNameID16),Minion Pro:style=Bold Italic,(font has no MSNameID17),Bold Italic

> Which font should be selected?

Currently, the answer varies from browser to browser. I'd say that those properties define "Minion Pro Bold Italic Condensed". The problem with CSS is that it's build on the assumption that fonts in a family only vary by Weight, Width and Slope, which is true for most families but certainly not all. What about fonts that differ only by Optical Size? (Two fonts can have the same WWS, but one is designed to be used at large point sizes --Display--, and the other at small point sizes --Caption). And what about two fonts of the same family that only vary in design? (e.g. Shelley Allegro, Shelley Andante and Shelley Volante). CSS goes a step further than Windows, which differentiates fonts only by Weight (Regular, Bold) and Slope (Upright, Italic), but still falls short of what is necessary for describing a font by its properties.

The thing is, CSS tries to address two different things with the same set of properties. On one hand, the properties have to be as specific as possible so that the desired font(s) get selected. To achieve that we'd only need two properties,
nameOfFontFamily: "Minion Pro";
nameOfStyleInFontFamily: "Bold Italic Condensed Caption"

But on the other hand, the font needs to be described by a set of general properties/characteristics so that, in case the desired font is not available, there's at least enough information to find a close match.

So, the main challenge is probably deciding where one of the operations ends and the other starts, i.e. when should browsers stop trying to find the font that equals the specified properties, and start guessing which font would be the better match.

Personally, I would like to be able to spec my font(s) in a typographic manner like I do in InDesign. That said, it would be great if CSS could provided two additional properties,
font-typographicfamily: MacNameID1/MSNameID16
font-typographicstyle: MacNameID2/MSNameID17

But I understand that is important to provide general properties to describe the font(s); this way browsers don't have to apply heuristics to two name strings in order to find if the font is Bold, Italic or Condensed. Is it possible to combine the two approaches? I think so.

BTW, I experimented writing the CSS code for a few font families, based on my proposal from January 30th, and was quite surprised by the results I got in Firefox. About 85% of the fonts were selected and displayed correctly. One of the families, Kepler Std, was particularly interesting, since it has no less than 168 fonts!!
The results can be found at http://adhesiontext.com/typophile/CSSFontTest/

I must say the results in Safari were very disappointing. This browser seems to prefer the PostScriptName (Mac&MS NameID6), but even with such specific pointer to the font(s), it failed to correctly display many of them. Some of which it couldn't even find. Perhaps there's something broken in the font matching mechanism.

Miguel Sousa's picture

> Should the code above work? Should the code below work? Should they result in the same font?

This code below works, at least in Firefox 2.0.0.11 Mac. You can see it at http://adhesiontext.com/typophile/CSSFontTest/Firefox/MinionPro/ It's the 5th font in the list.

font-family: "Minion Pro Cond Capt";
font-style: italic;
font-weight: 400;
font-stretch: condensed;

> font-variant: caption; /* assuming we add the "caption" keyword */

The optical size should not be seen as a variant in the same category as Small Caps or Ligatures. (Yes, there's the 'size' OpenType feature which is to be used for controlling the Optical size, but that feature has an unique format and it looks like it was shoehorned into the GPOS table)
I see the Optical size as a font property at the same level as the font's Weight, Width or Slope, and therefore it ought to have its own keyword, e.g.
font-opticalsize: 6pt;

The other thing to consider is that, historically, the optical size is an integer value between 6 and 72 (points). Therefore, the optical size shouldn't be defined as a finite set of names such as Caption, Subhead or Display. That was Adobe's approach, but there's no reason to do it that way, on the contrary. This system of names was good for educating the users --and even so, the terms are not interpreted the same way by all the users--, but it becomes problematic when new sizes need to be introduced.

John Hudson's picture

(Yes, there’s the ’size’ OpenType feature which is to be used for controlling the Optical size, but that feature has an unique format and it looks like it was shoehorned into the GPOS table)

David Lemon and I have chatted a couple of times about the possibility of deprecating the GPOS size feature, and replacing it with a dedicated 'size' table. I suppose extending the OS/2 table would be another option. I'll bring this up on the OT list, since spec updates are currently under discussion.

I agree with your comments re. integer point sizes rather than names. However, one of the virtues of CSS is that it can produce dynamically scaleable layouts, so rather than having authors spec a particular optical size, I would much rather see browseres interpreting the CSS and then delivering an appropriate optical size of font, if available in the family, based on size, resolution and a 'size' feature or table entry. I suppose having explicit font-opticalsize syntax would be useful if one wanted to override the automatic size selection, but the first order of business should be to get the latter working properly.

Mel N. Collie's picture

Miguel Sousa: "The other thing to consider is that, historically, the optical size is an integer value between 6 and 72 (points). "

And yet another thing to consider is that historically, optical size has been defined by an integer value, by a range of values, and by values and/or ranges for given distance, and/or output devices at said size or range...

Cheers!

Nick Shinn's picture

Foundries could specify nominal optical sizes, but art directors should be able to adjust/subvert that.
Bell Centennial, Griffith Gothic and Freight Micro have some life as display faces.

I always found the Quark XPress tracking table/graph very useful; something like that would be good in a layout app, so that the typographer could specify which optical variants to use at which sizes.

Maybe even give the end reader a control.
This could be compared to the Mac's "Font Smoothing" system preference controls, or perhaps somewhat like the Photoshop menu item for "smoother/sharper/stronger" type rasterizing.
Implemented as browser buttons next to the "increase/decrease font size" size buttons.

Thomas Phinney's picture

Just to follow up on Miguel's comments:

The CSS model is that within a "family" fonts should differ only on weight, width and slope.

The typographic reality is that within a "family" fonts differ on these metrics, on optical size, and additionally on arbitrary other variables indicated by arbitrary text strings in the name of the font style.

Sure, the proportion of the world's fonts that can't be handed by adding optical size to weight, width and slope is less than 10%. But even 5% is a fair bit. And the omission of optical size makes it close to 10% of the fonts in Adobe's type library that don't fit the CSS model.

Cheers,

T

John Hudson's picture

The CSS model is that within a “family” fonts should differ only on weight, width and slope.

So a CSS 'family' = a Windows 'family'.

That's not so bad then, because it is a situation we've handled as long as TrueType has been around. Use

font-family: = name table ID 1
font-style: = name table ID 2

just as you would in a Windows font menu.

Miguel Sousa's picture

> So a CSS ’family’ = a Windows ’family’.

That's only true on Vista, I think. On other Windows versions, ’families' are only differentiated by weight and width. Otherwise "Arial Narrow" would be part of the "Arial" family. Or am I missing something?

howcome's picture

«Sure, the proportion of the world’s fonts that can’t be handed by adding optical size to weight, width and slope is less than 10%. But even 5% is a fair bit. And the omission of optical size makes it close to 10% of the fonts in Adobe’s type library that don’t fit the CSS model.»

All of Adobe's fonts fit into the CSS model:

@font-face {
  src: url(http://www.example.com/thesis-optical-whatever);
  font-family: "mythesis" }

h1 { font-family: "mythesis" }

howcome's picture

«However, one of the virtues of CSS is that it can produce dynamically scaleable layouts, so rather than having authors spec a particular optical size, I would much rather see browseres interpreting the CSS and then delivering an appropriate optical size of font»

I agree.

howcome's picture

«So, the main challenge is probably deciding where one of the operations ends and the other starts, i.e. when should browsers stop trying to find the font that equals the specified properties, and start guessing which font would be the better match.»

Font matching is described in some detail in CSS:

http://www.w3.org/TR/2007/CR-CSS21-20070719/fonts.html#algorithm

As I see it, the problem is not in the algorithm itself, but in the input to the algorithm. What is the name of a font family? Is it «Minion Pro Cond Capt», «Minon Pro», or both?

Miguel Sousa's picture

> All of Adobe’s fonts fit into the CSS model:

@font-face {
src: url(http://www.example.com/thesis-optical-whatever);
font-family: "mythesis" }

h1 { font-family: "mythesis" }

What about fonts on the user's system? Do we need to hardcode the path to those as well, in order to get access all the fonts in the family?

Is referencing fonts by their file name really a solution? How is that data used for font-fallback?

Miguel Sousa's picture

> What is the name of a font family? Is it «Minion Pro Cond Capt», «Minon Pro», or both?

It depends whom you ask. If it's a Windows system, the font family will be «Minion Pro Cond Capt». That's because a Windows-family can only have up to 4 fonts, so the "Minion Pro" family had to be broken into sub-families of up to 4 elements.
If you ask a Mac system, the font family will always be «Minion Pro», independently of how many elements the family is composed of.

That's why MSNameID1 ≠ MacNameID1, for font families with more than 4 elements*. In these cases, two more Microsoft platform name strings are added to the fonts, MSNameID16 and MSNameID17, so that you get,
MacNameID1 = MSNameID16
MacNameID2 = MSNameID17

* MacNameID1 = MSNameID1 in one of the Windows sub-families

Miguel Sousa's picture

So for example, the "Minion Pro" family, which contains a total of 64 fonts, is divided into 24 Windows-families:

1. "Minion Pro"
-- contains: "Minion Pro" (Regular), "Minion Pro Italic", "Minion Pro Bold" and "Minion Pro Bold Italic"
2. "Minion Pro Capt"
-- contains: "Minion Pro Caption", "Minion Pro Italic Caption", "Minion Pro Bold Caption" and "Minion Pro Bold Italic Caption"
3. "Minion Pro Subh"
-- contains: "Minion Pro Subhead", "Minion Pro Italic Subhead", "Minion Pro Bold Subhead" and "Minion Pro Bold Italic Subhead"
4. "Minion Pro Disp"
-- contains: "Minion Pro Display", "Minion Pro Italic Display", "Minion Pro Bold Display" and "Minion Pro Bold Italic Display"
5. "Minion Pro Med"
-- contains: "Minion Pro Medium" and "Minion Pro Medium Italic"
6. "Minion Pro Med Capt"
-- contains: "Minion Pro Medium Caption" and "Minion Pro Medium Italic Caption"
7. "Minion Pro Med Subh"
-- contains: "Minion Pro Medium Subhead" and "Minion Pro Medium Italic Subhead"
8. "Minion Pro Med Disp"
-- contains: "Minion Pro Medium Display" and "Minion Pro Medium Italic Display"
9. "Minion Pro SmBd"
-- contains: "Minion Pro Semibold" and "Minion Pro Semibold Italic"
10. "Minion Pro SmBd Capt"
-- contains: "Minion Pro Semibold Caption" and "Minion Pro Semibold Italic Caption"
11. "Minion Pro SmBd Subh"
-- contains: "Minion Pro Semibold Subhead" and "Minion Pro Semibold Italic Subhead"
12. "Minion Pro SmBd Disp"
-- contains: "Minion Pro Semibold Display" and "Minion Pro Semibold Italic Display"

13. "Minion Pro Cond"
-- contains: "Minion Pro Cond", "Minion Pro Cond Italic", "Minion Pro Bold Cond" and "Minion Pro Bold Cond Italic"
14. "Minion Pro Cond Capt"
-- contains: "Minion Pro Cond Caption", "Minion Pro Cond Italic Caption", "Minion Pro Bold Cond Caption" and "Minion Pro Bold Cond Italic Caption"
15. "Minion Pro Cond Subh"
-- contains: "Minion Pro Cond Subhead", "Minion Pro Cond Italic Subhead", "Minion Pro Bold Cond Subhead" and "Minion Pro Bold Cond Italic Subhead"
16. "Minion Pro Cond Disp"
-- contains: "Minion Pro Cond Display", "Minion Pro Cond Italic Display", "Minion Pro Bold Cond Display" and "Minion Pro Bold Cond Italic Display"
17. "Minion Pro Med Cond"
-- contains: "Minion Pro Medium Cond" and "Minion Pro Medium Cond Italic"
18. "Minion Pro Med Cond Capt"
-- contains: "Minion Pro Medium Cond Caption" and "Minion Pro Medium Cond Italic Caption"
19. "Minion Pro Med Cond Subh"
-- contains: "Minion Pro Medium Cond Subhead" and "Minion Pro Medium Cond Italic Subhead"
20. "Minion Pro Med Cond Disp"
-- contains: "Minion Pro Medium Cond Display" and "Minion Pro Medium Cond Italic Display"
21. "Minion Pro SmBd Cond"
-- contains: "Minion Pro Semibold Cond" and "Minion Pro Semibold Cond Italic"
22. "Minion Pro SmBd Cond Capt"
-- contains: "Minion Pro Semibold Cond Caption" and "Minion Pro Semibold Cond Italic Caption"
23. "Minion Pro SmBd Cond Subh"
-- contains: "Minion Pro Semibold Cond Subhead" and "Minion Pro Semibold Cond Italic Subhead"
24. "Minion Pro SmBd Cond Disp"
-- contains: "Minion Pro Semibold Cond Display" and "Minion Pro Semibold Cond Italic Display"

howcome's picture

«What about fonts on the user’s system? Do we need to hardcode the path to those as well, in order to get access all the fonts in the family?»

CSS2 describes how to refer to locally installed fonts, e.g.:

  src: local("T-26 Typeka Mix"), url("http://site/magda-extra") format("type-1")

So, there's no need for a path. But the spec doesn't say how to get the font name. I think it's fair to ask that the spec gives guidance on this, even if most implementations will go through system APIs to find the font. However, I'm unsure what the spec should say, given that there are several fields with different strings in them. If the font community (that's you ;-) want guidance in the CSS spec, you need to agree on how to find the name of a font.

Dan Gayle's picture

RE:
All of Adobe’s fonts fit into the CSS model:

@font-face {
src: url(http://www.example.com/thesis-optical-whatever);
font-family: "mythesis" }

h1 { font-family: "mythesis" }

If we are thinking within the context of server side fonts/Prince, I think this setup is ideal. We don't have to be concerned about whether or not the target font is not on a user's system, because we're calling it from our own server.

Obviously it doesn't work if we're trying to spec a font that isn't on the end-user's system, but that's not what we're dealing with here.

Dan Gayle's picture

If the font community (that’s you ;-) want guidance in the CSS spec, you need to agree on how to find the name of a font.

It should be easy if we're talking about Opentype fonts. Since each font isn't in a "suitcase" like they are in Truetype or Postscript,(.dfonts excepted), you could just call it by filename (blablabla-regular.otf), couldn't you?

John Hudson's picture

Using filenames is not a good idea, because they are not necessarily static. If a font is something that is fairly frequently updated, e.g. a custom font for a publisher that is expanded with new glyphs to cover the typesetting needs of new books, then it isn't unusual for the font file name to include some kind of version or build reference.

As I understand the recent comments (thanks Thomas and Miguel for pointing out my misreading), the CSS notion of a font family is slightly larger than that of a Windows (non-WPF*) 4-font family, adding width to Windows' weight and slope. The OpenType family concept is essentially open-ended.

* On the subject of WPF, it seems to me that many of the issues we're talking about here with regard to font selection have already been given a lot of thought by Mikhail Leonov and David Brown, and their white paper on the WPF font selection model (PDF download link) might be worth re-reading about now. The WPF concept of family seems to be pretty much identical to that of CSS, including weight, width and slope properties.

Dan Gayle's picture

Using filenames is not a good idea, because they are not necessarily static.
You forgetting that we're controlling things server-side. We KNOW what the filename is. We don't have to guess. And if WE update the font, WE can update the link to the file, version or build reference included.

But I think that this requires two different sets of font specifications depending on intention. One for user-side font specification, like we currently have, and the new server-side specifications like has been discussed.

Etan Wexler's picture

Font selection model used by Windows Presentation Foundation: description and guidelines. (John Hudson’s link doesn’t lead where one would expect, given the text in the starting anchor.)

Syndicate content Syndicate content