Did anybody ever have negative rendering experiences with TrueType-flavoured webfonts that have overlapping components (Ç) for the sake of file size reduction?
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.
@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 ...
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...
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.
"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. ;)
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.]
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.
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.
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.
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.
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.
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?
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.
9 May 2012 — 12:15pm
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.
9 May 2012 — 12:42pm
It's been safe on Windows for a while now. Overlapping of decomposed outlines should be avoided, but overlapping of components is okay.
9 May 2012 — 1:48pm
John, I'm not getting the difference.
hhp
9 May 2012 — 2:14pm
I’m experimenting with this: http://www.flickr.com/photos/56183109@N02/6970925362/in/photostream
9 May 2012 — 2:16pm
But then again, I’m a crazy ****.
9 May 2012 — 2:46pm
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
9 May 2012 — 3:47pm
@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
9 May 2012 — 4:05pm
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
9 May 2012 — 4:11pm
Side note: The ø should **never** reuse the slash, despite its international name.
9 May 2012 — 8:30pm
@frode Yes. I only used that as a graphically clear example.
10 May 2012 — 3:44pm
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
11 May 2012 — 3:03am
"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. ;)
11 May 2012 — 10:40am
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.]
12 May 2012 — 3:13am
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).
14 May 2012 — 1:52pm
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.
14 May 2012 — 2:08pm
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.
14 May 2012 — 6:05pm
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.
15 May 2012 — 5:48am
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.
15 May 2012 — 8:48am
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.
15 May 2012 — 11:17am
I hope that doesn't mean Apple is planning on resolutions going so high that even anti-aliasing won't be needed... :-)
hhp
15 May 2012 — 11:08am
Is that TT or PS? Btw, for text that is more than safe.
15 May 2012 — 11:08am
@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
15 May 2012 — 1:26pm
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?
15 May 2012 — 10:29pm
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 :)
18 May 2012 — 4:47pm
@Goran
Is anybody going to NOT see that it's an Aring? And don't let one edge case make you nervous. Relax.
18 May 2012 — 5:04pm
YEAH! And why are you bothering with those damn-fangled accent thingies in the first place? Relax.
hhp
19 May 2012 — 9:26am
@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.
19 May 2012 — 9:12am
@frode
It’s TT.
19 May 2012 — 9:21am
I was being sarcastic.
http://www.flickr.com/photos/48413419@N00/347980079
hhp
19 May 2012 — 9:26am
@hrant
Ok, sorry I didn’t get that after first reading Richards answer.