Try searching the MS Typography site - it has gobs of stuff.

But do beware two issues:
1) Browser/OS compatibility.
2) The apparent ease of swiping such embedded fonts.

hhp

Thanks Hrant,

I did do all the reading on the site. It was informative ... but I am a little cynical, as MS is the Great Satan. I was hoping some here have had some experience with WEFT and would be willing to share.

I saw an earlier thread that you took part in that talked about the ease of swiping embedded fonts. That would be a conscern.

I think our problem is as a design studio that designs mainly for print we are having trouble thinking in terms of type variables that you get with the web.

I understand and accept it, but the designer that I am working with to create our site feels funny about not controling certain aspects of the user's interface, such as the type choice and treatment.

One of the things I do not like about WEFt is that it is not cross platform or cross browser. So, even though you may be able to control the type on PC's using IE, you still ahve to account for NS and Mac's and thus you are back to the basic considerations with web design that you are trying to eliminate.

Does not seem worth it, really. If it were up to me I would spec Ariel and move on ...

;)

What about using Flash?

hhp

Erm, I'm no web guru - in fact I know little to nothing obviously - but WEFT didn't work so well for me. That is, it works fine if your end user is on a PC with Explorer 5 or above, but not at all if they're on a Mac.

Feel free to check out {www.eightyproof.com, my site} & see the atrocity. On a Mac none of the text shows up. Though it looks fine on every PC I've seen it on.

My apologies if your screen resolution is above 1024 x 768. Joe Clark would probably hunt me down if he ever saw such a thing.

So you're saying if it's not Explorer on Windows, a page using WEFT (EOT) simply bombs?
Isn't there a way to have a fallback mechanism?

hhp

I haven't really put much work into making my site function - I'm hoping over winter break I'll have time - but I'm not sure how I'll work around it. I'm also an idiot when it comes to coding. This site is the only site I've coded, and I taught myself everything I know about CSS, HTML, and JavaScript. Which is not much. But...

I thought I could call up different CSS based on the OS/browser of my user. But WEFT writes the style declarations for font substitutions in the .html documents themselves - not the CSS. So I don't think using different style sheets will work.

The release notes for WEFT say that the font tag doesn't work in MacIE4.5, but CSS declarations do. I tried the work around suggested in the release notes, but could never get it to work.

Like I said though, I've done very little in the way of fixing anything. But I've never once seen the text on my site on a Mac. And I had mucho problemo with Netscape Navigator.

Sorry this doesn't help much.

One big problem I've found with WEFT (other than the fact that it won't work on anything other than IE) is that, even if you have ClearType turned on, the embedded type won't anti-alias, which looks like crap most of the time.

Nathan: you could always move the styles in the .html to a .css file and then call it depending on the user's browser. And font tags are deprecated anyways - there's simply no need to use them anymore.

One big problem I've found with WEFT (other than the fact that it won't work on anything other than IE) is that, even if you have ClearType turned on, the embedded type won't anti-alias, which looks like crap most of the time.

Really? I've not used WEFT, but I've looked at quite a lot of sites using it and ClearType seems to work fine. This WEFT tutorial site renders nice and smooth for me (Win XP Pro SP1, ClearType, IE6.2). Loud colours and poor choice of font, but it gets its point across (the cheesy music really is obnoxious though, and I bet they don't have broadcast permission).

Maybe they fixed it, then. I've only tried it one time, prior to discovering it only worked on IE, and embedded fonts wouldn't antialias.
My mistake, then.

I still think, though, that WEFT will only be ready for prime time once it works under Mozilla.

I think WEFT is a fundamentally cool technology, which the MS Typography folks came up with, and the rest of MS is not that interested in.

Support for WEFT has gone *down* over time, as it was once supported in the Mac version of IE. If MS as a company were at all serious about it, WEFT would have gotten built-in authoring support in Microsoft FrontPage.

Darn shame. Some well-supported sort of font embedding for the Web would be a Good Thing.

T

Mike -

A listserve on which I have been lurking, speaks more specifically how different browsers hande a given web design.

You might be able to get questions answered through http://webdesign-l.com/.

Alan Steytler

> This WEFT tutorial site renders nice and smooth for me

On my end it renders smooth when CT is turned on, but 1-bit when CT is off. I wonder if it's a GASP issue, since the larger Times text in the boxes does render smooth no matter if CT is on or off.

If the issue is the GASP settings, then it's really a matter of making sure the font is hinted well if you're using the range of sizes where smoothing is off (assuming CT is off). So it's not the technology's fault, more like a combined limtation of the hinting in a given font design and the font rendering algorithm in Windows (which is however the best out there, except maybe the Kaasila stuff).

I need to do more testing.

BTW, what do you guys know about security: how easy it is to extract a font from an EOT/WEFT page? Is it like PDF, harder, or easier?

hhp

I've never tried extracting from an EOT. I know it is not simply a re-suffixed TTF file, but beyond that I don't know. Thomas has indicated that it is easier than extracting from a PDF. I find it hard to believe that anything could be easier than extracting from PDF used to be, but Acrobat's protection of embedded fonts seems to have improved considerably in recent versions.

"the cheesy music really is obnoxious though, and I bet they don't have broadcast permission"

Oy! Cheezy music... It's Enya, lovely Enya. Song is Only Time on the album A Day Without Rain.

I haven

>>I understand and accept it, but the designer that I am working with to create our site feels funny about not controling certain aspects of the user's interface, such as the type choice and treatment.

Either your designer needs to learn to adapt to the context, or you need to find a web designer to design for the web.



>>One of the things I do not like about WEFt is that it is not cross platform or cross browser. So, even though you may be able to control the type on PC's using IE, you still ahve to account for NS and Mac's and thus you are back to the basic considerations with web design that you are trying to eliminate.

Yep, so either you can detect OS & browser or do what you would do if it were up to you...

>>If it were up to me I would spec Ariel and move on ...

Me too!


>>So you're saying if it's not Explorer on Windows, a page using WEFT (EOT) simply bombs?
Isn't there a way to have a fallback mechanism?

Yep, - detect browser version & OS




>>I still think, though, that WEFT will only be ready for prime time once it works under Mozilla

Its years since I met a client who thinks that's worth the expense (and they only think that its worth worrying about Mac support if the site is aimed at designers, dtp community or journalists).
Non IE browsers account for around 6% now, and Macs are way behind that - people can't see the point of going to great expense to accomodate such minorities.

Offer a client a choice between
a) Spending lots of money maintaining typographic integrity while accomodating 100% of potential users
b) Blocking off fewer than 10% of users and saving loads of money

