Uh, yepp. We spend way too much time on that 20% CSS doesn't handle particularly well. Sorting out formatting problems in webpages designed with CSS has long been a major time waster for me. It's just plain deadline-threatening. CSS's failings are typical of the developmental bungling the W3C are reknown for. The fact I'd rather have a new biro should tell you everything. Also try: eating glass.

Thanks for the link Joe :^)

j a m e s

The guys at the W3C always say the cutest things when they pull their heads out of their asses long enough to talk.

"will soon be so passé"

Well, I didn't hear him say 'will soon be', so, I would have to say that I think it's certainly plausible that at some point, yea, this will be the way to go...especially for publishing entities that need to publish massive amounts of content to multiple media.

"The guys at the W3C always say the cutest things when they pull their heads out of their asses long enough to talk."

No matter how evil some folks think the W3C is, I'll take them any day over 'standards' dictated by Adobe and Microsoft.

I don't think they're evil Darrel, but misguided, and compromised by the commercial interests which decide what directions the steering committee recommends. That committee is made up of professionals from Mightgosoft and Abode, and the W3C itself is funded by massive contributions from them and other software companies involved in the business of making crummy software.

I'm equally critical of the 'standards' pushed by MS and Adobe. Their software blows goats. What WC3 delivers is seldom any better. But I hope you're right in saying this is the way to go---provided CSS can be made to deliver what we need it to. Proliferation of multiple media publishing should drive it closer.

j a m e s

Watching the video, I get the impression that Prince is really a print-based 'browser' so-to-speak. In other words, it's a product that actually supports the CSS features that make print design a lot easier that most current browsers either ignore or mess up.

So, that's probably a good thing.

