Typophile - Black Blogs on-screen Type - Comments

” Though it doesn’t need

dberlow — Sun, 3 Jun 2007 05:30:44 -0700

” Though it doesn’t need to *start* complicated”
1994, 1999, or 2004 was when it needed starting simply. Now it is time to ask the user ’s appearence prefs and the browser version. Is that too much? Who would be against such a thing? oops...I almost forgot...lol...

Simon Daniels of Microsoft Corporation: “translation… “$$$$!” ;-)”
lol, not quite: $$$$$$$$$$$$$$$$$$$! is more like it, (split $$$$$$$$$$$ ways of course). But besides that, anytime Simon wants to go strolling through MS’s entire font library looking for functioning i-no-dots, on any platform, I’ll be there with a teeny-tiny doll spoon to hold what we find...Really.

meme on,

Berlow

>Amen. translation…

sii — Sat, 2 Jun 2007 16:17:43 -0700

>Amen.

translation... “$$$$!” ;-)

Here’s an interesting

James Puckett — Sat, 2 Jun 2007 15:26:58 -0700

Here’s an interesting idea. SVG fonts are well suited to browsers, and well poised for general cross-platform use. How much work would it be to integrate them into the EOT style system?

That’s probably not a great idea. SVG was always Adobe’s baby and Adobe dropped it after the Macromedia merger. Aside from maybe satisfying the tiny number of FOSS zealots who still care about SVG, and might refuse to work with EOT because they’re crazy, what would the point be?

David: But if embedding

John Hudson — Sat, 2 Jun 2007 13:39:01 -0700

David: But if embedding becomes sophisticated enough to ask the “entire specification”, down to user rendering preferences, one can deliver very specific fonts of the highest possible quality for each and every user.

Amen.

> for an embedding scheme

Christian Robertson — Sat, 2 Jun 2007 08:38:55 -0700

> for an embedding scheme that answers more questions than “FONTNAME”

True, true. Though it doesn’t need to *start* complicated. The advanced features should be available, but not required to make it work.

Likewise from Monotype, they

Choz Cunningham — Sat, 2 Jun 2007 08:30:32 -0700

Likewise from Monotype, they are documenting their compression, with a free license for Web use. Sorry if I didn’t make that clear.

No, you were clear, there’s no need to apologize, to me. I was being a bit tongue in cheek, but I meant, that to some activist, it will still be too fettered.

I do not see all this hap’nin as a result of this embedding today, do you?

Not instantly. That was from my list of the ideal situation. Ideals aere rarely attainable, but i see this as a more pivotal step forward than others in the line.

I see MS proprietary technology that has considerably more effect on the appearance of fonts than embedding, that is not supported cross-platform/browser, don’t you?

That’s why some people are developing non-hinted grayscale fonts, alternate text rendering engines, FOSS screen rasterizers and about a million other things.

——

Here’s an interesting idea. SVG fonts are well suited to browsers, and well poised for general cross-platform use. How much work would it be to integrate them into the EOT style system?

“it should be as simple as

dberlow — Sat, 2 Jun 2007 04:04:47 -0700

“it should be as simple as this:
h1 { font-family: url(“PillGothic300mg-Black.ttf”),Helvetica,Arial; }”

I see... If you are not either rooting for a confluence of the enabling and rendering technologies, or for an embedding scheme that answers more questions than “FONTNAME”, I think you need a rethink.

“”consistent type-What the designer makes looks, by default, virtually identical in default view, standard browser windows, and can be manipulated (zoomed, etc.) like “normal” text.”
I do not see all this hap’nin as a result of this embedding today, do you?

“I think a few type designers/vendors don’t like EOT purely because it is currently an MS proprietary technology and not supported cross-platform.”

I see MS proprietary technology that has considerably more effect on the appearence of fonts than embedding, that is not supported cross-platform/browser, don’t you?

I’m all for...embedding... but eventually, the fonts must emerge from their “hidden” folder and express the will of the reader or writer in a local font environment. To do this on a spectrum of technical foundations that are not consistently able to support high-quality output of fonts in low resolution environments is more than hard.

CT left pure TT behind and went for fake resolution. OS10 left TT, for ad hoc fat pixeled greyscale and TT was not fully licensed unto Freetype We all lost a place to do consistent high quality work, and who knows why? But if embedding becomes sophisticated enough to ask the “entire specification”, down to user rendering preferences, one can deliver very specific fonts of the highest possible quality for each and every user.

