In their latest issue, Reservocation asks interactive luminaries about type on the Web. Todd Dominey and Jim Coudal give particularly interesting responses.
See also: Type on the Panther Screen : MS Web Core Fonts :
Screen-based Typography Research
Get a prominent ad at a reasonable rate. Support Typographica.
I still can’t wait for the day when designers will be able to embed fonts right into their websites, perhaps through an external file similar to a stylesheet so that individual page size doesn’t increase. With superior anti-aliasing, readability issues should go straight out the window.
Then we won’t have to worry about whether Microsoft is going to enact a stranglehold on fonts we’ve come to hold dear, and the standards folks will finally see their dream come true where we won’t need graphic-based text anymore.
Of course, then there will be questions of rights issues (or outright prohibition in the licensing agreements) from font vendors about such encoding. With any luck, the people developing such capabilities in next-generation browsers will work with font vendors to ensure secure ways to encode fonts without their being easily duplicated. Here’s hoping.
Yes, I know someone already tried it, but although it was promising, it was also extremely limited. It was an experiment ahead of its time.
> With superior anti-aliasing
The only really good anti-aliasing (at reading sizes) is the hand-made stuff.
hhp
Dave: There’s Glyphgate (neďż˝ Fairy). But I’m always leery of any product that tells you to inquire before telling you the price.
Obviously, dynamic fonts are the anwser. Back in the 90’s we had two different and incompatible technologies from Netscape and Microsoft. Nobody won that battle, and the feature was afterwards removed from NS (in the 6.0 version).
On the W3C standards side, the dynamic font module for CSS3 has been stuck in a “working draft” mode since 2002.
On the free high quality fonts side, Bitstream released last year the Vera family with a ‘free software’-like licence. Serif, sans-serif and monospaced versions are available. Web developers should link to stable public URIs for these fonts (the way XML namespaces are defined by URIs pointing to DTDs for example). That would solve the caching problem, because obviously loading 4 or 5 font files for each page is not an option.
Font embedded into web pages? I vote for only after the resolution of screens increase to 300 dpi. Before, not really a need?
What who can be problematic in short term is the availability of bundled fonts (the core set of each operating system) in different platforms. Still today, with the old Explorer MacOs, Mac user have chance to have Verdana, Georgia and others like Windows users. I wonder what will happen in next generation of MacOs when Explorer will not anymore available on Mac and Office not installed.
Then, MacOs, Linux and Windows will back again in 3 different font worlds and it will became more problematic for web designers than painful various support of CSS.
Where’s the inherent need for this
other than for the designer?
Form follows function!
You’re joking, right?
> only after the resolution of screens increase to 300 dpi.
You’re forgetting pixelfonts, especially grayscale ones. At current resolutions they’re needed for reading sizes.
hhp
Providing web page designers with a variety of font options doesn’t appear to be a priority with the powers that be. (Or else we’d have Helvetica/Verdana Light to work with.)
But really, why can’t the browser engineers figure out a font format/procedure that will download (cache) the fonts used on a website, then trash them when the visitor leaves a particular URL (or make them unavailable at other URLs).
Surely this is the number one priority for a text-based medium?!
Like Ned said, the technology was there -in two forms no less- but politics (as well as some ego-trippin’ paranoia among some type designers) prevented widespread adoption.
hhp
I like the idea of fonts installed when upgrading or installing a web browser.
Browser developers should team up with type foundries and include open-source fonts with browser upgrades and new installations. Designers would then know with a relative degree of certainty that certain typefaces are available on certain browsers.
I am not allowed to have an opinion?
My needs are met. Sue me for being simple.
Long live Vignelli.
Hrant – but politics (as well as some ego-trippinďż˝ paranoia among some type designers) prevented widespread adoption.
Basically yes, but also Web designers care about legibility for body text and that caused a problem for both technologies. For Bitstream/Navigator you had the issue of throwing away hints and anti-aliasing – an idea a few years a head of its time as it turned out. And for our technology, which keeps the hints, there are practically no fonts as legible at low res in b/w as Verdana and Georgia – so why downgrade your users reading experience and add bloat to your pages? My belief is that the success of the Web fonts was the major contributor to the lack of interest in font embedding for the Web. Having said that the technology is used on numerous minority-script web sites, as well as more mainstream sites – http://www.mlb.com – being one that springs to mind.
Nick – Or else weďż˝d have Helvetica/Verdana Light to work with
As your lowest common denominator is bi-level rendering, you have single pixel stems for regular and two pixel stems for bold – which leaves no room for intermediate weights. ClearType provides the possibility of intermediate weights as well as bolds that are not overly bold, like Verdana and Georgia.
Cheers, Si
> ClearType provides the possibility of intermediate weights
As do grayscale pixelfonts.
Another technique that’s not used enough – or at all: setting the 2-pixel-stem bold in a dark gray. It actually works.
hhp
I am not allowed to have an opinion?
My needs are met. Sue me for being simple.
Long live Vignelli.
Opine all you want, but do try and be consistent. The fact that you have an image of text on your site is a little betraying. And try to keep the zealotry to a minimum(Zeldman can kick Vignelli’s ass!). Your meager needs being met says very little considering they are being met by…multiple fonts! Why not just reduce to nothing more than Arial and Georgia? Who needs Arial Black, Andale Mono, Courier New, Verdana, Times New Roman(I’ll concede this one), Trebuchet, Tahoma, Impact? Nobody ever uses them, and if they do, they shouldn’t because they’re superfluous. Better yet, we can not spec fonts at all, and let the user’s stylesheet figure it out. You do know where your user stylesheet is, don’t you?
Claiming that wanting the ability to use fonts other than available at the moment is nothing more than a designer kvetch is a straw man I’m not going to bother arguing against if you can’t see what’s wrong with it.
The greater issue is that the majority of the “standard” web fonts are being blocked off from entire user bases if you don’t install Microsoft’s browser, unless you go digging around in the Wayback archives or a few other places. The vendors of web creation software haven’t made any significant changes to the standard font selections their programs insert(I’d argue it’s not entirely their responsibility), and most designers can’t be bothered to check what *is* available on other systems to put them into their stylesheets. These, likely, are the same designers who claim that you can’t do typography on the web.
Bitstream’s Vera is a really nice idea, but I don’t get why it isn’t being picked up by or pushed to people producing software for bundling. It’s the only way it’s going to get any sort of penetration. Most people are simply not aware it even exists.
>which leaves no room for intermediate weights
Si — a light weight sans would be suitable for large sizes. At a smaller size, it would default to a regular weight.
At the moment, the nicest Core face for large sizes is Times, which has some fine details on the serifs when you use it large. Georgia, however, gets very slabbish.
That’s because Georgia is a real text face while Times is not.
hhp