No doubt that the W3C is influenced by corporate entities. I still find that better than just having corporate entities state the standard (not that microsoft and aobobe don't already do that...). ;0)

A print-based browser, yes. That's what it looks like. If it's dedicated to print it might end up handling that medium properly as the de facto standard for CSS, leaving online browsers to catch up.

No doubt that the W3C is influenced by corporate entities. I still find that better than just having corporate entities state the standard (not that microsoft and aobobe don’t already do that...

Beyond question, yes.

j a m e s

Yes, admittedly not “soon.” But he means “sooner rather than later.”

—
Joe Clark
http://joeclark.org/

I like that CSS will get more and more of those features, but I don't get the general point of that talk. They claim that they have invented the perfect way of automatic typesetting, whereas in Word or InDesign there are those sad people doing point and click to get the job done. Haven't they heard that every text and layout application uses stylesheets? And with much better results ...

And about web fonts: I like the fact that they try to push it, but Larabie/Steffmann fonts as the future of web and print? OMG!

And about web fonts: I like the fact that they try to push it, but Larabie/Steffmann fonts as the future of web and print? OMG!

Ah, they're just hedging for the popular angle, something contentious to make people read it. Or maybe they're on a bum steer. I wouldn't take it too seriously.

j a m e s

"but I don’t get the general point of that talk."

I think it was just to show off a particular technology...one that would (in theory) reduce the workload of a publisher that needs to accommodate multiple mediums. Instead of typesetting it for print, then formatting it for the web, you'd do it once, for both mediums, via HTML and CSS.

I think it's definitely more of a 'in theory' thing right now, but I can definitely see hos there is some appeal to this down the road for high volume publishers (such as the newspaper they used in the example in the beginning).

Until the web starts to allow more finesse and control across browsers and platforms, it's hard to imagine one application that can handle both the precision required for print design and the flexibility required by the web.

That said, I know nothing about css. But I do know that for a lot of designers, code is fairly anti-intuitive to work with. I have a background in print (hence Quark, InDesign) and can fumble my way through Dreamweaver because it's aimed at users like me who need to actually see something rather than just write code, but when it comes to html, I leave that to the programmers.

Back in the day, typesetting was done by typesetters, design by designers. The Mac changed all that, now most designers I know do their own typesetting (for better or worse). If the software gets too far removed from the physical act of designing, you'll start to partition things off again. I work with web programmers when I need to get a site done, but I'm not going to want to hire out for my typesetting.

"Until the web starts to allow more finesse and control across browsers and platforms, it’s hard to imagine one application that can handle both the precision required for print design and the flexibility required by the web."

Well, I think that's the intent of this particular application.

"But I do know that for a lot of designers, code is fairly anti-intuitive to work with. "

CSS isn't really more complicated than understanding proper styles in XPress or Indesign.

Getting CSS to work PROPERLY in browsers takes some work, but the appeal of this Prince application is that it seems to fully support CSS *as intended*. Which is rare, unfortunately.

So I wonder which major newspaper will take their workflow from Quark to CSS.

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%.

True, but that doesn't necessarily influence the dominance of production tools and workflows. Quark Xpress managed to grab most of the page layout market for a long time while supporting somewhat less than 80% of typographic sophistication; indeed, so much less that Dean Allen used to call it anti-typographic.

What I think the non-coders are missing is that a lot of the design we are doing now IS XML-based, or approaching it. For instance, although not a design program, Microsoft Word now uses XML.

XHTML and CSS is XML, so we shouldn't be too far off from having a design program that can automatically spit it out properly encoded text. No programming required.

The issue is having a comprehensive enough CSS specification that covers more than the 80% of what we're talking about. IF, and it's a big if, we can get the specification to reach at least the level of sophistication of say, Pagemaker, that's a lot of design that can be accomplished.

Yeah, but you’re doing it wrong if you start with styled text in an unpublished format (like MS Word, Quark, or InDesign) and then try to output to HTML. Your result will be tag soup and will be unusable on any modern site.

I have had more-than-satisfactory results with a workflow of valid HTML → MS Word → InDesign → tagged PDF. I start with and end up with published, accessible formats, and one of the intermediate formats lets me twiddle with typography and page layout to my heart’s content. (It bothers me that InDesign cannot simply inhale a valid [X]HTML file directly.)

I feel I am reasonably informed on the topic and I am pretty sure that even Prince would not do what I want. Typesetting a single page that varies its number of columns is punishingly difficult in CSS yet readily achieved in InDesign, for example. Then there are the issues of ligature substitution, swash characters, and real H&J. (Hyphenation is rather glossed over in the video; it’s viewed as being present or absent. I would like to know how I prevent a word from being hyphenated in Prince, for example.)

Even if John is right, the baseline has been raised. For Prince to achieve 80% of InDesign is a much taller order than PageMaker’s achieving 80% of whatever came before it. (And if that was 80% of the crapola CompuGraphic photosetters I worked on, well, how hard was that?)

—
Joe Clark
http://joeclark.org/

Am I wrong, or are there not plenty of newspapers and magazines still using their own custom developed page layout systems designed to coordinate out put with invoicing systems for ad space? Something Quark and Indesign didn't do before, and something I don't quite see CSS handling. The applications I know best are for making signs, and they can track inventory, billable hours, etc. and spit out an invoice when you are done. I imagine a newspaper publisher would expect nothing less. Does CSS do that and if it does, is it still a cascading style sheet?

Also, I hear so many 80% / 20% rules lately... "80% of your problems are caused by 20% of your (whatever)", "80% of you profits come from 20% of your customers (or products, or ideas)", and so on... It just seems to me that if you are going to pick a number and say "up to this point is good and you don't really need the rest", then, don't pick 80%. (82.5% is better. ;o) These rules almost always make it seem as though it's the 20% that you really want.

-=®=-

The CCI system used at the Seattle Times is exactly such a system. It was originally designed to aid the layout of time-intensive, text and ad heavy publications like phone books. It was and is not a typographically advanced system, no ligatures I'm afraid. It handles the bulk of the design work though, since ads constitute the bulk of a paper.

For graphically intense pages without ads, like our Entertainment and Arts Page 1, we use InDesign and Illustrator because we need more control over that final 17.5%

And don't even begin to talk about classified advertising, because my head will explode.

Will CSS handle this? Perhaps a sophisticated enough CSS spec could handle the layout of a dimestore novel respectably, but something as complex as a multi-page newspaper needs to not only be well specified, but also brutally error-free and as steady as a rock.

Which we all know web design/xhtml/css to NOT be. (See Exhibit A, Internet Explorer, any version.)

Sure, this is using proper CSS, but XML/SGML + stylesheets have been used for print for years. Recall being interviewed for a job of this kind in 1996. Technical publisher stored all their content in XML, used stylesheets to output to various paper formats, CDRom, later web.

http://en.wikipedia.org/wiki/XML_Professional_Publisher_%28XPP%29

As a half and half designer/coder, it is an increasing frustration that stylesheets in Quark/Indesign only go so far - you can't instantly rework a document from A4 to US letter, or make all 1st level headings within the 'further information' section of the page blue using stylesheets alone.

"For instance, although not a design program, Microsoft Word now uses XML."

As does InDesign, actually.

Ultimately, it'd be nice to see a company like Adobe embrace a product like this and incorporate it into their own DTP apps.

However, knowing MS and Adobe, they don't really like those open standards and prefer to keep to themselves. ;o)

(To be fair, I think Adobe has been a bit better in this regard than MS has)

"No programming required."

Well, for the record, CSS as it is now isn't really programming. It's just learning a bit of syntax. Really no different than learning prepress terms, or how to bind a book, etc. Just another publishing medium.

"I feel I am reasonably informed on the topic and I am pretty sure that even Prince would not do what I want. Typesetting a single page that varies its number of columns is punishingly difficult in CSS yet readily achieved in InDesign, for example."

Joe, have you used Prince yet? I haven't, but if you do, I'd love your opinion. I agree that for a web browser, using CSS for varying columns is a huge PITA at the moment. Prince, however, seems to actually support CSS-3 fully, which DOES allow for columnar layouts. One example: http://developer.mozilla.org/en/docs/CSS3_Columns

I agree, this is not a replacement for InDesign now. I am thrilled by the potential it has down the road, though.

"I know best are for making signs, and they can track inventory, billable hours, etc. and spit out an invoice when you are done. I imagine a newspaper publisher would expect nothing less. Does CSS do that and if it does, is it still a cascading style sheet?"

I have no answer for that (though would love to hear one). But, to add to the topic, it seems as if most successful papers are moving a lot of their ad revenue towards their online existence as advertiser depend less and less on the print medium for advertising. So this may very well become a nice addition to, rather than replacement of, current systems. It's been a decade since I've worked in a paper, though (which, at the time, was MS Word, cut and pasted into XPress [and then printed, cut, and waxed onto the keylines...those were the days...] and then cut and pasted into a primitive HTML editor where we published each article manually onto a static HTML site.)

"Which we all know web design/xhtml/css to NOT be. (See Exhibit A, Internet Explorer, any version.)"

Again, Prince isn't a web browser. It's a HTML/XML to PDF renderer. The appeal is that it does support a much fuller set of the CSS spec (especially for print) than any current web browser.

"Sure, this is using proper CSS, but XML/SGML + stylesheets have been used for print for years."

Excellent point. Doesn't Framemaker also use SGML or a subset thereof?

I think the idea, though, is that everyone touches HTML/XML these days, if not a fuller SGML subset. So this product probably hits a few more of the pragmatic buzzwords out there.

At some point there was something called XSL-FO (formatting objects) flying around, with the express purpose of producing fully formatted paginated documents and PDFs from XML.
Does anyone know what happened to that?

"Excellent point. Doesn’t Framemaker also use SGML or a subset thereof?"
Last time I used Framemaker (admittedly, a few years ago) it worked quite well with XML (although it had to translate it into its own native markup). The most impressive thing about Framemaker was its very powerful stylesheet system to which nothing I've seen comes close.

(I believe) We used Framemaker for for classified ads in one of the local papers I worked for. They would output their fully marked-up text, about 12 pages of classifieds, and we would input that into Pagemaker. We had style substitutions set up, so all we had to do was let it flow, ad display ads, then tweak to fit.

Google is barking up an interesting tree, but it's still the wrong one. What I would much rather see is a tool like InDesign that can actually output usable HTML/CSS! Why use CSS for typesetting? Back Asswards.

Outputting a typeset PDF deserves a (one handed golf clap) applause. But getting a decent layout application that works flawlessly is a whole other thing. Writing CSS still requires a developer to sit down and write code. We've gone miles beyond hand-writing Post Script, but we're not there close with HTML/CSS editors. We're 10 years out from the time the original WYSIWYG editors came out (NetObjects, GoLive) and still no serious web developers worth their salt use (or admit to using) WYSIWYG tools because they introduce too much error and require hand-coding. (Modern browser suckage is as much to blame as the people behind Dreamweaver.)

(I realize the term WYSIWYG is probably also passé... but you get my drift.)

> Why use CSS for typesetting? Back Asswards.

Amen. How much professional typography experience do these gentlemen actually have?

professional typography experience

Hey, Once you know what a serif is, some places you get to call yourself an expert.

-=®=-

Once you know what a serif is, some places you get to call yourself an expert.

(Or as someone said to me in Iqaluit, "an 'expert' is someone from South of 60, with slides" (in the days before PowerPoint).

Amazing -- we all agree on something.

I've learned some basic CSS because I had to for a client (to post some of their stuff on a website I did not design in the first place), not because I wanted to. ;-) And as much as I think Dreamweaver is terrifically useful for sketching-out things like tables that can be intricate (WYSIWYG is rather passé, as Joe has noted, although it does have its moments), I find that I still do most of my coding by hand.

But to make a blanket statement like this shows an incomparable amount of ignorance -- heaven forfend, even "lead" users are anything but extinct!

InDesign will go away when printing goes away, which is sooner than people think. Everyone will cry for a while about how good type was in the days of InDesign and "desktop publishing" and lament that "they just don't make 'em like they used to". Then type on screens will get better and everyone will forget, except for a few grey hairs on Typophile :)

Technologies tend to coexist more often then they throttle each other to death.

Christian, do you want to speculate as to a date?

I swear they said the same thing about the "paperless office."

Sometimes you just gotta hold something in your hand.

Technologies usually don't go away completely, but their use tends to become more specialized as they are replaced. The paperless office is actually a good example. Sure we still use printers, and there is still paper around the office, but they are used very differently. Paper now tends to be very temporary. It is almost always a copy of something that already exists in digital form. It may be a handout for a meeting, or a note to be thrown away, but it's rare that people have binders and filing cabinets full of things they intend to keep. More often for that type of thing you hear "can you send me a digital copy?". What's more, that transition is far from over. Offices are still populated by "digital immigrants". The new generation of natives use the technologies very differently, and they certainly aren't printing out everything they read like the old folks.

Another good example of this would be handwriting itself. Whereas handwriting used to be used for everything, it was replaced in large part by printing. It was replaced further by typewriters and morse code. Computers, personal printers and email further relegated it to a niche purpose. Texting and t9 have even replaced it for notes passed under the desk in junior high school. Now it's rare that we use handwriting to communicate with anyone but ourselves, rarely over distances, and almost never archivally. Sometimes it serves a nostalgic or ceremonial purpose, like for handwritten thank you notes.

Interestingly, the same thing happens with words as they are replaced by new ones: the old words take on more specialized meanings.

As for a date where printing will be gone from the face of the earth: probably never. As for a date where it started to fade, just look at the sales charts for paper newspapers, paperback books and annual report design, to name a few. Moving forward the act of stamping ink on paper will likely fill a niche purpose, at best for something useful or artistic, at worst for nostalgia alone. Unfortunately there will be typographic quality lost in the translation (ie that last 20%), especially at first.

Good old 201Clead201D users, how 201Cquaint201D.

Christian, I think there's no doubt that the mix is changing, with more going digital. How far it will go to my thinking depends partly on how good screens get. Have you seen the new Amazon 'Kindle' screen with text on it? I haven't, and I'm wondering if it really is 'digital paper.'

We print things out or buy print on paper when we want to read anything extended. And the preference for readers, probably based on physiology and psychology of reading is for small type--12 pt and under. That means to my thinking that screens won't substitute for paper until there are high resolution screens--at least 300 dpi,and maybe up to 1200. And then, I don't know. As Yogi Berra said, prediction is really hard, especially when it comes to the future :)

"InDesign will go away when printing goes away"

I don't think it has much to do with the medium. InDesign will go away when a proper typesetting tool replaces it. CSS is not it.

"Ah, they’re just hedging for the popular angle, something contentious to make people read it. Or maybe they’re on a bum steer. I wouldn’t take it too seriously."

You are completely wrong there. Håkon Lie seriously claims that such free fonts are "good enough" for general use, and has been working very hard to prevent the adoption of any web font scheme that would work with retail/commercial fonts.

I'm a bit bemused by folks putting down Adobe-promoted standards relating to typography. I take it PostScript, Type 1 and now OpenType have not solved real problems and you didn't like them?

Cheers,

T

Christian, I don't think you have completely argued the notion of "also" away. You have made some great points however. And I don't disagree with them.

Still lingering or malingering does go on. Vinyl sales are up in a big way....

I also think we don't disagree so much as maybe differ over degree of certainty.

And maybe we are thinking about different time scales as well. In 100 years I think we can't hope to imagine what's in store - I think thats the period I was arbitrarily thinking of for whatever reason. But where things will be in 20 years from now... I think you are describing that quite well.

Long term though - I think that at polyform state of existence for text/letters in the far furure is the safest bet of all.

As to the original post, I fail to see the scandal. Forget all the rhetorics (20% vs 80%, death of InDesign), just stick to what he actually presented.*
The presentation makes it clear that Mr Lie is not a typographer, see his selection of 'good' typefaces or the fact that he does not seem much interested in OpenType except for the fancier features. I do not even care since in the more fundamental issues he is pretty right: The HTML+CSS model is (or allows to be) quite strict in separating two independent domains which are, first, structured data, and second, (graphic or typographic) representation of these.

I think that in the long run, typographers will need to think of design in a more structured and abstract way. Designing nice books or brochures manually and individually by placing frames on a virtual page and filling these with given texts or images, is one thing. It is another thing to 'design' design rules -- the actual design results from (automatically) merging data and design rules. This is nothing to be afraid of, it can help make the design process more efficient. And this does not necessarily result in a loss of quality: What did the most traditional book designers do? Define the design rules. See the beautiful sketches by Jan Tschichold or Max Caflisch.
With this in mind, I consider ther HTML+CSS approach as pretty interesting. Another example is DocScape (cannot find an English version). This system allows to program very complex design rules, and one command will merge these with texts and images from any database and generate a PDF of an entire catalog or book. Its developers claim that this is much different from scripting layouts in InDesign or XPress in that these fill fixed template pages or frames with content while in their system the layout by default is supposed to be programmed such that it can deal with texts and images of various length or size, e.g. using two columns instead of three.
'Defining design' rather than 'designing' requires that designers or typographers are able to think of design abstractly.** And to make designers (myself included) feel comfortable with this it needs appropriate visually oriented tools. This is a particularly interesting question for which I have not seen solution. How would such a tool represent a layout, and allow designing it, if there is no 'content' yet? Would it be possible to create such a layout visually nevertheless -- and also show which parts of the layout are fixed and which parts remain variable? In short, how to represent virtual representation of data?
Nobody seems to have made an attempted to address this. Current solutions either force designers to fix text and image snippets on a digital page (PageMaker, XPress, InDesign), or require developers rather than designers (like LiveCycle, can anybody explain this to me in an afternoon?). There is nothing inbetween.

*  I think it was Mr Lie who made an interesting remark in the presentation: The actual typographic representation, which also includes things like hyphenation or optical margin alignment, is not up to CSS itself but to the browser or PDF generator.
**  For this reason, web designers and developers may easier adapt than print designers. Also I am not surprised that all these technologies, PrinceXML, but also AIR and WPF emerged from the web & UI design rather than the print world. My impression is that currently there are pretty exciting things under way, including the above-mentioned technologies. Many of these have the potential to change the way we think of design: By allowing to address document (or print) design, web design, UI design in the same 'language' they may help overcome the strict distinction of these three -- they have more in common than previous design tools (special tools for each of them) suggested. The real distinction is between data and their representation. The same data can be represented in a book or on the screen, or these data may be opend up for manipulation, then the form of representation turns out to be a UI.)