or

c) Compromising typographic integrity to get a site that everyone can use without spending a fortune.

In my experience C beats B almost all of the time - if any client ever goes for A, I'll let you know.

>>Either your designer needs to learn to adapt to the context, or you need to find a web designer to design for the web.


Couldn't agree more. The wish to "control" what people see on the internet is - at best - outdated, naive and quaintly megalomaniac, however it also betrays a serious misconception of the medium that is being designed for. In short: You can't control it and neither can I, so get over it and move on, before more valuable resources are wasted on solving the unsolvable.

The web is about the exchange of information, period. It is currently not a very suitable medium for the display of typographic integrity, whether that suits any of us or not (and yes, of course I *do* agree that current options for web typography are lamentable, limited and unsatisfactory, ).

Flash, while fun and (typo-)graphically more fulfilling than HTML, suffers from serious usability problems, not the least of which is the failure of SearchEngines to index Flash content in a satisfactory manner, so if that is important to you, you may have to settle for Arial after all. Of course you could go out on a limb and use Verdana instead...

While checking out the Microsoft Typography site, I came across GlyphGate, a server-side application that claims to offer a cross-platform solution to the limitations of web typography.

Has anyone tried it?

And that's why, in most cases, C is the rule. B is more of a shot in the foot than a business practice.

> and they only think that its worth worrying about Mac support if the site is aimed at designers, dtp community or journalists

It's not that hard to get a site working cross-platform nowadays as it used to be, say, 2 or 3 years ago. Most of the browser issues are gone or reduced to mere annoyances, and the few major issues that still exist can be worked around without much effort or 'hacks' as long as you plan what you're going to do and how before you actually get to coding (which a good web designer/developer should always do).

Oops... type forum. Bad non-typographic post!

Refusenik - That seems to work, but the type is not anti-aliased even with ClearType turned on.

>>It's not that hard to get a site working cross-platform nowadays as it used to be, say, 2 or 3 years ago

I agree that this is true as a rule of thumb, and in practice, as its usually possible to get clients to avoid problematic features when they find out how much it costs to get compatibility on some issues. But I think that its largely because people have more idea now that they can't have everything they want and still have 100% compatibility without paying a small fortune.*
About 4 or 5 years ago I wroe a cross plaform function library for DHTML - it was a learning experience as much as anything, which is fortunate, because not long after that new releases of Netscape and IE made it redundant. I wouldn't even consider doing such a thing now - at least not for less than a medium size fortune...


*Pop quiz: What's the quickest and easiest way to make a small fortune?

"Isn't there a way to have a fallback mechanism?
Yep, - detect browser version & OS"

Browser/OS detection is asking for trouble, usually. There are so many browsers today that unless you really take care to fully test your script in all the browsers and be sure to keep it up to date to reflect changes in all the browsers, you'll block a chunk of people from seeing your site.

There are still plenty of badly built sites out there that still assume the only two browsers are IE5 and NN4. Ugh.

The best advice for designing for the web is to realize that the most you can is 'suggest' a visual presentation. You can't/shouldn't mandate it.

But don't spec arial. yech. ;o)

GlyphGate, I think, is just a browser detection system that then throws out embedded faces if it can. A lot of money for little benefit, IMHO.

quoth Hrant:
What about using Flash?

If your site has more than very short snippets of text, please don't. Flash is lovely for animation, getting better for GUI development and can be just the ticket for rendering vector artwork. It is, however, an abominable means of displaying even modest amounts of text.

