I thought Patrick Griffin had an interesting idea that got shot down pretty quickly. He suggested using some of the technology behind PDF as a solution. I think people assumed he was meaning that PDF could become the new HTML, but my impression was that he was suggesting using parts of PDF technology within a browser to display fonts correctly — not having the whole page be a PDF file. I believe PDF is an open standard now, so it would not mean that Adobe would be responsible for the implementation.

I’m not a programmer, so I have no idea how exactly this would work, and it may be a moot point now that Safari is allowing font embedding, but it would be interesting if there was some way that when you were creating your web page (I suppose you’d need to use a WYSIWYG editor rather than just writing the raw code), the elements that required specific fonts could be rendered into some sort of on-screen postscript that keeps the text scalable, and copyable, but the fonts themselves would remain hidden behind the PDF technology.

>He suggested using some of the technology behind PDF as a solution.

If that was his intention then we did get the wrong end of the stick. Although this suggestion too has issues. Most font vendors understand PDFs, and many allow embedding. Extending PDF to become a delivery mechanism for fonts would need to be co-ordinated with the community, (like EOT was, when document embedding was extended to the Web) and licenses would need to be adjusted. As I recall extending the scope of PDF to include editable forms wasn’t a smooth process with respect to font licensing – and in the end going down this path would lead to a Flash competitor? Maybe opening up Flash as an open standard would be a better way to go? However not really seeing an advantage over EOT.

Web designers, if you agree that raw-font-downloads are not the solution you’re looking for let the W3C know, post to the blogs and newsgroups and if you agree with the positions at www.fontembedding.com post a link.

No no no!
Please don’t make this another format war!
A broad EOT support would be great, but support for linking TTF/OTF files also. There is no point in trying to force the browser makers only to go for EOT. We can learn from the music industry and don’t have to make the same mistakes. It’s about the fonts and the users – not about protection and font piracy.

Web designers don’t care about the format at all. They will just use whatever has a broad support and is easy to use. (The fontembedding.com EOT generator is certainly a step in the right direction in this regard.)

Ralf
http://www.webfonts.info

Sorry Ralf, I wasn’t sugesting a format war - just getting the word out that raw-font-downloads don’t serve the needs of Web designers. I don’t think raw fonts will go away.

I will have more detailed comments later, but after Sunday’s session I am increasingly convinced that EOT is the short- to medium-term solution. It resolves many of the problems with raw font embedding such as security, licensing, and the vendor’s ability to offer a product tailored for the Web.

Thanks very much for the update and information.

I have been imagining PDF-style embedding as inevitable for the web. However the proposal to the W3C from Microsoft for EOT is very encouraging. You’re absolutely right that it’s not the silver bullet — maybe not a bullet at all, but at least it would be forward progress.

>However the proposal to the W3C from Microsoft for EOT is very encouraging.

We should give Monotype a mention too - spec’ing and offering the compression was a major undertaking. And Monotype’s David Dewitt was our 8th panelist from the front row.

I agree with Si that any PDF-derived solution doesn’t have any apparent advantage over EOT. I do appreciate the idea... I didn’t take it that way when it came up during the panel. My reaction at the time was, “Oh no, let’s not drag PDF into this” — and I guess I still feel that way. HTML with CSS is still such a nice, straightforward delivery system. Technology like PDF and Flash has its place, but I really do think web developers deserve better typography without bringing all that into play.

”...the discussion was more focused on delivery mechanisms.”

I don’t like this idea. :)

”... in Tom Phinney’s opinion EOT is on par with PDF embedding in terms of security.”

Fine. But put security out of your mind, and instead, think about how complete a PDF is compared to anything one can compose with EOT on a page. “PDF-style embedding” means not just the font is stuck into the file — it means the font is completely composed, with all that implies, and then the font and all sorts of descriptive info on its use are embedded. And THEN, because PDF is a zoomable technology, no additional composition is required besides the user fitting it into the window.

Security, EULAs and some parts of Delivery can wait.

Cheers!