As an aside, it is with more or less automatic design in mind that I think that fonts need to be spaced and kerned well enough that no or very little intervention by the typographer is required. And OpenType helps a lot with this.

Karsten

"Why use CSS for typesetting? Back Asswards."

Not at all. That's the very point of CSS. No different than style sheets in your DTP apps.

"Amen. How much professional typography experience do these gentlemen actually have?"

How much typographical experience do 90% of inDesign users have? ;o)

"I don’t think it has much to do with the medium. InDesign will go away when a proper typesetting tool replaces it. CSS is not it."

CSS isn't a typesetting tool in and of itself. It's style markup language. Consider it like printers marks on the margins of a proof. Given that a lot of content is now being natively stored in XHTML and XML and the like, CSS seems like a perfectly logical extension. Now, whether or not Prince is 'the tool' is certainly debatable, but I certainly see CSS as the future. Rather than XPress styles, InDesign styles, Word Styles, we'd have one standard: CSS. If anything, and if the moons align, we might see InDesign eventually just use CSS natively within the application.

"I’m a bit bemused by folks putting down Adobe-promoted standards relating to typography."

Nothing wrong with [insert big software corporation] promoted standards. It's when they are also solely owned by said entity that some of us tend to start rooting for the open standard instead.

And yea, I can't think of any Type-centric standards that Adobe has created that have been anything BUT a boon to the industry. I, personally, just have qualms about the Adobe vs. Microsoft issues as we go forward in trying to agree on standardization of content storage in general. If you're in a business where part of your requirements is to pump content out to the public at-large, then open HTML begins looking like the best solution. As it is now, one-click exporting from print documents into an easy to publish HTML format is still a bit of a dream for most DTP apps (though, admittedly, a big part of that is simply lack of application user training/knowledge).

As for calling these gentlemen out for a lack of type knowledge, I think that's valid...they are clearly more technology orientated and seem to be focused on a lot of university and scientific documentation (which is the origins of the web). But I don't think that invalidated their vision...if anything, it should be a call to arms to help them improve the product based on the needs of the professional typesetter/designer.

"Still lingering or malingering does go on. Vinyl sales are up in a big way...."

This is maybe for an entirely different thread, but I find that point very interesting. Why is that? Clearly, part of that is the fact that it's a tangible item. Perhaps that's the appeal of Prince for some? It turns the intangible screen of HTML into a tangible book?

"Vinyl sales are up in a big way...."

"Perhaps that’s the appeal of Prince for some?"

Prince was always better on vinyl, purple vinyl in particular.

"Prince was always better on vinyl, purple vinyl in particular."

Ha! Purple Rain was the first LP I ever owned. (I'm not sure if I'm proud or embarrassed of that fact...)

I think the idea of separating content from presentation is very useful and has a huge potential for making information more accessible, but it's not always easy to draw the line between the two...

@Thomas: You are completely wrong there. Håkon Lie seriously claims that such free fonts are “good enough” for general use, and has been working very hard to prevent the adoption of any web font scheme that would work with retail/commercial fonts.

Thanks I didn't know that. I know Ray Larabie's fonts rather well. His free products have no serious problems. But surely there's a taste issue here. Ray's old Larabiefonts catalog is permanently "set" in the late 1990's/2000 era geist. Dieter Steffmann's blackletters I love but have never seen under the hood, and again there is a style issue.

Also, by "popular angle" I was thinking of Manfred Klein's mysterious output, confusing him with Steffmann for a moment.

@Thomas: I’m a bit bemused by folks putting down Adobe-promoted standards relating to typography. I take it PostScript, Type 1 and now OpenType have not solved real problems and you didn’t like them?

I like what Adobe has given us and embrace it whole-heartedly. OpenType allows me to realize some fantastic creative ideas.

W3C's concept of typography and typesetting I find compromised. Its lack of versatility and precision is offputting.

j a m e s