Any advantages Flash lends in terms of aesthetics (and at text sizes there are few) are overbalanced by loss of convenience unless you go to the trouble of ensuring that scroll wheels, keyboard accelerators and the like all work in your movie--something I have not seen done. I recently read through the Flash-based tutorials on this site and the experience was not pleasant. The type was too small for comfort on my screen (17" LCD at 1280 x 1024) and could not be adjusted, the antialiasing was appallingly bad, the lack of a history function (back/forward buttons) was frustrating and rendering speed was markedly inferior to HTML.

Flash design (which is image-centric) should not be confused with web design (which is text-centric). The two aren't identical, nor even all that close in many respects.

sayeth steve paxton:
Non IE browsers account for around 6% now, and Macs are way behind that - people can't see the point of going to great expense to accomodate such minorities.

I'd be a bit leery of drawing an serious conclusions based on general statistics. As one example, the Google Zeitgeist puts MacOS at 3% of web share while OneStat puts it at 1.49% and TheCounter splits the difference at 2%. That's quite a swing--Google claims twice the proportion of Mac users that StatMarket does. Upsdell's Browser News demonstrates nicely just how radically browser share can vary from site to site and also explains why statistics purporting to reflect the entire web audience should be taken with a grain of salt.

In addition, strict market share does not tell the entire story. Historically, Mac users have skewed more educated, more affluent and more willing to purchase online than Windows users. So although Mac users make up only a tiny fraction of the total audience, they may make up a much larger portion of the audience that will actually buy whatever it is you are selling. To my knowledge, there is no research on the demographics of browser users, but it is entirely possible that users of minority browsers may likewise be more desirable than their sheer numbers indicate.

There are really just too many factors involved for general stats like these to be taken too seriously.

Besides, IE as a standalone browser is dead. MS has gone on record saying that no further standalone versions will be released for Windows or Mac, and the primary driver of IE/Mac, Tantek

revealed Refusenik:
While checking out the Microsoft Typography site, I came across GlyphGate, a server-side application that claims to offer a cross-platform solution to the limitations of web typography.

I'm with darrel on this one regarding cost/benefit. It may engage in some tricky sniffing to determine browser capabilities, but as a practical matter there is no way to support every browser out there as this product claims. Just off the top of my head, one would have to test it with all released versions of Trident (IE 4+/Win rendering engine), Tasman (IE 5+/Mac), Seamonkey (NN4.x), Gecko (Mozilla, Netscape 6+, Camino, Firebird, Galeon, etc.), Opera and KHTML (Safari, Konqueror and OmniWeb 4.6+), to say nothing of such obscure rendering engines as iCab and OmniWeb (pre-4.6), older rendering engines used by the aforementioned browsers (such as IE 3, NN 3, etc.) or browsers for the Danger hiptop, PalmOS, the Symbian OS, etc.

From the FAQ:

Q: What is Server Gated CSS Level 2?

A: The ability to publish a web page containing CSS Level 2 formatting to a server and view that page faithfully in a browser without CSS support.

...

Q: What browsers are supported by GlyphGate?

A: All browsers are supported, at varying levels. Text of any language, any font, any color and any style is presented equally well in all browsers. Other types of formatting, such as border styles and margins, may or may not be supported by all browsers.

So they plainly state that it doesn't do quite what they claim: CSS2 layouts are not magically viewable on non-CSS2 browsers.

Q: How are browsers without support for "embedded fonts" handled?

A: Even browsers that do not support font embedding are fully supported. Web pages are partially formatted on the server and text set in non-standard fonts are transmitted as images to these browsers.

So it just sets your text as images in Mozilla, Safari, Netscape 6 (the 'Navigator' name only applies to Netscape versions prior to 6) et al.

I would also add that I'd be leery if this thing served embedded fonts to NN4.x. I've heard nothing but horror stories from those who have tried to use the Bistream embedding technology in that browser--as in 'every page with an embedded font crashed the browser' kind of horror.

Net-net, this product may be beneficial if you're serving sites using Thai or Arabic or some other script that is poorly supported in most browser/OS combos. It is not, however, a means of ensuring that 'every' visitor will see the layout/fonts you choose.

>>I'm with darrel on this one

I agree. The idea of "solving" issues related to pesky and uncooperative browser/platform combos by serving them images instead of text is particularly disturbing and takes un-usability to new and previously unseen heights. God only knows what Googlebot gets to see on a site using this technology. *sigh*

OTOH I must admit that deep down I am pleased to see that there actually are some companies (well, one) out there devoting time, resources and money to the issue of web typography. Let's face it: it can only improve from where it stands right now.

Hands up all those who wouldn't love to use a different font on a web page in their lifetime. ;)

> So it just sets your text as images in Mozilla, Safari, Netscape 6 (the 'Navigator' name only applies to Netscape versions prior to 6) et al.

Actually, I tested their example pages with Firebird (Mozilla engine/Win32) and it popped up a dialogue asking me to install a plug-in. I chose not to install it and the text was then set in Times New Roman.
On IE, it doesn't ask for a plug-in installation (I don't know whether it installed without my consent, which it shouldn't have, or if it simply works without a plug-in), the text was set in Franklin Gothic Condensed, as they claim, and it's just plain text - no images - but I had ClearType on and there was a clear difference between the GlyphGate text and the other text on the page, which was set in Arial. The GlyphGate type wasn't antialiased, even though ClearType was turned on.

"Non IE browsers account for around 6% now, and Macs are way behind that - people can't see the point of going to great expense to accomodate such minorities."

Actually, the great expense is IE/Windows...which is the most buggy in terms of supporting web standards.

That said, there isn't really any expense involved. A competent developer with an understanding of web standards can design for a variety of platforms/browser at once.

Nothing pisses me off more (well, in terms of the web, at least) than idiots that develop web sites or web applications that REQUIRE IE on a PC. That's *not* a web application. That's an IE/PC application. At that point, why bother with the browser? Just make your own thin client.

Our company uses something called Netilla to allow users outide our network to dial-in through the firewall and acecss their files. Netilla is Java based. It requires Mozilla to use. Great! Cross platform! Well, the idiots built the Java applet using MS's Java IDE. Which, like IE, is non-standard and proprietary. Crap like that is just way too common.

And let's not forget there are other platforms than Macs and Windows...some growing slowly but surely (WalMart sells Linux computers...many people are using their Palm OS Phone...etc.)

>>Actually, the great expense is IE/Windows...which is the most buggy in terms of supporting web standards.

Well, I think that's a highly dubious statement anyway given Netscape's buggines in terms of actually working ;)
Most clients are interested in 'cost per head'

>>That said, there isn't really any expense involved. A competent developer with an understanding of web standards can design for a variety of platforms/browser at once.