Delivering jam to spread on “whatever” and “promising” it will “taste good” is someone else’s job, apparently. Anyone today can see that the Windows CT and TT fonts once moved to the Mac look poor at most sizes. Moving “normal” TT fonts into a CT environment yields poor results as well, and browsers don’t allow enough options, consistently, to assure user comfort or allow publisher’s even modest quality control.

“the only folks [who] seem to really push for custom fonts on the web are the ad agencies working on major brand campaigns. As they also see fit to turn the web into pure Flash, there is little reason for them to need another font embedding method”

I see...So if this is only about text...

Cheers!

Obviously Darrel I meant

hrant — Fri, 1 Jun 2007 22:15:58 -0700

Obviously Darrel I meant that your viewpoint is shallow, or at least over-simple. The truth isn’t like that at all - as usual it’s quite complex! For one thing, relying on the conscious evalution of readability on the part of end-users is just plain nuts; in fact it has been shown empirically that users over-estimate the font size that’s most conducive to reading - which is to be expected. And if they get the size wrong, you can bet they get everything else wrong too.

The bottom line is that discerning designers design things in spite of what users say (or often even think) they prefer; and -like Christian said- discerning designers spend money on fonts to get their results just right; yes, more often in print, but there’s so much room to grown on-screen.

> The main money maker will be display fonts

While the main “comfort maker” will be text fonts,
specifically in the area of hand-made grayscale fonts.

hhp

There’s no code license -

sii — Fri, 1 Jun 2007 21:02:12 -0700

There’s no code license - it’s documentation, a format spec, which would likely be appended to the CSS spec. Likewise from Monotype, they are documenting their compression, with a free license for Web use. Sorry if I didn’t make that clear.

But Microsoft doesn’t own

Choz Cunningham — Fri, 1 Jun 2007 20:49:24 -0700

But Microsoft doesn’t own all the code, they license it from Agfa, who borrowed it from Monotype, who has it on a lease from a guy in Wisconsin, who knows a guy who... or whatever. ;) The peer pressure response is very valid, since Firefox is the self-proclaimed force that keeps IE competitive where the free market and our gov’t failed. Mozilla devs would likely be able to code compliant behavior from the data that would be released to get W3C approval.

Another interesting thought:

James Puckett — Fri, 1 Jun 2007 18:42:55 -0700

Another interesting thought: To go into Firefox needn’t the methodology be GPL’ed, not on indefinite loan from a private interest?

According to Mozilla.org:
All of the code which makes up the core Mozilla products is licensed under a MPL/GPL/LGPL tri-license or a licence compatible with all three of those (e.g. the BSD licence).

Given those license terms I doubt that there will be any trouble getting Firefox support. Microsoft has gotten along just fine with the BSD license for decades, so and Microsoft code could simply be released under a BSD license. But Microsoft doesn’t even need to write the code, it just needs the W3C to sign off on EOT and then the Firefox team is stuck supporting EOT because they would never let IE support an open standard that the Firefox team does not.

Jpad- I wasn’t meaning to

Choz Cunningham — Fri, 1 Jun 2007 17:30:53 -0700

Jpad- I wasn’t meaning to champion FOSS either. I haven’t the inclination or the knowledge. The FOSS fanatical types will not settle for free (in cost) methods to accomplish this goal. The main thing keeping them from calling for/developing a solution was that no “open” browser support a way for fonts to be served into a web page, even if they were licensed appropriately. Christian is right, there is a lot that it entails in the sandbox department, and also with integrating it in web dev/management tools.

Another interesting thought: To go into Firefox needn’t the methodology be GPL’ed, not on indefinite loan from a private interest?

Anyway, the radical libertarians are out there, and this will be another step closer to making fonts as simple as serving an image or a text file.

Christian- it should be as simple as this:

h1 { font-family: url(PillGothic300mg-Black.ttf); }

Or, at least start that way. The W3C likes to write imaginary software then wait for someone to make it, and they’ve come up with a pretty extensive method of defining the font, including degrading back to plainer fonts, real and emulated variants, small caps and all sorts of stuff. If I recall, Microsoft’s new method of font substitutions in Vista is based on a portion of this, so it has some viability, too.

David- Simon explained the gist of it, but I’ll break it down a bit.
Open - consisting of fully-public documented procedures
css friendly - conforming to the xhtml font-face and css @font-face rules of the W3CC specs.
non proprietary - not controlled, dictated or dependent on components of code controlled by private parties through licensing agreements.
cross server - Works consistently with any full-featured software that spits out web pages.
cross browser - Works in every major current pc browser, and could work in even more, or at least, not break them.
consistent type-What the designer makes looks, by default, virtually identical in default view, standard browser windows, and can be manipulated (zoomed, etc.) like “normal” text.