@James: No offense intended to either you or Ray, but I might disagree with you on the quality of his fonts as well. I guess it depends on what you mean by "no serious problems." For my own needs and how I evaluate fonts, >95% of the time I'm holding it to a pretty high standard, and price is only a secondary consideration for me.

I also assume that Ray is making a tradeoff between the quality of his fonts and the quantity/variety they produce (or the time he puts in per font, if you want to look at it that way).

Type designers in general are free to choose something other than the extreme "quality" end of that spectrum. Personally, I'm more interested in typeface quality than quantity, and that's what I'd like to see more of in the world as a whole.

This is all a bit of a diversion from the main topic. i think that the general idea that more and more content is going to be primarily Web based is true. The video in question sensationalizes it a bit, and there are questions about the speed of content migration to the Web. But the general idea is indisputable. I don't think that means either print or InDesign will go away any time soon, though.

Cheers,

T

Thomas, no offense taken. I only meant no serious technical problems in Larabiefonts. Aesthetics and typeface design is of course another matter.
I would love to see Ray make fewer fonts of more artful design, but what Ray does is what Ray does (Ray is as Ray does) and it isn't really my job to decide major content issues for him. I'm more a tweaker of his work and a coach, and a partner he bounces ideas off. He does the same for me.

I also assume that Ray is making a tradeoff between the quality of his fonts and the quantity/variety they produce (or the time he puts in per font, if you want to look at it that way).

There is a tradeoff in the amount of time put into each font in order to maintain the level of quantity Ray turns out. But again it's a matter of what Ray does being what Ray does. It's a question of momentum and keeping the momentum going. He needs to because that's his nature. It has everything to do with continuous creative activity and very little to do with compromising quality in any sense.

The video in question sensationalizes it a bit...

Yes, that's what I was getting at with, "hedging for a poular angle". It's not over until the obese lady sings.

Back on topic...

j a m e s

@Aluminum
If anything, and if the moons align, we might see InDesign eventually just use CSS natively within the application.

THAT's what I'm waiting for. An ideal program would be a combination of Dreamweaver and InDesign, able to organize and simplify stylesheets for complex typography ALA InDesign, but output well-specified valid XHTML + CSS.

That's the day that I am happy, where I can spend my time on the visual end of design, rather than on wondering why the padding on this or that DIV is bumping this column over and breaking under IE.

"That’s the day that I am happy, where I can spend my time on the visual end of design, rather than on wondering why the padding on this or that DIV is bumping this column over and breaking under IE."

Alas, InDesign supporting valid XHTML and CSS won't fix the issues with a particular browser.

The reason css isn't 'precise' is that it'd not designed to be. HTML + CSS is how one typically 'suggests' a visual presentation to the end user. It doesn't dictate it.

The appeal of an app like Prince or a CSS-enabled InDesign is that it would allow you to dictate a layout for that one particular medium...in this case, a PDF. You'd still have valid CSS and HTML that may or may not render exactly as you want in any one particular web browser, but at least you'd have the full control over the PDF you are creating. The valid and portable and semantic HTML+CSS is then just a bonus that makes it easy to slap onto the web.

"CSS and HTML that may or may not render exactly as you want in any one particular web browser, but at least you’d have the full control over the PDF you are creating."

Then why not use InDesign in the first place? :-o There are several other amuzing things about this thread.

"I take it PostScript, Type 1 and now OpenType have not solved real problems and you didn’t like them?"

Thomas, choice in any of the three was not an issue, so WE LOVE 'EM, LOVE 'EM & LOVE 'EM! Do these 'standards' have the guts, balls and smarts to take on the dynamic networked low res typographic requirements of the planet? apparently not. No font format could, that window is now closed. Please proceed to the next window.

"Technologies tend to coexist more often then they throttle each other to death."

Mmmm, this may be true, more elsewhere than in software. One could make a strong case that the T1 and TT technologies throttled each other to death, in the bleak and blurry view of the web honchos at least.

Then of course, what columns fill up with is far more important than the columns themselves. I mean...have shorter and/or justified lines of text ever made it easier to compose badly designed and/or poorly rendered type into 'good typography'? We've all seen fixed columns s'plode on impact when users have the audacity to pick their own type size.

Cheers!

Håkon Lie seriously claims that such free fonts are “good enough” for general use, and has been working very hard to prevent the adoption of any web font scheme that would work with retail/commercial fonts.

That demonstrates how ignorant of typography and good typographic design this original author of the CSS spec, Lie, really is. What an impractical, anti-commercial agenda! Does he, or has he ever, worked as a designer for commerce, doing commercial design for money? Does he understand what drives professionalism and high standards in any design industry? Commercial design is about more than money, its about doing a good job and delivering value for the client's money. The CSS spec makes delivering high quality typesetting impractical. Stop wasting my time.

Shutting out retail/commercial fonts from adoption by any web font scheme is paranoid, nonsensical, unworkable. Come down out of your ivory tower, Håkon Lie. Throw away your bleeding heart prejudices and look at type from the standpoint of quality and the needs of professional users for quality fonts in web-based publishing. You want everybody to adopt your standards, yet you ply them with contempt and mistrust for the makers of high quality fonts.

j a m e s

When I was talking about one thing killing another or not I was thinking of how old computer languages still exist and are quite alive because banks are still using & editing code that was written in the 60's. It's a minor % of the code that's written each year and yet it isn't dead.

However David; your point about context/specificity determining the outcome is a hell of a good one. What may be true for say computer languages which rise & fall quickly but may harbor holdouts, may not be true for how documents are stored, or how bread is made or what happens to ID/text layout.

Being slightly contrary I keep thinking of "Micro brew" beer and how it has not only not been wiped out, but seems to be rising each year at the expense of mass market sudz.

"That demonstrates how ignorant of typography and good typographic design this original author of the CSS spec, Lie, really is."

Does it? The CSS spec really has no care/interest in where a font comes from or the particular license it has. It's not biased one way or the other.

"The CSS spec makes delivering high quality typesetting impractical. Stop wasting my time."

Are we talking about the CSS specification or Prince? The point of Prince is to make CSS practical for print based typesetting.

"Shutting out retail/commercial fonts from adoption by any web font scheme is paranoid, nonsensical, unworkable."

And unless I missed something, nothing to do with CSS. CSS doesn't shut any particular font out.

Now if we're talking about things like font embedding, well, isn't that the idea of the PDF output? Let the PDF take care of that portion.

"It’s a minor % of the code that’s written each year and yet it isn’t dead."

I think we'd be surprised at how much code IS 'legacy' code each year. I had to use up a $50 Circuit City gift certificate yesterday. I was smiling at the fact that their check-out terminal, which is right next to the latest PCs with Vista, Wiis, and all sorts of other 'modern' technology was running a DOS-like terminal application that I'm sure has code circa 1980 in it still ;o)

Anyways, I don't think Prince has anything to do with 'the end of print'. It's specifically designed FOR print.

>I have resisted the trend for years and have no plans to make my EULAs more restrictive.

But with all due respect you don't even mention web based document embedding, Flash, EOT, PPT etc.,

http://www.myfonts.com/viewlicense?lid=359

From the recent survey I did involving foundries and embedding for the web (and Si please assist on this)

30 were surveyed
of these, 12 allowed some sort of embedding
of these, 7 wanted additional licensing

I think there are people who might be willing to pay additional fees. But I say might with emphasis. I think foundries are lucky, and they know it, (in general) to get the first fee for which they ask, let alone additional fees. I do think the larger corporations are different, but how different? I don't know.

An aside. Yes there are many people who upload and download at will. Yes at the end of the day it is, as Adam said, only a theoretical loss. But, I'd be willing to bet that of those who do download many are designers who shouldn't be doing it to begin with. So, it is money lost and it isn't something that can just be chalked up as a theoretical loss. Designers are taking advantage of it and so are taking advantage of the foundries.

What Adam is saying is that if someone is going to steal their font, that person is likely to have already done so. What the foundries are depending upon is the solitary, sometimes institutionalized, consciences of individuals and companies determined to do the right thing. (Or at least, the legal thing.)