But that still takes longer than developing for just one browser, and testing is a much longer process. Unless you want to stick to really basic stuff (which is a good strategy, but one many clients don't want to know about). This is what I've said in the post above - you might have missed it, as your post was only a few minutes later.


==================
==================


Spouteth setmajer:
That's quite a swing--Google claims twice the proportion of Mac users

Hey, so the real figure could be as much as even maybe 4 or 6% at a push. I can't imagine any client not wanting to throw money at that market sector.


>>Historically, Mac users have skewed more educated, more affluent and more willing to purchase online than Windows users

Hmmm, interesting. You would know this from some other, more reliable type of statistic, then?

>>So although Mac users make up only a tiny fraction of the total audience, they may make up a much larger portion of the audience that will actually buy whatever it is you are selling.

Well there are a few assumptions there.
1. That your stats are right in a general sense.
2. That I, or my client, has something for sale.
3. That Mac users are the kind of people that want my clients product. Now I really don't want to get into a Mac vs PC fight, but both sides in that argument suggest that Mac users compared to PC users represent different groups with different approaches to buying. Which group presents the best pickings for a given client depends on many things, not least the product range and its target audience.
(Alternatively, one could argue that Mac users are not significantly different to PC users in a personality or lifestyle or buying habits sense, (and in fact are often the same people) but that still puts this part of the argument out of the window).

You suggest that:
'they may make up a much larger portion of the audience that will actually buy whatever it is you are selling'

Are you sure?
I'm not sure what you mean by 'much larger', but it seems unlikely that a group which consists of roughly 3% of the total is going to contribute a 'much larger' contingent in any subset - unless I'm selling Mac software of course.

>>but it is entirely possible that users of minority browsers may likewise be more desirable than their sheer numbers indicate

Yes, that's entirely possible, but in order to justify more than nominal extra expense, these groups would either have to be much larger than they are now, or very, very much more desirable users for a given client - and this would have to be demonstrable.

"Well, I think that's a highly dubious statement anyway given Netscape's buggines in terms of actually working ;)"

Hmm...I have infinitely more problems with IE crashing my PC than any flavor of Netscape or Mozilla.

"But that still takes longer than developing for just one browser, and testing is a much longer process."

Well, sure. Just like printing 4 color is more work than black and white. It certainly isn't perfect, but the problem is Microsoft, not the rest of the browsers. Choosing to design for microsoft only is just encouraging their bad behavior. ;o)

"Hey, so the real figure could be as much as even maybe 4 or 6% at a push. "

Also consider that a lot of Mac users still have to use PCs at work. So that skews figures like that as well. You can't assume that all people are one-OS users. ;o)

"Yes, that's entirely possible, but in order to justify more than nominal extra expense, these groups would either have to be much larger than they are now, or very, very much more desirable users for a given client - and this would have to be demonstrable."

Do you charge your clients on a per-end-user rate? Again, if you're designing for IE/PC only, then you're not making a web site. You're making an IE/PC site.

> detect browser version & OS

I think this is key.
Option C above is the best if you assume there can be only one version of a page. Sure it costs more to do a two-tier solution*, and usually the expense is hard to justify, but I think it's not any harder than justifying good design in the first place.

* One generic page for all browsers, a second for IE/Win - that's a great compromise between saving money and delivering quality.

The web is like a pet: you can't control it totally, but you can train it a lot with the right pragmatic and "humane" attitude - you don't have to let it run wild.

hhp

> [Flash is] an abominable means of displaying even modest amounts of text.

I really think all that's missing is a nice third-party licensable (or included in Flash) infrastructure, or "engine", where you could just dump in the text in, choose some parameters (like size, line length, etc.) and the textual navigation would pop up looking and working great. I think somebody actually made something like this in Java - in fact I think it was Bitstream.

hhp

confessed Refusenik:
OTOH I must admit that deep down I am pleased to see that there actually are some companies (well, one) out there devoting time, resources and money to the issue of web typography. Let's face it: it can only improve from where it stands right now.

On some level I agree, but the approach is terribly disheartening: a complex and expensive server-side application. I also have philosophical problems with MS regarding product activation and the like, not to mention security, but that's another can 'o worms.

confessed Refusenik:
Hands up all those who wouldn't love to use a different font on a web page in their lifetime. ;)

Me.sit('on=hands');

revealed Adriano Santi :
Actually, I tested their example pages with Firebird (Mozilla engine/Win32) and it popped up a dialogue asking me to install a plug-in. I chose not to install it and the text was then set in Times New Roman.

Interesting, as I'm using Firebird on OS X and got the following:

You are using a web browser that is unknown to this web server (it's identified as Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031026 Firebird/0.7), so these web pages may not look correct.

I can't really blame them, though, as Firebird has not yet hit final-release status. I can't say as I'd be terribly anxious to go chasing after beta-status browsers myself.

On Safari, I get the first page of the demo in all its glory, but with the 'GlyphGate Demo Pages', 'Welcome to the GlyphGate demo Pages!' and other text set as images

opined steve paxton:
Well, I think that's a highly dubious statement anyway given Netscape's buggines in terms of actually working ;)

Which version? NN4.x is an unholy mess, to be sure, and Netscape versions prior to 6.2 were beta-quality at best. However, I've been using Mozilla (the same 'guts' as NS, just without the AOL adware) since 0.9.4 and it's quite stable and acceptably fast. In fact, my SO uses Moz 1.0 on a 6-year-old Dell PII 266/160 MB and is quite happy with it.

Firebird on OS X has been a bit dodgier, but I've been using it on my Win2K laptop since the Phoenix days with nary a problem and speed-wise it's comparable to IE or even Opera.

And of course there's always the little matter of security.

further posited steve:
But that still takes longer than developing for just one browser, and testing is a much longer process. Unless you want to stick to really basic stuff (which is a good strategy, but one many clients don't want to know about).

It takes a bit longer, yes, but once you relegate NN4.x to the 'gets basic content + functionality' category it isn't so bad. In fact, if IE/Win were even as capable as IE 5+/Mac WRT CSS testing expense would be negligible. With the exception of heavy use of frames (generally a Bad Idea anyway) or hairy DHTML I find that pages tend to work first time out in Gecko-based browsers (Moz, Netscape, etc.), Safari, Opera 7 and IE 5+/Mac. Opera 5/6 typically boosts time by maybe 10% or so, IE/Win by 10-30% depending on what you're trying to do.

It also matters what you mean by 'support'. If you're still locked into thinking that the pages must look pixel-perfect across browsers (which it doesn't seem you are), supporting multiple browsers can be a PITA. If you realize that pixel-perfection is a fool's errand, things get easier in a hurry. With a little practice, methodology like Steve Champeon's ' progressive enhancement' makes supporting multiple browsers relatively painless.

observed steve:
Hey, so the real figure could be as much as even maybe 4 or 6% at a push. I can't imagine any client not wanting to throw money at that market sector.

I assume you're being sarcastic, but there are in fact sites that do take that percentage seriously. The creative director at the Economist is a regular over at WD-L and has explained many times that given their traffic levels, even 3-4% of their audience is large enough to warrant attention.

Even if it weren't, it isn't like we're talking about breaking the bank. It's mostly a matter of not doing things that are actively hostile to non-Windows or non-IE browsers (document.all and such) and not browser sniffing and locking non-Windows browsers out.

>>Hmm...I have infinitely more problems with IE crashing my PC than any flavor of Netscape or Mozilla

I didn't really mean crashing, I was referring to the way Netscape browsers deal with DHTML.

>>Do you charge your clients on a per-end-user rate?

No, but that's how they set their budgets.

>>Again, if you're designing for IE/PC only, then you're not making a web site. You're making an IE/PC site.

Well, I'm designing for an overwhelmingly IE/PC audience, but no, I don't design for IE/PC only, unless the clients insist on it. (Sometimes they do!)

queried steve:
Hmmm, interesting. You would know this from some other, more reliable type of statistic, then?

It was a Gartner or Forrester press release from about a year ago. I'm not finding the link just now. I can't vouch for their methodology as I didn't purchase the whole report, but generally they survey a scientifically-selected sample. Selecting the sample for statistical validity is itself an improvement over the typical general-interest web stats, which are usually compiled by a web log analysis outsourcing firm based on users visiting their client's sites. Those users may or may not be representative of the web as a whole.

qualified steve:
Well there are a few assumptions there.
1. That your stats are right in a general sense.

I have slightly more confidence in the Mac user demographics than I do in general Web stats because the latter are known to be flawed (see this MacEdition article for one example).

2. That I, or my client, has something for sale.

I don't know very many clients who don't. :-)

The big exceptions would be publication sites, which as I said tend to take an 'every last eyeball counts' approach, and government/education sites. In the U.S., U.K. and Germany, at least, the latter are covered by accessiblity laws that make the whole discussion moot.