>the font and all sorts of descriptive info on its use are embedded

You don’t see that as being possible with EOT and CSS?

Since Adobe bought Macromedia I’ve been thinking that one day soon I would be able to export complete websites as PDFs from tools like Dreamweaver, InDesign or even Flash. I’d still love to see that happen. But at least publicly I don’t think that has even been floated as a goal.

However there is the immediate thrill of having an open source font standard that is usable by the major browsers via CSS very soon. EOT is the only current candidate and would seem to be able to be implemented with the next CSS release. Nothing else seems to be close. And there doesn’t seem to be a reason for the major browsers to not support it — at least from my distant point of view.

The alternative seems to wait be waiting for Adobe to launch a proprietary solution and get the browsers to implement it. And having a font call from CSS with no defined standard will lead to chaos — fine for the anarchists, but bad for business.

“You don’t see [typographically descriptive info] as being possible with EOT and CSS?”
lol. I hope so.

”...to export complete websites as PDFs.”
You, are not following. Websites do not zoom, and though PDF’s do not live by zoom alone, zooming is critical to PDFs de- and em- ployment.

Cheers!

That panel certainly needed more time. So did most other panels.

When I suggested to the panel that using PDF technology can be a good universal response to Apple’s implementation of @font-face, my suggestion was a direct reply to Roger Black, who at one point said that we needed something where designing for the web is the same as designing for print. We already have something like that. It’s called PDF, and it’s been through the wringer for many years to prove itself. Acrobat already has plug-ins for all browsers, enabling them to view PDF within the browsernot to mention that the tech is already standard on iPhones, iPods, and every smart phone. The only remaining issue is loading time. Couldn’t that be alleviated if some non-fat version of PDF is implemented?

Given that PDF has finally become the print standard format after about 20 years of development, it doesn’t take much imagination to make the leap. A proven tech, already a standard one one medium, designers (both type and layout) are happy with it, so why not see if it can work for the web too. Wouldn’t it be great if building a web page was as easy as exporting a PDF from InDesign now? And PDF already respects font embedding bits, so type designers can be happy.

Another reason for my suggestion was Apple’s stubbornness and inconsideration of the ramifications of their @font-face action. Not only it makes things ridiculously complicated and costly for type designers and users in terms of licensing, but as Erik van Blokland pointed out on the panel, it is also a browser user security breach (triggering the operating system’s layout engine, so a font can in fact be maliciously constructed to crash one’s system). Apple already supports PDF under its own terms on OSX (the Preview app), so if PDF tech is used for the web as well, it would be a walk in the park for Apple to implement it in Safari. I like EOT and applaud its submission as a standard, but I’ve been around long enough to know that there isn’t enough incentive for Apple to implement it in Safari. Not to mention Firefox.

Ten years ago, two font embedding techs were proposed. Bitstream’s PFR and Microsoft EOT. Netscape went with PFR and IE went with EOT, so they cancelled out each other and both techs went south. Now Apple has gone with @font-face, which is in effect server-based, browser-downloadable TTF/OTF, and Microsoft has submitted EOT for standardization. Déjà vu.

Who was it that said: “The great thing about standards is you can have so many of them.”? And which way will Firefox go if EOT is standardized? Which way will it go if it isn’t?

Wouldn’t it be great if building a web page was as easy as exporting a PDF from InDesign now?

No. PDF is based on static content placed on a fixed layout space (“the page”). A website works completely different. A system for a fixed-size website with support for embedded fonts is already available. It is called Flash.

Ten years ago, two font embedding techs were proposed. Bitstream’s PFR and Microsoft EOT. Netscape went with PFR and IE went with EOT, so they cancelled out each other and both techs went south.

They didn’t cancelled each other out. The web designers would have used both technologies at the same website if they had worked properly. I tried to do websites with EOT and PFR in the 1990s. The results were faulty and plain ugly. Mostly because of the missing subpixel rendering at that time. But that has changed ...