Yes, I understand how that works, and how easily you or anyone else who wants to can obtain my fonts for nothing. So I give unscrupulous users less reason to distribute my work illicitly by making some of my fonts downloadable from the authorized vendor (Myfonts) for zero cost, with the option to purchase a license if they want to use it on a paying job and believe in doing the right thing.

In practice, only a dozen or so people each year purchase licences for the fonts I make available with an optional free license. Hundreds more download the free license version and I know (because I've seen the evidence) many of them use the fonts for profit. If I offered the same dual license/try before you buy deal for everything in my catalog, the revenue would not even cover operating costs---I would operate at a loss and probably give up releasing retail fonts.

@sii: But with all due respect you don’t even mention web based document embedding, Flash, EOT, PPT etc.,

(those) Uses not addressed in my EULA are permitted by default of common law. It's a free world. What I don't explicitly prohibit in writing is permitted.

Can we get off the topic of embedding for a while and discuss the otehr aspects of CSS that need to be sorted out please?

Thanks, guys.

j a m e s

So, it is money lost and it isn’t something that can just be chalked up as a theoretical loss. Designers are taking advantage of it and so are taking advantage of the foundries.

Exactly the point I'm trying to make. Thanks Tiffany.

j a m e s

@Dan Gayle: Wow dude, you must be out of the loop something fierce. I, and anyone else, can have all of the major foundries folios in a hop, skip, and a jump via the methods described above by Adam. The facts are simple, if I want your font for free, I can get it.

If it's a font from a "major foundry" you can probably get hold of it easily for free, once you know how. The fact that you and Adam both know how to obtain major commercial font products for free makes me wonder about your professionalism, and that of others, as far as working designers go. Forgive me for making that remark---I am not trying to personally attack anyone here, but citing an example of how faith in wider trust of an industry can be so easily eroded by a few who are in the know (in the loop).

The fonts I make are much, much harder to come by illicitly because they're not as extensively marketed as the products of larger players, so there is less demand for them. That's one reason why I value being an independent and have stayed independent. It's a way of protecting my best interests. Working for a "major foundry" entails a greater risk of having your work knocked off.

Let's move on to CSS formatting and related issues.

j a m e s

@Arbo: ...I understand how that works, and how easily you or anyone else who wants to can obtain my fonts for nothing.

Make that---"how easily you or anyone else who wants to can obtain fonts from major foundries for nothing".

j a m e s

I have not read this whole thread, but I'll throw this out there anyway. Web fonts are thriving in Korea at the moment. Cyworld, the popular Korean website that offered personal spaces on the web years before MySpace, is selling about 25,000 web fonts a day, which amounts to 10 billion won (about 10 milion US dollars) in sales per year.

Users buy web fonts so they can personalize their "mini homepages", bulletin board and forum entries, and email messages on websites like Cyworld and other large network orportal sites. Web fonts are predominantly pixel fonts, and this has been a big part of their success in Korea. Because Korean fonts for print require hangul, with thousands of glyphs, they often require years of work and can be quite expensive. There is not much variety, either. But pixel fonts can be produced in a tiny fraction of the time, and thus hundreds of hangul web fonts have sprung up, produced by traditional type foundries as well as new outfits devoted to web fonts.

I must confess I do not know much about this phenomenon, since my primary interest is in print typography. I've never bought a web font, and I'm not really interested in doing so.

A few quick points... The Korean web environment is different from what you may be used to. Koreans are used to buying a lot of virtual items like personalized avatar elements and items needed for multi-user games. Also, many spend an inordinate amount of time on the large Korean websites that provide the web font services. Finally, none of these web fonts that I've seen are suitable for print, as the vast majority are pixel fonts, and even those that are not are heavily compromised for screen use.

Now THERE's a thought. Bitmap only fonts. That could satisfy a whole lot of people, I would think, for exactly the same reasons you mentioned. Great post.

is selling about 25,000 web fonts a day, which amounts to 10 billion won (about 10 milion US dollars) in sales per year.

Wow! That's great news!

Now THERE’s a thought. Bitmap only fonts.

No, that's really no solution. We already had the hype around (super pixel) flash fonts, but I'm glad that this is going away. That's not the way the web should work.

But why does it have to be a black or white discussion? Lets say you have a font family in 6 weights and 4 optical sizes. You don't need to offer all this with a web license. Just select a single display style or a little font family of 2 or 4 styles, optimize them for the screen and offer only those styles for web embedding. You may not only make profit with those styles, but you will also advertise the whole font family.

Ralf

> The fact that you and Adam both know how to obtain major commercial
> font products for free makes me wonder about your professionalism,
> and that of others, as far as working designers go.

It makes you *worry* about our professionalism? I would think the opposite should be true. I think it wouldn't be very professional of me to talk about an issue that I have no clue of. Sure, there are such people but I don't like belonging to them.

Just like many other colleagues involved in font work, I've been looking at the situation in the piracy world. Whenever a new source of pirated fonts surfaces, or a substantial number of pirated fonts appears in the known channels, I, along with others, inform the respective right owners — some of them take legal steps while others let it roll. I have also helped uncover other kinds of piracy — those when a designer uses other font's outlines to create derivative fonts that he then tries to sell as his own. And of course I have experimented with font extraction from PDF or Flash documents — how else would I be able to advise any of my clients (various font vendors large and small) on its viability.

The nature of my work is font business and technology. My clients pay me to have knowledge and assist them with it when they need it. I think it would be very unprofessional of me if I based my knowledge only on reading the tealeaves.

A.

Ralf, that's a great idea.

If I recall correctly, one Korean foundry, Yoon Design, do something similar. They offer a single weight each of hangul serif and sans faces optimized for the web (spacing, hinting, maybe even bitmaps for common web sizes) for free to those who register on their website. Perhaps it helps in developing brand loyalty and getting users to try out their more extensive ranges of typefaces for print.

>(those) Uses not addressed in my EULA are permitted by default of common law. It’s a free world. What I don’t explicitly prohibit in writing is permitted.

So why do you call out other formats in your EULA?

"(iii) Portable Documents: You may “embed” ST typefaces in PostScript-Language files, .PDF files, .DOC files and .EVY files for distribution, viewing, and imaging to other parties."

@Adam: The nature of my work is font business and technology. My clients pay me to have knowledge and assist them with it when they need it. I think it would be very unprofessional of me if I based my knowledge only on reading the tealeaves.

I am sorry if I implied you lack professionalism Adam. Obviously your line of work differs very much from mine. I'm tuned in to mainly to design and marketing concerns as an indie "foundry", whereas you deal mainly with font technology.

@Sii: So why do you call out other formats in your EULA?

The document is out of date, and I've been lazy and unprofessional getting it up to date. You're complaining about a clause that is permissive in nature, because it specifies some formats and not others. I could update it tomorrow with the recent formats you mention, and webpage embedding and so on, and somebody will invent a brand new document format, making my EULA instantly out of date.

Meanwhile, formats and uses of ST products not covered by the out of date EULA are permitted. I have never had any legal problems or disputes of any kind with any of my clients or purchasers of ST products.

What department do you work in Sii?

j a m e s

I said "I'm not trying to personally attack anyone here", but obviously I lack the professionalism to have put it more clearly.

j a m e s

Si Daniels is the lead program manager for fonts at the Microsoft typography group:
http://www.atypi.org/05_Brighton/25_typetech/40_speakerst/view_person_ht...

A.

Howcome: "First, it’s important that the markup languages of the web are spared from holding all the typographic and presentational information that we want to associate with documents."

We've talked about this offline quite a bit, but, that's how all this started. I mean, the founding papas of the web didn't have the foresight to make all things possible, so they started with no form, only content. Now, where does one draw the line between 'some of the typographic and presentational information' and 'all of the typographic and presentational information'.

Howcome II:"Second, we need ways to express beautiful typography and design for web documents."

The essence of this second thing, expressing beautiful typography, is not possible without the opposite of your first thing: at least the 'option' of a typographic specification specific to the font needs of the user of a web site.

It should be obvious that expressing beautiful typography, other than by image, requires knowledge of 'where' the expression is to take place if the variations are as diverse as those found in the entire web audience. Is that not obvious?

Cheers!

Adam, thanks for pointing to that page about Sii. I wasn't questioning Sii's qualifications but trying to ascertain if he is a legal professional or expert, or if if he specializes in other aspects of the font business.

I take it that none of us taking part in this discussion are legal professionals, and for that reason critiquing legal matters comes down to one peron's professional opinion versus that of the next.

Arbo: The fact that you and Adam both know how to obtain major commercial font products for free makes me wonder about your professionalism

I did mean "wonder", not worry. It's fair to say I worry about people's morality, but that applies to the whole human race. Adam you defended your professional need to know the technical details of outline extraction, which is perfectly professional for your line of work, "And of course I have experimented with font extraction from PDF or Flash documents — how else would I be able to advise any of my clients (various font vendors large and small) on its viability." I wish to point out that I did not question that activity. I wondered aloud about the morality of a person in Dan's position knowing where to obtain illicit copies of major retail fonts. Apologies to Dan too. I was pondering the moral compromise inflicted on designers as an industry by the wonderous digital media revolution and all its foibles.

j a m e s

>but trying to ascertain if he is a legal professional or expert,

Er? Sorry, but I don't follow this line of reasoning. I made the basic point that for ideas (like Hakon's Web font idea) to take root they need to be supported by commercial font makers, and the place they would show this support is in their EULAs (basic or extended). I also observed that font vendors have been going in the opposite direction in recent years clamping down in their EULAs on any technology they perceive (rightly or wrongly) as putting their IP in harm’s way.