Darrel- For the moment you are largely right. But... screen resolution has and will continue to improve. The population will continue to move online, and bring more arts and culture with it. Computers will get faster, bandwidth and storage cheaper, font rendering software will improve. Every one of these factors will make a more viable market for any digital media, including fonts. The main money maker will be display fonts which stand to improve in the screen-arena the most, and are easy to appreciate to designers and lay-folk alike.

For big companines, rendering display text in the native browser space instead of through a plug in and a hack will reduce costs. They can keep accessibility and still market themselves. They can have dynamic headlines and such that really stand out, but managed without adding another layer of re-rendering graphics or such.

Your comments give me an interesting line of thought about font-on-demand services to serve to others’ pages. Hmm...

Sii- I think I read correctly, but grossly misunderstood the post. I’ve since re-read it a few times.

“but none allow “zipping” as currently proposed.”

I think this means “zipping” as currently possible and very rarely done.

I just could not get my brain around that. Why would someone want to zip the file to transmit it as an element of presentation? Most font files are small, when considered as media, and the wrapping in a generic container would only make the user unsure of what they are getting. Additionally, if they were downloaded and the user knew what to do with them, they still have to go through the process of installation and restart of the browser. As I see it, that is a non-solution.

As a designer, I would be helping my clients make bad web sites if I endorsed this method, with the obvious risks to my work.

This is essentially a survey that asks, “do you prefer doing something this one way, or in the worst possible way?” Yes, I’ll take the former.

What I thought it meant was that there was a proposal to run simple zip-style compression on a font, with the typical extension change or similar, so that it would be rendered immediately inside the web, but with a slightly smaller transmission size and isolated from the OS. Sure it would be rather trivial security to my work, but it would be of great benefit to the consumer. In which case I would have to say that it is appealing.

The topical section of my Pre-formed EULAs goes like so (emphasis added):

The output of the software may be embedded in any manner of portable document or interactive electronic document, assuming a reasonable, common level of care is exercised to prevent extraction and/or installation of the font data.

This leaves a lot of leeway for the most basic systems of presenting the text electronically. Since there was no cross-platform solution when I wrote that, and still isn’t, I decided to gloss things. Remember I do not consider anything that requires the client’s end-user’s interaction as truly “embedded”.

Over half of what I’ve licensed this year closed with a custom EULA, and no end-user has yet asked for zip-link access. When I offer a license’s full text to them prior to sale, they are told to reply if there is something else they want or need, both in my correspondence and in the license itself. Every sale has been through contact with just me, and no one has yet requested it. I’m open to it.

BTW one “vendor” that I thought of that currently buys fonts and then serves them as links is SIL. (Clarification: SIL is a font purchaser from whatever vendor(s) allowed them to post the fonts as zips.)

Tiff- The ones I linked to a while back are slightly out of date. Once Myfonts figures out how to handle the leading !- in my font names, the new EULAs will go up, with the products. Any day. Really. Like soon.

“It depends who your

aluminum — Fri, 1 Jun 2007 14:57:52 -0700

“It depends who your clients are. There are a lot of companies that really do get branding and the power of typography.”

Typography is important. A specific font for body text, not so much. At least not in the eyes of the end-user.

“These are the people who buy typefaces. They are buying type for the web right now for gifs and flash, and they would buy more of it if embedding worked.”

Maybe. Hopefully we’ll get a chance to find out down the road. ;0)

it should be as simple as

Christian Robertson — Fri, 1 Jun 2007 13:43:59 -0700

it should be as simple as this:

h1 { font-family: url("PillGothic300mg-Black.ttf"),Helvetica,Arial; }

> a huge chunk of ‘huh?’

Christian Robertson — Fri, 1 Jun 2007 13:38:25 -0700

> a huge chunk of ‘huh?’ responses.

It depends who your clients are. There are a lot of companies that really do get branding and the power of typography. These are the people who buy typefaces. They are buying type for the web right now for gifs and flash, and they would buy more of it if embedding worked.

Black Blogs on-screen Type

mike_duggan — Thu, 31 May 2007 09:36:28 -0700

Roger has been busy lately blogging about onscreen type. It might be of interest here

http://www.rogerblack.com/