3. That Mac users are the kind of people that want my clients product.

Yes, which is why I used 'may' rather than 'are'. :-)

I'm not sure what you mean by 'much larger', but it seems unlikely that a group which consists of roughly 3% of the total is going to contribute a 'much larger' contingent in any subset - unless I'm selling Mac software of course.

Well...say the Mac users account for just 6% of potential customers (those who would buy if they could). 6% doesn't sound like much, but boosting sales by 6% isn't something most companies would sneeze at. Wall Street tends to like that sort of growth, anyway, particularly when it comes with relatively little expenditure.

Remember that web site construction is typically a relatively small percentage of a company's costs. Even for an outfit like Amazon, which has no bricks-and-mortar stores, the biggest costs for them are inventory, shipping and so on, not the construction of the site itself.

Besides, what does being IE-only really get you in most cases? Some whizzy DHTML or other? Prettier text? Is there any research indicating that those things will add even 3% to total sales? Most of the big gains come from improving navigation, reducing page load time and the like

clarified steve paxton:
I didn't really mean crashing, I was referring to the way Netscape browsers deal with DHTML.

NN4.x wasn't that bad, so far as it went. It's DOM just wasn't as powerful as the MS or W3C DOM.

NS6+, OTOH, does very well with the W3C DOM, and IE 5+ Mac/Win isn't too shabby there either. There are sore spots, of course. IE doesn't implement the W3C's event model, for example, and NS's animation speed has been an achilles heel, though it has improved markedly in the last few revs.

It really depends on what you're doing.

asserted Hrant H Papazian:
Sure it costs more to do a two-tier solution*, and usually the expense is hard to justify, but I think it's not any harder than justifying good design in the first place.

Except the cost of a two-tier solution is deceptively high. It isn't just initial construction that is more expensive, it's maintenance too.

Even assuming the content is stored in a database and combined with templates at request- or publish-time, every time you want to redesign something on the site, add some new functionality or alter the structure (adding a new section/subsection, for example) you've got to do it twice. You've also got twice as much (OK, probably more like 140-170% as much, but still) code where things can go wrong.

You're also setting up a false dichotomy here: neither IE/Win nor 'everything else' is monolithic. IE 5 <> IE 5.5 <> IE 6. They're closer in many respects than, say, IE 5/Win and IE 5/Mac, but the differences are still significant enough to warrant testing. So you're testing regardless. Likewise, 'everything else' includes everything from Mozilla to PocketIE on a cell phone. Those browsers have vastly different capabilities. Either you need to serve them straight-up HTML 2.0 (no tables, no CSS, no JavaScript, etc.) or you're back to testing and 'progressive enhancement' again.

And then, of course, there's the question of what, exactly, is 'good design' in the first place. Is it really 'good' to take an approach contrary to the fundamental purpose of the medium (non-discriminatory access to information)?

analogized Hrant:
The web is like a pet: you can't control it totally, but you can train it a lot with the right pragmatic and "humane" attitude - you don't have to let it run wild.

I disagree slightly: the web is more like a child than a pet; you can try to instill the right values in it, but in the end it leaves you and goes into the broader word where it is entirely beyond your conrol.

Remember how the web works: when you go to a site, you aren't looking at something that lives somewhere else, you're looking at a copy of that something that has been made on your local HD, complete with source code. Once that copy hits the user's browser, all bets are off. They can resize the text. They can zoom the whole page. They can turn off JavaScript, plugins, images and CSS. They can even gasp use their own stylesheets with 18px/18px Comic Sans if they so choose.

As a wise man once said "the control you have is proportional to the control you relinquish."

Indeed.

OK ... Awesome responses! Thanks all.

First, Hrant, about Flash. We want to avoid it for content. We are cool using it for some simple navagation, but we want to keep the site content in HTML to make it easy to search and easy to update.

Second, as to the designer I am working with - well he is prez of our studio and cut his teeth in print. I agree that he should just get over the control issue, but with everything, life is never that simple. I am moving him toward the right mindset for this project, but I can't just make demands here. Sigh.

I think WEFT is a cool idea, but not worth the effort. If we still have to account for variations in text we might as well just go simple and worry about other aspects of the site.

> the cost of a two-tier solution is deceptively high.

So is hiring a designer. Just do it in-house! :-/

> Is it really 'good' to take an approach contrary
> to the fundamental purpose of the medium