Do you need to be a lawyer to make these observations?

James...I think you, and a lot of the industry, is hung up on the whole 'ability to extract outlines' issue of embeddable type.

The reality is, anyone that wants your font illicitly would find taking the time to do that silly, as they could quickly and easily get the source fonts online in a matter of minutes.

So, to go back to the issue of 'web fonts', we probably are over-thinking the 'outlines' issue. We probably don't have to worry too much about the scrapbooking mom using some software crack to extract web based fonts for her 4 year old's birthday party scrapbook. Or, perhaps we do need to worry, but not on the technology side...but rather on the consumer awareness side.

(This system won’t permit nested blockquotes.)

> > First, it’s important that the markup
> > languages of the web are spared from holding
> > all the typographic and presentational
> > information that we want to associate with
> > documents.
>
> I mean, the founding papas of the web didn’t
> have the foresight to make all things
> possible, so they started with no form, only
> content. Now, where does one draw the line
> between “some of the typographic and
> presentational information” and “all of the
> typographic and presentational information”?

I keep being told to be extra-nice to David Berlow, because (I am also immediately thereafter told) he’s been “doing this forever” and none of the rest of us have. But his remark above is nonsense. It masquerades as an expert’s posing an intractable question none of the peons had managed to think of before.

HTML elements have explicit or implied semantics. The most useful distinction, which, contradictorily, is intrinsically presentational, is the classification of elements as either block-level; inline; or, for a rare subset of elements (iframe, del, ins), either. Block-level elements act like paragraphs (notionally, with a carriage return before and after) and inline elements fit inside lines.

These categories are, however, overridable with CSS, as via display: inline and display: block. (That’s how standards-compliant Web pages style navbars – unordered lists, a block-level element – as nice little rows of words you can click.)

Now, in principle every single element in HTML can be styled in other ways, and the other ways germane to this discussion involve font, size, leading, and foreground and background colour. Indention can be styled for some elements. A small number of elements are hard to style (abbr/acronym, q, button, fieldset/legend), but those are due to browser bugs, not flaws in the spec.

In short, then, dberlow, the answer to your question is as follows: The dividing line is right where we’ve been telling you it is all along, between HTML (structure) and CSS (presentation).

Purely presentational elements (not a misprint) like font and center simply aren’t used in standards-compliant authoring. An additional grey area comes up with other purely presentational elements, namely b/i/u, whose application in the context of Web standards used to be debated quite a bit. Now people know that you can use those elements if you are, for example, transcribing a(n) historical text that uses bold, italics, or underline in a way that other elements, like cite, em, or strong, cannot capture. These borderline edge cases do not vitiate the explicit principle, at work every minute of the day on the Web and easily learned by Googling or reading any of a dozen books, that HTML marks up page structure and CSS specifies appearance. This is noncontroversial and it’s tiresome to have to beat this dead horse.

—
Joe Clark
http://joeclark.org/

dberlow: the founding papas of the web didn’t have the foresight to make all things possible, so they started with no form, only content. Now, where does one draw the line between ’some of the typographic and presentational information’ and ’all of the typographic and presentational information’

I don't think web documents should hold any typographic or presentational information. Instead they should link to style sheets that can be reused and cached. The web is diverse and the final presentation should be made as close to the user as possible. There, more information about the user's environment is available, and the presentaion can be optimized on a per-user basis.

dberlow: The essence of this second thing, expressing beautiful typography, is not possible without the opposite of your first thing: at least the ’option’ of a typographic specification specific to the font needs of the user of a web site. It should be obvious that expressing beautiful typography, other than by image, requires knowledge of ’where’ the expression is to take place if the variations are as diverse as those found in the entire web audience. Is that not obvious?

I'm not sure I understand your question. Does your 'where' refer to where in the document? Style sheets languages offer selectors with high enough specificity to address single elements (e.g., #foo in CSS). So, you can create highly customized presentation while maintaining the separation of content and presentation.

joeclark: I would like to know how I prevent a word from being hyphenated in Prince, for example

Here is one way. In your style sheet you have:

.foo { hyphens: none }

In you HTML/XML document you have:

<span class='foo'>Thiswordisnothyphenated</span>.

You can read more about it in the proposed specification, and in the Prince documentation:

http://www.w3.org/TR/css3-gcpm/

http://www.princexml.com/doc/6.0/properties/

DanGayle: I think one problem that you’ll run into when discussing web fonts is that your 5% “good enough for web use” free fonts is in most Typophile’s estimates, 4.9% too high.

Right :-)

Most web users, however, will be happy with the 4.9%. And many will be overjoyed by the remaining 95% as well. For use in headlines, in latin scripts, many of them are suitable. Ransom notes is another use case. I think it's wrong to focus on the quality of current fonts, though. It's like saying the web is a failure because you wouldn't want to read 99.9% of the pages that people publish.

I believe high-quality fonts will be made legally available if browsers learn how to do web fonts. It may be open-source fonts, commercial limited-range fonts, commercial fonts restricted by the 'Referer' HTTP header, or through new business models that none of us have thought of. But it will happen.

>I believe high-quality fonts will be made legally available if browsers learn how to do web fonts.

Is this based on talking to actual font designers? If not do you have any interest in talking to the type design community, say at TypeCon or ATypI?

I’m working on extending the ’font-variant’ propoerty in CSS to better select fonts with OpenType features. Would this be of interest in this forum?

Of course.
Fixing a defect, OpenType fonts containing superior characters could remedy the "extra leading" effect that accompanies reference numbers and the dreaded "th".
Also, true small caps.

Here is a site that uses SVG (Scalable Vector Graphics) to access the contextual alternates in Handsome Pro:
http://culturalcartography.net
Apparently, they had a lot of difficulty with inconsistent implementation by different browsers, so the feature may not work for everyone.
Having OT features available via CSS would be easier than SVG, or the latest Flash capabilities.

Sorry, but I don’t follow this line of reasoning. I made the basic point that for ideas (like Hakon’s Web font idea) to take root they need to be supported by commercial font makers, and the place they would show this support is in their EULAs (basic or extended). I also observed that font vendors have been going in the opposite direction in recent years clamping down in their EULAs on any technology they perceive (rightly or wrongly) as putting their IP in harm’s way.

Do you need to be a lawyer to make these observations?

Nope. You also observed that some document and media formats aren't specified in my EULA, and I responded that that is not restrictive. We are both in effect "lawyering" even tho niether of us are legal professionals. I just wanted to know for certain I got that 100 percent correct, as you are forcing me to give legal opinion on my EULA in a public debate.

