iOS Postscript font bug

Frode Bo Helland's picture

Hi,

I’ve come across a bug in iOS causing rendering errors with Postscript flavoured fonts. Some characters are rendered lighter than others in landscape mode (subpixels), but when you zoom in or switch to portrait mode (greyscale) they appear correctly again. Tim Brown (edit: Tim Ahrens) over at Typekit looked into the issue with the font in question (I’ve only tested Mobile Safari on iPad, but Tim also sees these problems on the iPod):


I think you have discovered a rather weird bug in the iOS type rendering engine. I can reproduce this and have tried to figure out what exactly it is that causes the problem. It must be in the actual outline drawings of the letters in question, not the hinting, features or any other font metadata.
It seems that the rasterizer is not 100% numerically stable and runs into problems when certain constellations of nodes and BCPs occur. It is difficult to pin down exactly what these constellations are, which is not too surprising considering it is a bug.
I had a closer look at the v, which rendered strangely on my iPod. After a bit of playing around, it turned out that tweaking one curve is enough to make it render correctly (see the arrow on the attached image). Looking at this example, and how the other glyphs are drawn, I suspect that it could be related to "retracted" BCPs, although in some cases, they don't seem to cause any problems. I personally also work with retracted BCPs a lot and I am not aware of any rule or convention that forbids this. That said, the only fix I can think of right now would be to "extract" the BCPs.

Have anyone else experience this? Can someone shed any light?

Frode Bo Helland's picture

A close up of the outlines. Disclaimer: This is a slightly different variant, but uses the same basic node set-up.

hrant's picture

Having BCPs on both ends of a curve is indeed
good practice, I guess because some renderers
assume that's the way it has to be. Annoying.

BTW, holding down Shift-Alt while clicking a
"half-dead" curve makes FL add/balance the
BCPs, although it usually needs tweaking.

hhp

Sindre's picture

Hmm... I've had a closer look at the font in question. All horizontal serifs have the same BCP configuration, like the 'v' in the close-up here, while only the diagonals have the rendering problems, right? That makes no sense at all, does it?

I think it's a highly unsatisfactory solution having to redefine all the serifs because of this, as this practice is not in any way non-standard. (At least, Font Audit does not think it is.) People need to write better renderers.

eliason's picture

Tangential FontLab question:
Is there a modifier key or other method for grabbing such a fully-retracted handle? I'm used to option-click-and-drag to drag a handle out of a node that doesn't already have one, but if the node has a handle right on top, this sometimes doesn't work to grab it--it will often the node instead and leave the handle behind.

Sindre's picture

Hmm, I've thought that too, Craig, but isn't that behaviour only typical when you drag the mouse the wrong way, that is in the direction of the extended handle, by mistake? I didn't know about the method Hrant mentioned, but it works very well, though it changes the curve somewhat (but probably often for the better).

hrant's picture

Due credit: I learned about it from Nina,
who I think got it from the FontFont boys.

It's a damn shame we have to do that,
not least because "half-dead" curves are
actually much more natural to modify.

hhp

hrant's picture

BTW, you know you have some other "issues" there, right?
Like missing inflection points, and "crossing projection" BCPs.

hhp

Sindre's picture

Well, to be honest, no. Font Audit makes no red arrow, so I've done that now and then in Satyr, but perhaps I shouldn't trust Font Audit on that. I like to draw that way, but I guess I should insert inflection points. I just like to use as few as possible, as Satyr lacks lines, changes become more manageable that way.

hrant's picture

Actually those two things FontAudit is supposed to catch...

And yes, as with half-dead curves, explicit
inflection points should go in as late as
possible, even after [any] trapping.

hhp

Jens Kutilek's picture

»Half-dead curves«, I love that term :) We call them in-point bezier control points, quite prosaicly.

We advise to avoid them because they will lead to distortions and extra points being inserted when the curves are converted to TTF:

The PS curve is in the mask.

FontAudit isn't very reliable. Some of the things it does find are more design hints than technical errors, and it doesn't find more severe errors like half-dead curves or self-intersecting outlines.

nina's picture

"Due credit: I learned about it from Nina, who I think got it from the FontFont boys."

Wait, what? I got the «avoid in-point BCPs» rule from the FF boys (hello Jens!). The Alt-Shift-click technique was something I found more or less by accident while playing around in FL. I think what it does is make the curve [more] symmetrical, which isn't always what's needed. I basically ended up correcting all of my «half-dead curves» manually. :-\

k.l.'s picture

Frode (citing Tim Brown) – I suspect that it could be related to "retracted" BCPs

hhp – Having BCPs on both ends of a curve is indeed good practice

Jens – We advise to avoid them because they will lead to distortions and extra points being inserted when the curves are converted to TTF

While you are not saying this explicitly, your comments can be read as "it's a font quality issue that needs to be address on font level" which would be the wrong message. Type designers and font producers cannot, and should not, offer workaround for all other parties' faults.
If certain point constellations cause rasterization issues, it is a rasterizer bug which needs to be fixed. (Hello Apple.)
If they cause issues with cubic to quadratic bezier conversion in one or another font editor, then the conversion mechanism needs to – and can – be fixed. (Hello FontLab.)

