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

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

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.

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.

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).

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

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

hhp

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.

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

»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.

"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. :-\

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.)

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

> 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

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

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

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.

Tim & Tim! I’m so sorry!

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.

@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!

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

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.]

I assume someone let Apple know about this?

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

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

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

hhp

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.

> 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

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.

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

The adobe curveto command requires two off-curve points between two on-curve points.

‘’This operator draws a curve from the current point to the point (x3, y3) using points (x1, y1) and (x2, y2) as control points. The curve is a Bézier cubic curve. In such a curve, the tangent of the curve at the current point will be a line segment running from the current point to (x1, y1) and the tangent at (x3, y3) is the line running from (x3, y3) to (x2, y2).’’

If you can read at least as well as me, There are No Exceptions, It is Deeply Baked into PS interpreters and the cff format.

Deeply, means there is as much chance of changing to “half-deadness” as there is of one being hit by lightning while being attacked by a shark in the middle of a hailstorm in the desert.

If you read better than me, let us know.