Aluminium: James...I think you, and a lot of the industry, is hung up on the whole ’ability to extract outlines’ issue of embeddable type.

Nope, not me. (much laughter) I think it sucks, but I'm not hung up on it. If I was hung up on extraction I wouldn't allow embedding of my fonts in PDF, Word and similar documents.

The reality is, anyone that wants your font illicitly would find taking the time to do that silly, as they could quickly and easily get the source fonts online in a matter of minutes.

Yeah great! (much laughter) What a rude twisted age we live in. I don't call it the "wonderous digital media revolution and all its foibles" because I'm hung up on it. I try to make fun of it instead.

"mew"

j a m e s

>as you are forcing me to give legal opinion on my EULA in a public debate.

Sorry you feel that way. I wasn't intentionally trying to force you to do anything.

@Sii and Howcome
If not do you have any interest in talking to the type design community, say at TypeCon or ATypI?

I think that this is an awesome idea. You could take your presentation to the people necessary to make your ideas work in a non-crappy font way. For instance, if you could convince Mr. Berlow, he might follow through on my "Roger Black custom fonts for magazine website" scenario I joked about above.

Convince the source, the suppliers, designers, and users of fonts, and you effect millions of people worldwide who use web browsers.

Dan "...magazine or newspaper’s website using a proprietary Font Bureau salvaging of an obscure Benton typeface from the early 20th century."

A little late with the idea, a little early with the style. ;

Howcome: "There, [close to the user], more information about the user’s environment is available, and the presentation can be optimized on a per-user basis."

We are on the same track, Howcome, welcome.

Howcome: "I’m not sure I understand your question. Does your ’where’ refer to where in the document?"

My 'where' Howcome is the user environment too. I understand you, Howcome, to be proposing that the name of the font be passed to the network (and little else), installed on the client's machine, and turned over to the OS (and nothing else). That proposal is not, in my opinion, complete to the task at hand and as the OS' continue to diverge in their treatment of 'the same type data', that solution becomes less complete over time.

Besides being of concern to some type folk, your proposal implies that the consortium are not doing everything they can in this regard, nor are operating systems, browsers or foundries. Is this true!? But your proposal's scary to me because I can only 'lend' property in the form of a box of shapes, but not the intellectual property that makes that box of shapes into the words users expected and got, in print.

Some say, I want to break it completely to fix it, but I don't. I want to expand the options from just letting the OS at it (ye olde single outline for the entire planet), to making the final font entirely via network (ye new bitmap for a single user), if required, with all the options in between available, if required (ye olde and new combination outline bitmap stoke font for the user with 4 screens on one desk). That's where we were pre-web and I think I can speak for 500 years when I say "We liked it, and it worked."

It still works, as I've proved for numerous high-end screen font-craving clients, if I have all the answers I need, as opposed to lies, silence or being told I have pay for it.

Cheers!

David,

but notice that the bulk of the web is switching from the idea of a thick server and thin clients over to distributed computing -- simply because the users' PCs have a massive computing power at their disposal, so they can deal with rasterization, scaling, resolution adjustments etc. -- while if you offload all those tasks to the servers, every content vendor will have to invest in massive server and bandwidth technology, and this technology will become usable for rich content vendors only.

What you're proposing is similar to "soft ripping" in prepress times -- the computer would rasterize a document and send a finite bitmap down to the imagesetter, which would then slavishly render the dots. But the industry chose PostScript/PDF, where it would be the receiving devices that would have an intelligent driver that transforms a common interchange format (PostScript, later PDF) into the rasterized image, while the sending part would take care of generating that common code.

The web works similarly now: the sending part (the server) formats the content into an interchange form (HTML+CSS+PNG/GIF/JPG+(soon)TTF) while the receiver (a browser) is an intelligent "driver" that converts this common language into the user space, taking into account things like the resolution and size of the display, the navigational device at hand and other preferences set down by the user.

I think the best personalization/individualization can happen reasonably only at the user's end.

A.

Does dberlow use unparsable syntax and flat-out bad writing to give the impression of deep thought? Because I can’t understand his business at all. That seems to be the intended effect on the reader, come to think of it.

—
Joe Clark
http://joeclark.org/

Tracking.

ChrisL

Adam: "...but notice.." "...offload ALL those tasks...", "..EVERY content vendor..", "...send a FINITE bitmap..."
Not that I'm suggesting billions of streaming bitmaps, 'all', 'every', or 'finite', either but nice knee reflex. Fonts, unlike all other forms of web media don't and won't need the magic of networking ever? Think hard, options are diminishing fast.

"I think the best personalization/individualization can happen reasonably only at the user’s end."
You know my business — for whom do I provide personalization/individualization? and for whom is such personalization/individualization now important? Hmmmm?

Then, on request, and from a city in Ilyria: Clark! What pale and soot soiled light from broken window spews? That mischievous son of Polyphemus must you be, to send streaking such plutonium-laden words. Alighting here as like from a squeaking propellor of the plains, spinning never less true from a garden of weeds, they bounce. Here! look upon thine own father in kind, great in bulk and creased of brow with but with one more eye than this son of accessibility.

Should this sweet-speaking silver-tongued son of proud Palatino, friend of all wordsmiths, the one who made that traveling son of Laertes seem lazy, drop his lofty head to the instruction-littered ground like a hound to sniff at frozen-hearted meaning, or like a raven perch upon thine shaking shoulder to peck at thine ears 'til they become like shining pearls in the cold light of Apollo's fair sister? Nahhh.

And, sorry Dez, unless we 'win' you may effectively only use positive tracking in Billimeters.

Cheers!

What light on yon window breaks that billimeters but tracking takes. Fire burn and cauldron bubble, let measure unit but end the trouble :-)

ChrisL

David,

of course it'll be the client with deep pockets who will come first. Note that even if all the rendering is happening on the user's end after the browser has received the outline font, the content vendor is always free to personalize what he is sending to the user based on receiving such settings as the screen resolution, operating system, the actual browser used and other parameters.

Joe,

yes, David Berlow always writes like Yoda and I think he is on his way to become the most revered Jedi master of typography ever. :)

A.

I'm curious about the end effect of hundreds of different fonts, outline or bitmap, being uploaded onto an end user's computer. Do they stay there indefinitely? Since they need to be active, will that collection of fonts start wearing system resources thin?

And if we're uploading hundreds of different proprietary pieces of software onto a person's computer and asking them to be executed, doesn't that lead down the path to all sorts of viruses, malware, hacking schemes, etc. from the unscrupulous?

Could that "cache" be cleared everytime you quit the browser?

Dan: I’m curious about the end effect of hundreds of different fonts, [] being uploaded onto an end user’s computer
There's a whole lot-o-cachenation goin' on, maybe now font management will be able to evolve, e.g. to disable all but two or three languages if the user wanted not to be swamped with BS fonts from an unused languages, in the interest of being well-swamped with good reading fonts, e.g. One might complain their far eastern junk mail doesn't look so good, but you have to make sacrifices somewhere. I'm not sure what the problem/question would be though, the MS Reader, e.g. installs fonts secretly from the U, they appear to work pretty well, and even if one likes to read, say, 20 newspapers a day, one would not have time to work on much else any way, so how many fonts does one need?

MT:Could that “cache” be cleared every time you quit the browser?
Absolutely. It's had me wondering for a while now, I mean, it shouldn't even take this long to get fonts kicked out of the Millennium Copyright Act Club.

Cheers!

In general the font would not become installed as a system-wide resource. The font would be temporarily enumerated to render the page, and then uninstalled once the user navigates away. That's not to say a rogue font wouldn't cause issues when temporarily installed.

Sii: That’s not to say a rogue font wouldn’t cause issues when temporarily installed.
What issues precisely? The dark side of fonts is the contours, alone, attempting to be all type for all people. If I had to map this, I would put a big red arrow pointing to now, that says, "You are here."

...the most revered Jedi master of typography ever. Dee Be One Claptoni, I presume.
Leave you to complete your journey, I will, to Adamkin Skywalker...or Tward Vader. ;)

Cheers!

oops. Don't you love mixing typesetting commands right into the text? We live in a world ruled by type baboons.