This is not a religion (or at least it shouldn't be - we have enough of those).

As far as our clients ar concerned, the "fundamental purpose of the medium" is to make more money, so "good design" is merely what increases material wealth. To me though it's about maximizing the cultural benefit of a tool, with a pragmatic -not a fundamentalist- mentality as to how to achieve that. Hacking rules, and "elegance" is a succubus.

hhp

postulated Hrant H Papazian:
I really think all that's missing is a nice third-party licensable (or included in Flash) infrastructure, or "engine", where you could just dump in the text in, choose some parameters (like size, line length, etc.) and the textual navigation would pop up looking and working great. I think somebody actually made something like this in Java - in fact I think it was Bitstream.

I have concerns about licencing a text display widget in an era when web sites with budgets in excess of US$5-10K are few and far between. I don't see it getting used much, to be honest.

That aside, your theory here sounds a little like the old /. joke:

1. Develop widget
2. ???
3. Profit!

What we've got here is the dreaded SMOP (Simple Matter Of Programming), which as most developers will tell you is often anything but simple.

I probably spend as much time reading on-screen as anyone (often 8-12 hrs./day), but I really don't like it as much as old-fashioned dead-tree text. The reasons are fairly obvious:

1. limited layout options
2. limited font choices
3. can't as easily see where one is in the text
4. you typically see less text at a time, so scanning about the page requires scrolling rather than just moving one's eyes
5. mousing + clicking is slower and clumsier than thumbing for moving back and forth to reread, compare and contrast
6. cannot hilight passages
7. relative discomfort of viewing emissive vs. reflective media for extended periods
8. being tethered to a desk or a laptop (the latter isn't as handy as a book, not even the thin'n'light varieties)
9. cannot dogear pages
10. redraw times are infinitely greater online (books have none)
11. high entry cost (price of a computer + 'Net connection vs. price of a book/magazine)
12. poor text rendering

The unique advantages of online text balance the equation for short- to medium-length texts:

1. Low incremental cost (even paid sites are typically cheaper than a magazine subscription)
2. Easy storage (a hard drive is smaller and holds a lot more than a bookshelf)
3. Portability (a laptop is easier to carry than a library)
4. Ubiquity (easier to find a phone jack or wireless hotspot than to find an adequate library/bookstore in many areas)
5. Automatic updates
6. Ease of copying
7. Internal searchability (the 'find' command)
8. External searchability (search engines like Google)
9. Easy cross-referencing (copy/paste into Google, M-W.com, etc.)

There are also a few things that a browser does to mitigate the disadvantages of online reading:

1. ability to resize text (text/page zoom)
2. proportional scrollbars
3. scroll wheel/arrow keys for moving around a page
4. keyboard accelerators for forward/back, links, etc.
5. bookmarks
6. ability reflow text (changing browser width)

Now, going through the disadvantages of online text, which ones does Flash address? Flash allows better layout control (point one) and a far wider selection of fonts (point two). Two points for Flash.

Flash neither hurts nor helps with respect to points 3-9. No score.

However, Flash does hurt us with respect to point 10: OS + Browser is always going to be faster than OS + Browser + Flash. Flash imposes some overhead, no way around it. Likewise, one needs a newer, more powerful computer to have an acceptable experience browsing a Flash page than browsing HTML, so it hurts again on point 11. On point 12, Flash's rendering of small text is notably inferior to OS X's native rendering, and I'll take your word that WinXP's antialiasing is better than OS X's, so Flash looses this one. Score 3 for HTML.

Now let's look at the advantages of online text. Flash has no effect whatever on points 1-4, so those are a draw.

Assuming proper authoring, updates in Flash can be more or less as simple as updating HTML (the text needs to be drawn in from a file on the server or similar), so we'll give it point 5. Likewise, it's possible to save an .swf file to your HD just as you can an HTML page, so point 6 is a draw as well. I have never seen any implementation of a 'find' command in Flash, but it shouldn't be that difficult to implement, so we'll give it point 7 as well. Point 8, external searchability, is a well-known problem with Flash. Theoretically, at least, one could include the text in a 'hidden' <div> or similar to enable searching so I'll give you that point, too. Likewise, I've never met a Flash page that allowed me to copy a text snippet, but IIRC there is a particular sort of text that can be used (the name escapes me) that makes the text editable, and that text could allow copy/paste, so I'll concede point 9. Another draw, but only after an awful lot of hand-waving.

Last, we'll look at the things browsers do to mitigate the problems with online text. Flash allows users to zoom, and we'll concede that your widget gives us proportional scroll bars, scroll wheel/arrow keys and keyboard accelerators. No score.

Bookmarking is another well-known problem with Flash, but we'll wave our hands some more and say each page could be a separate movie or that there is some mechanism for bookmarking within a Flash movie of which I am unaware. So a draw on point 5.

On point 6, Flash zooms to fit the screen, but doesn't reflow. If for whatever reason I've got a narrower display area than you anticipate, I'm screwed. Still, there may be a way to automagically determine the width of a Flash movie and reflow the text to accommodate it. Let's wave our hands and call it a draw.

Final score: Flash 2, HTML 3, and *lots* of hand waving going on to get there. Notably, I haven't used Flash since v. 5 so I'm just assuming that there is some way to get a movie's dimensions at run time and that the editable text cast member can use an arbitrary font that isn't installed on the end user's system (my recollection is that it could not as of v. 5). Futher, to solve both the external searchability problem and the bookmarking problem we need to rely on techniques that will exacerbate the performance and entry-price problems. As well, I glossed over another issue: we need to license this widget, which means our costs for producing content go up, which in turn means incremental costs (cost per new page of text) will probably need to reflect that somewhat mitigating one of online text's advantages.

Call me crazy, but it seems to me that right now, today, even with a whole lotta benefit of the doubt and assuming a widget that doesn't exist, Flash is still inferior to HTML for reading more than small bits of text. Seems to me efforts at improving online reading would be better focused on a base of HTML rather than on Flash.

"You are using a web browser that is unknown to this web server"

Which is the problem with browser detection. At least this detector was smart enough to say 'I don't know what you are using, but if you think it's OK, go ahead and look at the site...'

"I didn't really mean crashing, I was referring to the way Netscape browsers deal with DHTML."

Oh...I think you're referring to NN4. No argument there that's a crappy piece of software. I tend to serve NN4 the plain-jane text of a site. It's not pretty, but they get all the content.

As other's have mentioned, Flash really isn't the web. Flash is it's own thing, and can often compliment a web page, but using flash *as* the web page is often (though certainly not always) a bad thing. Even Macromedia is realizing that and is finally pushing Flash outside the browser, where I think it will actually do quite nicely.

Bottom line, use flash when it makes sense. Using it because it is 'easier' to get the exact visual design 'you' (the author) wants isn't usually a valid argument.

oh...and just to take it back to typography on the web, the key is to realize what the priority for the site actually is.

The exact typeface used probably shouldn't be a high priority. A nice luxury if you can get to it, but there are so many other variables that go into a succesful site that should be addressed first.

sniped Hrant H Papazian:
So is hiring a designer. Just do it in-house! :-/

In 7+ years of web development I've never once gotten a call from an irate CEO at 11 p.m. on a Friday night saying a designer was preventing his mother-in-law from accessing the site with her iMac. I cannot say the same for browser-sniffing widgets.

Perhaps you know a different sort of designer.

As far as our clients ar concerned, the "fundamental purpose of the medium" is to make more money, so "good design" is merely what increases material wealth.

Very good. Now, which is going to do more to increase material wealth: spending $X on browser testing to see that 3-8% more visitors get the branding, UI, etc. rather than a circa-1995 grey background'n'Times mess or spending $X on a two-tier system to ensure that IE/Win users get to see 12px-on-14px Bookman Old Style instead of 1em-on-1.2em Georgia? And what of the X% of Win/IE users who can't read that 12px-high text because they're near sighted? Or the Y% who decide to override your font choices just because they feel like it? Or the Z% of IE/Win users who have the contents of the page read to them via a screen reader and don't see that lovely type anyway (and won't get anything at all without non-trivial extra effort/expense if you're using Flash)?

To me though it's about maximizing the cultural benefit of a tool, with a pragmatic -not a fundamentalist- mentality as to how to achieve that.

And how does serving unstyled pages to everyone not using IE/WIn maximize 'cultural benefit'?

If playing to the strengths of the medium is somehow 'fundamentalist', then pass the bible 'cause I'm in a thumpin' mood.

Your approach is rather like trying to turn a pickup truck into a sports car. Yeah, you can hop up the motor, rework the suspension, add new breaks, wheels and tires...hell, you could slap the pickup body on a Corvette chassis if you like (I've seen it done), but at the end of the day what you have is a hopped-up pickup that will get spanked by a cheaper off-the-showroom-floor 'Vette at the racetrack and is far worse at hauling cargo, towing trailers or driving offroad than it was to start with. If what you want is a vehicle for hauling cargo that also has good road manners, you buy a BMW or Volvo station wagon. Maybe it won't quite run with the hotrod truck or the 'Vette, but it's cheaper and more utilitarian, not to mention more economical to own and maintain.

Flash is the 'Vette, your two-tier solution is the hotrod truck and a browser-tested CSS solution is the wagon.

Thing is, if you bother to learn CSS et all well, you can get 90%+ of the nifty presentation you would from your two-tier system out of a one-tier system that will be easier to maintain and expand, quicker to download, and more accessible to a wider audience to boot.

Sounds pretty pragmatic to me.

setmajer, it's great to see you've put a lot of thought into this stuff.

> Flash's rendering of small text is notably inferior to OS X's native rendering

Not really. Flash can render the highest form of text (handmade grayscale bitmaps) more reliably than MacOS (and even Windows) can. Flash also has the advantage of allowing kerning - very important for onscreen readability (and legibility). HTML doesn't kern (does it)? The grayscale bitmap font I'm finishing up has over 600 pairs just within the alphabetics (although only about 10% are likely to show up in normal text), and it's only a sans!

I'm not saying Flash is ready for prime-time in terms of extended reading, but I do think (not least by observing the wanton behavior of the OS/app makers) that it has more potential than HTML.

> improving online reading would be better focused on a base of HTML

The main problem with that is that with HTML you're relying on the OS, and neither of the two major OSes (if you can call 5% market share "major"...) can deliver handmade grayscale bitmap fonts as well as Flash. They just don't care enough.

> I've never once gotten a call from an irate CEO ....

Ah, but you've also not gotten calls from clients who decided never to contact you in the first place. That's my point. Flash enables a level of design greater than HTML (elbeit flawed in some [important] ways), and that helps justify your existence as a designer.

> which is going to do more to increase material wealth: spending ....

And by the same logic: Which saves more money, hiring a designer or doing it yourself?

> how does serving unstyled pages to everyone not using IE/WIn maximize 'cultural benefit'?

Design is the artful balance of compromises.
Trying to make everbody equally happy just makes everybody more miserable.

> If playing to the strengths of the medium is somehow 'fundamentalist',
> then pass the bible 'cause I'm in a thumpin' mood.

But if it means ignoring its weaknesses, and trying to achieve some sort of "purity", then that's not design, that's art. My approach is getting to the destination in that jalopy as fast as possible without taking undue risks. Tellingly, my actual car is an '87 BMW.

> CSS

That's just code representing a de facto a two-tier system.

hhp

Just a quick update on font extraction from EOT:
After some asking around and some actual testing, it seems that it's not at all trivial to swipe fonts from an EOT page. Although the fonts are indeed saved as individual files in the browser's cache, there's no obvious way of making them work as fonts on their own. I guess it's possible to decipher (or swipe) the encryption MS seems to be using on the font files, and provide a utility to bring them back to TT (or PS), but I don't see anybody going to that trouble. Fonts are much easier to swipe otherwise.

hhp

informed Hrant H Papazian:
Not really. Flash can render the highest form of text (handmade grayscale bitmaps) more reliably than MacOS (and even Windows) can.

Is there an example somewhere? The tutorials on this site apparently do not use them, because the text looks like •••.

Taking your word that they're noticeably better than native OS X/WinXP text at the designed size (it does make sense), how good are they if you zoom them in Flash? Better, worse or about the same as zoomed outline fonts?

As well, we're adding to our incremental costs again, and I don't believe these greyscale bitmaps are in terribly wide use.

Regardless, I'll give you the point with the caveat that there's some more hand-waving going on here. So it's still 2-2, even up, and lots of hand-waving to get there.

Flash also has the advantage of allowing kerning - very important for onscreen readability (and legibility).

Important, yes, but it's an incremental improvement. I'd vote for higher-resolution displays, reflective displays (for extended reading, at least) or even annotation/highlighting capabilities before I'd go after kerning.

HTML doesn't kern (does it)?

You mean hand-kerning? Not really. You can hack it by wrapping the problem pair in a <span> and using the letter-spacing property to adjust the space, but it's crude and probably not worth the effort for anything other than an egregious headline boner (not that I expect many people take the time to hand-kern body copy even in print). Even there, given the differences in text rendering between platforms and unreliable fonts I'd say it would likely do more harm than good.

If you mean automagic kerning based on the kerning pairs specified in the font, that would be an OS-level issue. Honestly, I don't know if OS X does or not as it's not terribly obvious which nasty pairs in the text above are due to lack of kerning and which are due to the coarse pixel grid.

I'm not saying Flash is ready for prime-time in terms of extended reading, but I do think (not least by observing the wanton behavior of the OS/app makers) that it has more potential than HTML.

Based on MM's progress so far? I don't know. They seem pretty focused on making Flash the app development platform Director could be but isn't (due to underpromotion as much as anything, really; it's far more capable than Flash as a programming environment).

As well, there's SVG floating around out there. The SVG-RCC bit allows you to map arbitrary XML elements to an SVG display, which would in theory allow you to add vector fonts to XHTML elements. It's still at the Working Draft stage, though.

And of course there's XAML, MS's Flash/SVG/HTML/DOM/CSS killer-to be. By the time Longhorn hits, &deity; only knows what text will look like in that or where OS X text rendering will be. In principal, OS X uses display PDF, so there's really no reason it shouldn't have at least as much sophistication as Flash.

Ah, but you've also not gotten calls from clients who decided never to contact you in the first place. That's my point.

So you're talking wow-em portfolio showpieces? Sure, Flash allows some brilliant stuff in that area. No contest there.

I'm talking production sites

> how good are they if you zoom them in Flash?

Since pixelfonts (1-bit or grayscale) are built with funky outlines (to map to the screen pixels correctly), zooming destroys them. What you can do is detect the zoom level and sub another font that renders well at that magnification. But a user who zooms in isn't worried about readability (unless the Flash stuff is badly designed and the text is too small).

> I don't believe these greyscale bitmaps are in terribly wide use.

Because they're not available yet (at least not in a form most people would like to use). Yet.

> I'd vote for higher-resolution displays, reflective displays (for extended reading, at
> least) or even annotation/highlighting capabilities before I'd go after kerning.

Except those really are not available!
Kerning is available - just not in HTML.

> You mean hand-kerning?

Huh? I mean that the kerning in a font is ignored by HTML.

> If you mean automagic kerning based on the kerning pairs
> specified in the font, that would be an OS-level issue.

No, because the OS conveys kerns just fine - how else would Word be able to use them?
BTW, it's not automagic at all - we spend a lot of time doing kerning right! :-)

> Based on MM's progress so far?

No, based on the fact that they provide a flexible tool that an individual (with no shareholders to mind the bottom line) can use to develop some real onscreen text display. HTML doesn't.

> So you're talking wow-em portfolio showpieces?

No, I was trying to say that Flash gives designers more reason to exist. The clients of yours who have complained to you about browser-sniffing but not about the access are outnumbered by the clients (or actually non-clients) who didn't bother hiring a designer in the first place.

The arguments you use to win clients are the same for using Flash instead of HTML.

> .... one site, properly built ....

A properly built site takes as much advantage of the differences in user setups as budget allows.

> CSS doesn't do that at all.

Then it's not enough, at least not all of the time.

hhp

informed Hrant H Papazian:
Since pixelfonts (1-bit or grayscale) are built with funky outlines (to map to the screen pixels correctly), zooming destroys them. What you can do is detect the zoom level and sub another font that renders well at that magnification. But a user who zooms in isn't worried about readability (unless the Flash stuff is badly designed and the text is too small).

That's precisely why users may want to zoom in. And 'too small' is subjective. On my screen for my eyes the text in this forum is at the bottom edge of comfortable legibility. For my GF, it's a shade too small. For my aunt, it's illegible. That's one of the bonuses of online text: no need for large-print editions. Flexible text size is a nicer solution, at least as far as the sort of ephemeral, moderate-length text people tend to read online. The violence done to line length by resizing the text might be too much for longer texts, but by then you've got bigger problems (eye fatigue from staring at an emissive display, for example).

I mean that the kerning in a font is ignored by HTML.

Vocabulary-check time. HTML is a markup language for describing the structure of a document. It really does nothing in terms of rendering a document to the screen. It just says "this is a 'p', this is an 'h1' and that's an 'li'". The browser then interprets those tags (typically as a paragraph, a level-1 heading and a list item, respectively) and applies formatting based on internal style rules. If it groks CSS, it will override those internal rules according to the rules specified in the stylesheet, if any.

The little presentational candies (font tags, color and border attributes and suchlike) are corruptions introduced by Netscape back before CSS was a working draft, and are slowly being deprecated out. They really shouldn't have been there in the first place, but are and are still in wide use despite their drawbacks WRT bandwidth consumption, maintainability, etc.

The point of HTML was that it could be viewed using a wide range of clients running on a wide range of devices: text browsers running on green sreen terminals, graphical browsers running on a PC, audio browsers running on a phone and so on. Fine points of display were intentionally left out because there was no way for an author to know whether the reader's device would even be capable of displaying multiple fonts or even boldface, let alone kerning and the like.

CSS is a style language. It's entire raison d'etre is to define the look of a page. One of the design goals was to make it device-independant, so that the same style language could be used to style a document intended for a PC screen, for print, for a cell phone, etc. It is interpreted by the client application (a web browser, most commonly), which then applies the rules it understands and ignores those it doesn't.

Neither HTML nor CSS is responsible for rendering the output; that's the browser's job. As I understand it, browsers typically use OS-specific drawing routines to actually produce the page. Leastwise, that's the only way I can explain why Firebird gets OS X's system-wide anti-aliasing.

No, because the OS conveys kerns just fine - how else would Word be able to use them?

Does Word display kerns in online text? I honestly don't know. I just know that on OS X at least, Word text is by far worse than text in Safari, Firebird, Flash, Acrobat, Illustrator...just about anything other than FreeHand with antialiasing turned off (which is hands-down the worst of all). If it does display kerns, you'd never know it. The text is that bad.

It would actually surprise me if IE/Win didn't display kerns but Word did (my Win2K version of IE displays old-skool aliased text), as I'd expect them to use the same library for rendering text given how intertwined with the OS both are.

To be perfectly honest, I'm not exactly sure how all the interaction between a font, an app and the OS plays out; that's a bit lower-level than I typically go. I do know that neither HTML nor CSS was ever intended to get quite down to that level

> That's precisely why users may want to zoom in.

The interface should disable the Flash zoom and provide an intelligent way of size change.

> Neither HTML nor CSS is responsible for rendering the output; that's the browser's job.

You're right, that's what I meant.
Anyway, the OS has the kerning available, but browsers seem to ignore it.

> you spend lots of time doing the kerning tables

Kerning: defining pairs of letters and saying how much they should be moved closer or further way.

> what does Flash provide that the browser doesn't?
> Embeddable fonts, kerning and better layout control?

Well, exactly!
Intent, shmintent - I want results.

> either class outnumbers those who can be convinced to spend extra money for kerning.

But the point is that with Flash you don't have to convince anybody: you put kerning in your font, and it works.

> Could you explain how that argument supports splitting the audience into two monolithic camps

Cost-effectiveness.
But if the product/service is Mac-centric, then the tactics -but not the strategy- need to change.

> Neither is Flash.

But Flash has much more potential for improvement, exactly because it's a tool in the hands of (non-bottom-line-obsessed) individuals, unlike the browsers.

hhp

I just wanted to make two comments:

WEFT: It was at one time really easy to rip off WEFT fonts if you were viewing the page as an end user. This was what I based my comments on. However, this appears to be no longer the case, which is a good thing. Similarly, fonts in PDF are less easy to rip off than they once were (not that I'm claiming they're "secure," just a bit less insecure).

HTML: There is absolutely no reason that a web browser can't display HTML using the built-in kerning in the font you're viewing in (if there is any), except that it chooses not to. (The HTML text itself doesn't have to indicate kerning any more than plain text does. Place a plain text file in a DTP app, and it will have kerning.)

T