Haven't done any real investigation, but I did exactly that it (at first) on a recent project but on some Macs, you could spot a really small thin line where the outline met the outline, so I’d say it’s not safe. It didn't
look like Postscript fonts where the overlap made a white “cut”, it was very subtle.

On the other hand I’ve heard people saying it should work. Perhaps it’s safe on Windows or older systems? Dunno.

It's been safe on Windows for a while now. Overlapping of decomposed outlines should be avoided, but overlapping of components is okay.

John, I'm not getting the difference.

hhp

I’m experimenting with this: http://www.flickr.com/photos/56183109@N02/6970925362/in/photostream

But then again, I’m a crazy ****.

No. Haven't had any problems with overlapping components.
And have done quite a bit of it and well tested, too.

Richard Fink
Blog: Readable Web
Font Director: Kernest/Konstellations

@hrant - Components mean that the glyph outlines aren't defined in that character position, but are created by referring to other positions. If you 'decompose' such a glyph, the outlines are now in their character's position. For example, the O-slash position could have pointers to the 'O' and the 'Slash' (component) or it could have the outlines right there (decomposed). There's a slight saving in file size using components; I believe that they must be decomposed before creating an open type font.

Now why rendering agents should display them differently, I have no idea. Possibly something to do with the rendering sequence, or outline directions, or conflicting hinting, or ... or ...

- Herb

Got it. But why ever leave overlapping outlines in the position? For one thing they take up more room than the overlap-removed one. So I assume Yanone is talking about referred components.

Also:
- I assume the rendering varies because for referred components each glyph is rasterized individually, then the bitmaps are merged. If so, that means it's slower than rendering a single outline-merged glyph. So you're trading rendering speed for download speed.
- Component referral only saves space if you use a component enough times (which might be as low as three, or even two, depending). For something like the cedilla there's probably no contest, but for the slash, I wonder.
- A problem with referred components -especially overlapping ones, and in darker weights- is that there's no opportunity for modulation. For example the lower curve of the /C/c should get thinner when a cedilla is attached. Then there's the ogonek, which likes to affect the base glyph bigtime...

hhp

Side note: The ø should **never** reuse the slash, despite its international name.

@frode Yes. I only used that as a graphically clear example.

One major reason to avoid this for desktop fonts was that if an end user strokes the outline of the glyphs, they get undesirable results from overlapping components.

Of course, given a greatly increased concern with file size, that might change the balance of priorities.

T

"Now why rendering agents should display them differently, I have no idea..."

The parts of a component are rendered to bitmaps separately and then the bitmaps are combined. Overlapping bitmaps are not a problem. Overlapping contours require the rendering to figure out the overlap and present a bitmap.

"For one thing they take up more room than the overlap-removed one..."

Plus.... a landscape oriented rectangle and a portrait oriented rectangle overlap and use 8 points and 10 hints. Remove overlap and you have 12 points and 14 hints.

"...if an end user strokes the outline of the glyphs, they get undesirable results from overlapping components."

Not in Cooltype or any other savvy app. You Occidentals don't know squat about overlapping issues. ;)

David: Not in Cooltype or any other savvy app.

Hmm. I recall seeing some intelligent stroke outlining in Adobe apps previously, but when I tested this today in InDesign CS5.5 ME, these are the results I got:

[Top: Adobe Arabic, showing overlaps of joining glyphs; bottom: Segoe UI showing overlaping components in a single glyph.]

Works here. Input TT glyph on left. Screen rendering of same glyph on right.

CS 3 5.0.3, (Mac of course).

(don't know if the png will show up).

I wrote: "...if an end user strokes the outline of the glyphs, they get undesirable results from overlapping components."

DB replied: Not in Cooltype or any other savvy app.

Well, I've seen it, John has shown it, and it was at Adobe, where they make CoolType, that I both saw it and was taught about it being a problem. That was why they never allowed overlapping outlines in their western fonts.

Of course it is unavoidable for connected fonts, whether they are Arabic, Indic, or western connected script fonts. But that doesn't mean it shouldn't be avoided where practical.

Thomas,

The overlapping is only unavoidable if the outline is centered on the glyph’s periphery. In applications which allow you to place the outline behind the glyph, the problem disappears.

TP: "...that I both saw it and was taught about it being a problem."

They taught about overlapping TT at Adobe?

The TT spec allows overlapping contours and components from 1.0, and the only experience I've had where that didn't render properly was corrected by Apple in their iOS about two years ago, partly, I was told, because there isn't any software on the web that renders "western fonts" differently from "eastern fonts", and Apple has a lot of eastern fonts that follow the TT spec.

Besides all that, last time I tried to stroke and fill a live font on the web, the support was so inconsistent, forgetting about the overlap issue, that I had to include SVG and graphics to make my presentation show up on all browsers.

(don't know if the png will show up).

David — The png format itself should show up fine; but you included an ampersand in your file name, which will not work with the system. So, your image got lost somewhere on the server. If you rename the image with only alphanumeric characters, you can re-upload it and then it should work.

Here is Aring with two overlapping components in Safari, OSX Lion..

(If you don’t see it first, look again)

You can also see it live here:
http://www.impallari.com/testing/

Click the “Latin” and take a look at glyphs with overlapping components. The default Times version have same issues on my computer, just like my example.

So, I consider it not safe.

I hope that doesn't mean Apple is planning on resolutions going so high that even anti-aliasing won't be needed... :-)

hhp

Is that TT or PS? Btw, for text that is more than safe.

@Goran Soderstrom:

The Aring example you're showing is a bug of some kind and bugs get fixed.
Is it happening with every font you try?

I've looked at hundreds of different fonts using overlapping components on Mac platforms and have never seen this.
(And as rendering weirdness goes, it's not even that bad, IMHO.)
Certainly not enough for me to avoid TT fonts with overlapping components and/or actual outlines.

I haven't seen a problem yet, except for the one you're presenting.

Rich

GS: "So, I consider it not safe."

That's the OS with a bug that I think shows up in older Apple apps and not in others that have revved. I can show it in Fontbook and Textedit, but not Keynote or Safari. Can you show it in Safari?

I’m running OSX 10.7.3 and this shows up in Safari and FireFox on my newest MacBook. It also was visible on my older Mac with that other cat system.

Perhaps it’s a bug but it’s there :)

@Goran

Is anybody going to NOT see that it's an Aring? And don't let one edge case make you nervous. Relax.

YEAH! And why are you bothering with those damn-fangled accent thingies in the first place? Relax.

hhp

@Richard and hrant

We have a different way of thinking about quality – what it is – how it looks – and how to present it to people who license fonts if that’s your answer.

And you certainly do not know the swedish language.

Bye now.

@frode

It’s TT.

I was being sarcastic.
http://www.flickr.com/photos/48413419@N00/347980079

hhp

@hrant

Ok, sorry I didn’t get that after first reading Richards answer.