Now Apple has gone with @font-face, which is in effect server-based, browser-downloadable TTF/OTF, and Microsoft has submitted EOT for standardization. Déjà vu.

That’s why I said we shouldn’t start another format far. It really doesn’t help.

BTW: @font-face and EOT are not different technologies. An EOT font is also loaded with the @font-face declaration. The CSS webfonts module states that @font-face can support TrueDoc-pfr, Embedded Opentype, Type1, TrueType, OpenType, TrueType GX and Speedo intellifont.
So Apple didn’t introduce a new technology with Safari 3.1. It is in the CSS specs forever.

Re PDF for web, a clear no. For a simple reason:

PDF was made for static design, making printing data visible on screen. It’s dimensions are fixed, everything on the page is fixed. The only thing you can do is scaling. For anything beyond that, PDF is a dead end.
html(/css) allowed layout to adapt to the size of screen or window. As non-designed as that may be, it pays tribute to the medium.
So if anything it would be a mixture of both a html/css website’s adaptability and PDF’s typographic qualities. Years back I was musing along these lines and thought that it were nice if PDF would support flexibility of layout; my focus then was on print and books printed on demand. But the solution came from the web/UI corner — Microsoft’s WPF is what I have dreamed of. (Some remarks here.)

The interesting thing about WPF is that it serves as common API for almost everything visual, both document description — static (print) and adaptive (web) alike — and application UI description. It completely erases previous “hardwired” distinctions like web/print or document/application. By integrating all, it implicitly points out that design is about structure, and a book and a UI have more in common than is obvious at first glance. And it fully supports OT layout features, thus fulfils part of the requirements for high-quality typography.
In my opinion, Adobe has missed an opportunity in this respect, yet Microsoft does seem to see the value of what they have done — at least the propaganda machinery is rather silent when it comes to WPF.  :)

As regards the topic of this discussion, WPF does seem to have a mechanism for font embedding but I am not sure how “secure” this is.

[Added: Maybe a good idea to bring up PDF, WPF, etc in this discussion. Speaking of ’web’ as html+ alone is too narrow-minded given what’s going on elsewhere.]

“I said that I doubted it [some premature Eula stuff] would get into OpenType due to these concerns, but another option for supporters of the technology would be to bypass MS and Adobe and take the fight to ISO (not trivial).”

This is interesting, and so I’ve wondered mightily not if, but when it’ll come up. What if: ISO has a stated goal, like for example, “high quality scaling of glyphs, based on the advanced TrueType hinting capabilities” or “broader support for advanced typographic features and text layout” but somehow MS and Adobe block that goal?

How long would you guess it would take for “the fight” to become trivial?

Cheers!

>No. PDF is based on static content
>PDF was made for static design

I believe the PDF has far more dynamic capabilities and/or possibilities than you are giving it credit for.

>but somehow MS and Adobe block that goal?

I think MS and Adobe would object to any changes to OpenType that would break backward compatibility in shipping apps and OS’s and we’d make that case. My comment related to the electronic EULA discussion. If a new table were defined by the community to include the eEULA I don’t know how MS and Adobe could block it.

The ISO process is complex, and since we lost our standards person we’ve been relying on someone external to help create documents, and report back from meetings. We are planning another day long OpenType meeting in the near future (will be publicized on OpenType list). Maybe an agenda item there would be how to submit independent proposals for consideration.

BlueSteak — I believe the PDF has far more dynamic capabilities and/or possibilities than you are giving it credit for.

I’m curious.

“I’m curious.”

I guess he’s talking about forms, video content, Flash content, 3D content etc.

>forms, video content, Flash content, 3D content etc.

Plus hyperlinking. What else is missing?

Oh, I see, thank you.
No, I did not speak of gimmicks but inherent adaptability/flexibility of the layout — make the window wider, and lines get longer or margins wider too, etc, depending on which kind of flexibility the designer allowed.

“I think MS and Adobe would object to any changes to OpenType that would break backward compatibility in shipping apps and OS’s...” ...but not fonts? good heavens! :)

Cheers!