Frode Bo Helland's picture

I agree. This is an Apple issue. I couldn't report a bug without a dev account. Any Apple people lurking here?

hrant's picture

> I found more or less by accident

Ah, sorry, my memory failed!

> Type designers and font producers cannot, and should
> not, offer workaround for all other parties' faults.

Cannot: Why not? Well, not all, but as many as possible.
Should not: Who pays for that? The user... who then
blames you and moves on to a font that "just works".

The best designers assimilate problems.

> This is an Apple issue.

This might seem atypical coming from
me, but you can't only blame Apple here.

hhp

k.l.'s picture

You don't expect a reply to that, do you?

hrant's picture

It doesn't matter what I expect. Just do what
you think is right. On my end I'm likely to
benefit from a reply, since my purpose here
remains to learn, and I'm sure you can teach
me things.

--

Who benefits when one refuses to tweak
curves that expose a flaw in a renderer?
How much time are you saving? And what
are the chances a large corporation will
care enough (beyond its own products,
which it can easily tweak to mask the flaw)
to spend money fixing the problem? Maybe
if you can get somebody of the stature of
Matthew Carter to create a highly desirable
font that exposes the flaw... What are the
chances of that? Nobody can reach the top
a profession without some pragmatism.

Getting FontLab to improve the conversion
would of course be much easier. On the other
hand if the TT version of a font is removing an
issue that the PS version might sporadically
suffer from, maybe that's actually a disservice?

hhp

Tim Brown's picture

I'll be happy to see this issue resolved. Thanks for pursuing a fix, Frode.

Wanted to clarify something: the feedback Frode cites atop this thread is from Tim Ahrens. I am immeasurably flattered to have been mistaken for him; My knowledge and experience in this area pales in comparison.

Frode Bo Helland's picture

Tim & Tim! I’m so sorry!

Jens Kutilek's picture

While you are not saying this explicitly, your comments can be read as "it's a font quality issue that needs to be address on font level" which would be the wrong message.

Karsten is right, of course. It is definitely related to our own workflow. We need reproducible results when converting PostScript to TrueType curves, so we need to take that into account as early in the process as possible.

Frode, does this bug occur also in Mac OS rendering? For all I know, it is the same rasterizer as on iOS (except for different settings for subpixel vs. greyscale antialiasing). The FreeType rasterizer is also related, you may want to test with it.

Rob O. Font's picture

@Jens-We need reproducible results when converting PostScript to TrueType curves, so we need to take that into account as early in the process as possible.

As early in the process as possible, you would want to design your outlines as TT curves instead of PS. This is one reason why I've been pushing so hard (since 1989), for native TT drawing in font design apps!

hrant's picture

Question:
Are there no observed "bad behaviors" among PS renderers*?
I'm talking about bad behaviors that can be circumvented with
simple tweaks as above.

* Which I do realize are much more
relevant in print than onscreen, and
due to resolution less problematic.

hhp

John Hudson's picture

The question of 'half dead' curve constructions is one that I've pondered for a while. So far as I recall, there is nothing in the PS font format specs to prohibit them, and yet Adobe seem to consistently avoid them in their own fonts.

[I avoid them for the same reason that Jens gives: they muck up PS-to-TT conversion algorithms.]

dezcom's picture

I assume someone let Apple know about this?

hrant's picture

Prohibit is one thing, advise against is another.
Does TT even explicitly prohibit half-dead curves?
What I'm wondering is, if we know that a given font will
only ever be in PS, is it safe to leave in half-dead curves?

BTW, Adobe does break some PS rules though - like
Slimbach doesn't bother with explicit extrema for
very small curves, like at the tips of bulgy serifs.

hhp

dezcom's picture

But that makes sense,Hrant. If adding xtremma points screws up the tiny curve but gives no problem to hinting, why not?

hrant's picture

I haven't seen it such that it would mess up the curve.
And doesn't its absence mess up TT conversion?

hhp

k.l.'s picture

hhp – Prohibit is one thing, advise against is another.

Exactly. And when a spec doesn't prohibit something, and all but one library are fine with it, there is no need to advise against it.

A too big discussion for a too little thing.

hrant's picture

> all but one library are fine with it

I don't get it. There are many foundries that
play along and tweak their curves to bypass
renderer flaws. And I myself am sad to say,
iGadget rendering isn't a "little thing".

hhp

k.l.'s picture

You can spend all day wrapping your head around it if you formulate it as vaguely as "many foundries that play along and tweak their curves to bypass renderer flaws". Which foundries exactly? And which renderer flaws, in plural, are you referring to? The original post is about a very specific one which, afaik, exists in a single renderer.

hrant's picture

So you're saying only FontFont is überpicky, and the only flaw is this one?

BTW, since you caused me to re-read the original post, I just
realized that this flaw is with PS outlines! So that settles that.

hhp

Syndicate content Syndicate content