To close your "em" tag, click the 'edit' button at the bottom of the your first entry today. Unfortunately it will then jump later, out of order...

>What issues precisely?

Here's one, a search result on "freetype security"

"Previous versions of the freetype package were vulnerable to an issue whereby a specially crafted ttf file could execute arbitrary code at the permission level of the use running freetype."

http://www.linuxsecurity.com/content/view/130661/

There's also the question of whether or not people would want the fonts. For us, those that choose type from a refined, trained, educated eye, this seems great. But what about the majority of folks who will pick the typeface randomly based on everything BUT the appropriateness of the typeface. I know within months of 'web fonts' being enabled, I'd likely do everything I can to block them on my own machine. ;0)

But maybe the converse is true. Perhaps people would just stop visiting the ugly sites that are using a combination of 12 fonts on one page. Maybe we'd see a resurgence in type appreciation?

David, editing yesterday's posts is completely out of order. Unless you're closing an em, that is.

I'd like to get on with the discussion of how to extend CSS to better select fonts with OpenType features. Before doing so, however, I want to know if we're on the same page.

Thomas Phinney wrote: I agree emphatically with Joe that referencing fonts in CSS is fundamentally broken.

If something is «fundamentally broken» I assume you want to throw it away instead of trying to fix it. What would you replace it with?

FYI, I've done some studies on how different style sheets languages select fonts. They all take the property/value approach:

http://people.opera.com/howcome/2006/phd/#lot

David,

I've encountered OpenType PS (CFF) fonts that caused Windows XP to "blue-screen" and that made Mac OS X 10.3 and 10.4 freeze the app.

A.

>that caused Windows XP to “blue-screen”

That should be "unpatched Windows XP".

I'm not hearing ANY significant problems with fonts joining the networked generation.

If something is «fundamentally broken» I assume you want to throw it away instead of trying to fix it. What would you replace it with?

You have my take, Completely.

Cheers!

I think the main thing I want to see Howcome respond to is why he's opposed to having EOT as an equal standard. I'm not opposed to the existing proposal, as I think it will solve some problems. But my survey of web designers showed pretty clearly that most of them want something that works (legally) with regular, commercial fonts.

Aluminum writes: So, to go back to the issue of ’web fonts’, we probably are over-thinking the ’outlines’ issue. We probably don’t have to worry too much about the scrapbooking mom using some software crack to extract web based fonts for her 4 year old’s birthday party scrapbook. Or, perhaps we do need to worry, but not on the technology side...but rather on the consumer awareness side.

You're over-thinking the "outlines" issue because that's not the issue at all. Howcome is pushing for simply putting entire fonts on Web servers. If there are to be any protections at all, they are only present if a server admin puts them there. Otherwise, you've simply got the fonts out there.

Now, other proposals, such as EOT, are still not massively secure either, but the general idea is that, as with PDF or other forms of embedding, it doesn't take massive security to keep the average person honest.

Thomas Phinney wrote: I agree emphatically with Joe that referencing fonts in CSS is fundamentally broken.

Howcome replied: If something is «fundamentally broken» I assume you want to throw it away instead of trying to fix it. What would you replace it with?

Actually, I just want a CSS spec that makes it clear, given a font, how one gets the "font-family" property from that font. Now, given that this has been unspecified for so long, maybe we need a new tag to go with the unambiguous spec. But *something* would be good.

Cheers,

T

Thomas,

Would you recommend that the W3C CSS recommendation should explicitly reference ISO/IEC 14496-22:2007 (Open Font Format, the ISO variant of OpenType)? I think it'd be a good idea -- of course CSS should remain being somewhat format-agnostic so theoretically it could work with BDF or Type 1. However, CSS might cite particular examples based on ISO 14496-22. I think that would be useful.

Is the OpenType Layout script, language and tag registry a part of ISO 14496-22?

A.

The CSS recommendation needs to explicitly cite processes for *all* major font formats to say how one processes the information inherent in those fonts to get to a CSS "font-family" string. Or sub for "font-family" some new equivalent thing.

Cheers,

T

Thomas Phinney wrote: I think the main thing I want to see Howcome respond to is why he’s opposed to having EOT as an equal standard.

I'm not. Currently, EOT is on an equal footing with other font formats in the CSS specification in the sense that they are all listed:

http://www.w3.org/TR/1998/REC-CSS2-19980512/fonts.html#referencing

Some people have argued that EOT should be given preferential treatment in CSS. This I'm opposed to as I think TrueType and OpenType also have roles to play on the web. Therefore, I believe CSS should be agnostic wrt. font formats -- they should all be "equal standards", if you will.

So, it seems we're in agreement?

Howcome: "So, it seems we’re in agreement?"

If the 'we' you came to 'meet' is folks with no typographic intellectual property of their own, little or none in the companies they represent, and no experience that I'm aware of in improving either tools, technology or type on the web, 'You' are in agreement.

And, if you only 'think' "TrueType and OpenType also have roles to play on the web" and don't 'know', we've not moved much closer to anything but more, (perhaps), of that nice 'free-for-all' display type, e.g. Larabie.

Cheers!

OK, Håkon, I think you’re misunderstanding the issue of specifying exactly one font, due perhaps to not being an expert in these sorts of things. (Which is fine! Which is why you’re here! And all I can say for myself is I always have valid CSS.)

The issue is that the font names presented to the computer user are variable, as are the exact filenames (highly variable when you compare PostScript and TrueType fonts, still somewhat variable in OpenType despite the marketing pitch that the same file works everywhere). Thesis is a worst-case scenario, given that there are over 250 variants. 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?

—
Joe Clark
http://joeclark.org/

Lie: Some people have argued that EOT should be given preferential treatment in CSS.

That's a bit misleading.

OpenType and Type 1 are already public standards adopted by the ISO. EOT has heretofore been a proprietary and unpublished spec. In order to be broadly usable, EOT should be adopted and published by a standards body. But which one? As the whole point of EOT is to be a Web standard, the W3C is the obvious answer. I haven't seen anyone suggest that the W3C should endorse EOT *more* than any other format, just that the W3C be willing to be the holder of the EOT format.

Cheers,

T

I wrote: Some people have argued that EOT should be given preferential treatment in CSS.

Thomas Phinney wrote: That’s a bit misleading.

No, it's not. People have suggested that the CSS WG recommends the use of EOT over other font formats. I was in the meeting.

Thomas Phinney wrote: EOT should be adopted and published by a standards body. But which one?

It would be good to see the EOT specification published. It's always good when closed, proprietary formats are opened up. It's easy enough to do, just put the specification on the web.

I'm not sure the EOT format needs a standards body any more than DOC or PPT do -- those specifications are, apparently, scheduled to be released soon. The people behind EOT are, of course, free to submit them anywhere they want. My only argument has been that work on font formats is outside the scope of CSS.

Thomas Phinney wrote: The CSS recommendation needs to explicitly cite processes for *all* major font formats to say how one processes the information inherent in those fonts to get to a CSS “font-family” string.

Perhaps.

The interface between specs can sometimes be tricky as specs often are controlled by different people and organizations.

An extra complexity in this case is that CSS implemementations do not, in general, deal with font files directly. Browsers typically use the APIs and font renderers provided by the operating system they are running on, they don't open the font files themselves. As such, it would be more relevant to make demands on the operating systems and the APIs they expose than on the CSS specification.

BTW, the CSS specification briefly discusses the complexities of names here:

http://www.w3.org/TR/1998/REC-CSS2-19980512/fonts.html#aname

I'm open for proposals, though. How would you describe how to map information from (say) OpenType to a font name?

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" }


> 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

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?

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

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

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'?

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!

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/

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?

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.  ;-)

"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!

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/

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.

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

—
Joe Clark
http://joeclark.org/

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.

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

Thanks for working on that!

> 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

«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.

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.

> 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...

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.

«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?

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.

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?

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?

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 */


> 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.

> 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.

(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.

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!

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.

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

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.

> 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?

«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" }


«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.

«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?

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

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?

> 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

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”

«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.

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.

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?

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.

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.

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.)