New algorithm: Italify – optically corrected obliques

SCarewe
SCarewe Posts: 38
edited March 25 in Type Design Software

After almost four years of working on and off on an algorithmic approach to optically corrected obliques, the completely overhauled Italify is ready.

With the initial version of the plugin, which is still publicy available, I was running into too many issues due to the approach. It was using a basic slant/rotate mix, which deformed the height of outlines and lost horizontal extremes.

So I developed a completely new algorithm, which is purely geometry-based, without any rotation involved. That means: No stem info required, works with removed overlaps, and even works on quadratic curves if necessary (though not implemented yet). No nodes are removed/added, so master compatibility is guaranteed. Horizontal extremes are perfectly maintained. If you’re wondering about vertical vs. italic extremes, I recommend this Typedrawers topic.

Like the first Italify, curves are corrected as well as diagonal stems (think k, v, w, x…).

Currently, the algorithm is available on a service basis. The long-term goal is to make this a public Glyphs plugin, but there is still a very long way to go.

So, if you have a sans-serif font and can’t bear the thought of making your italics manually, here is your solution. Sources must be in Glyphs format. Get in touch for pricing and further information.

E-mail: sebastian.carewe at gmail dot com

Tagged:
«1

Comments

  • ok_locksmith_8414
    ok_locksmith_8414 Posts: 7
    Would this work on a nonstandard UPM? I am working on a typeface with a 1500 UPM. 
  • James Puckett
    James Puckett Posts: 2,042
    Congratulations on getting so far with this!
  • SCarewe
    SCarewe Posts: 38
    @ok_locksmith_8414 yes. It works on any UPM, and even works with custom subdivisions.
  • SCarewe
    SCarewe Posts: 38
    In case anybody is curious about results, here is a Google font I forked to make an oblique with Italify. The italified masters are in the main file, not the (old) Italic file, which you can use for comparison. The backgrounds contain the purely slanted paths.

    Instrument Sans
  • Christian Thalmann
    Christian Thalmann Posts: 2,058
    edited March 26
    The long-term goal is to make this a public Glyphs plugin, but there is still a very long way to go.
    That would be awesome! Isn't it already better than the built-in Italicize?
    Meanwhile, I find myself manually skewing my italicized glyphs to the top left and bottom right, one by one...
  • SCarewe
    SCarewe Posts: 38
    In all honesty, I find Glyphs' Cursivy (that's the name) terrible. It's stem-info-based and comes with all sorts of problems – just look at Inter's italics, for example.

    So yes, Italify is far better. It's just not yet ready to be publicly released to users who expect a fully functional plugin. I still guide the algorithm.
  • Typedesigner
    Typedesigner Posts: 97
    edited March 27
    That’s a really interesting algorithmic approach! Could you do the same for FontLab 8? That would be great.
  • Christian Thalmann
    Christian Thalmann Posts: 2,058
    SCarewe said:
    In all honesty, I find Glyphs' Cursivy (that's the name) terrible. It's stem-info-based and comes with all sorts of problems – just look at Inter's italics, for example.

    So yes, Italify is far better. It's just not yet ready to be publicly released to users who expect a fully functional plugin. I still guide the algorithm.
    Maybe for test users then?  :#
  • Typedesigner
    Typedesigner Posts: 97
    edited March 27
    Incidentally, what stands out in the example shown is that the nodes at the extremes have been completely omitted. Why is that? The handles should not be slanted, but vertical.
  • SCarewe
    SCarewe Posts: 38
    @Typedesigner
    "The handles should not be slanted, but vertical", says who? Did you read the Typedrawers thread I linked?

    An adaptation for FontLab is theoretically viable, but it is not on the current roadmap. I'm not aware of the user base and have no experience in FontLab scripting. I'm not sure whether it's viable for me to publish an FL version (and to maintain it).

    @Christian Thalmann
    What do you mean by that? I'm not publishing the algorithm as a test version. The plan is to make it into a commercial plugin – until it is stable enough to do so, I offer it as a service, so that I can control/guide it where necessary.

  • Christian Thalmann
    Christian Thalmann Posts: 2,058
    edited March 28
    Ah, missed the commercial part!
    "The handles should not be slanted, but vertical", says who? Did you read the Typedrawers thread I linked?
    That was also my understanding from back when I started, but it seems the consensus has changed to vertical handles since then.
  • SCarewe
    SCarewe Posts: 38
    I'll try to summarise from the Typedrawers thread I linked.

    The only objective reason for keeping handles on verticals is hinting. Autohinting is not possible for "vertical" stems in slanted shapes, since they don't exist. Thus, keeping vertical handles in slanted shapes is not necessary.

    People are welcome to add vertical handles back to the shapes Italify produces, but I won't offer it, since that is beyond the "pure geometry" approach I am pursuing.
  • Typedesigner
    Typedesigner Posts: 97
    edited March 28

    It’s a pity that your script won’t be available for FontLab 8 – it would have been very useful for many of us.

    I understand your “pure geometry” approach, and it’s interesting from a design perspective. However, there is a technical point that cannot be ignored:

    When the handles at extrema are not vertical, the curve’s extrema points do not lie exactly at the mathematically highest, lowest, leftmost, or rightmost positions. This has practical consequences:

    1. Autohinting may calculate inaccurate stem positions.
    2. Interpolation / Variable Fonts can produce small but noticeable artifacts.
    3. Even modern renderers handle the curve visually, but technically the extrema are not defined, which can be an issue in professional font production.

    In short, for display or purely geometric fonts this may not be noticeable, but for precise hinting, desktop fonts, and variable fonts, vertical handles at extrema are practically necessary.

    Your approach works well for visually “pure” curves, but from a technical font production standpoint, the non-vertical handles at extrema mean the exact points are missing, which is a real consideration.

  • SCarewe
    SCarewe Posts: 38
    Copying a ChatGPT response that completely misses everything I've said multiple times won't help. As a font engineer, I think I know what I'm talking about. You clearly don't.

    Once again, read the topic I've linked.
  • Typedesigner
    Typedesigner Posts: 97
    The tone here is a bit unhelpful for a technical discussion and may risk alienating potential users of your script.

    On the technical side: non-vertical extrema handles mean the true extrema aren’t present. FontLab 8’s Font Audit flags this as an error - this isn’t just theoretical, it’s a real production issue. Of course, you may have a different perspective.
  • SCarewe
    SCarewe Posts: 38
    As somebody who actually produces professional fonts, I know which flags to ignore when adequate. The argument that vertical extrema are not present when vertical extrema are not present is circular, to say the least. Why do you need them?

    Luckily, technically experienced people are aware of this and trust my tool already. Adapting this for FL seems even less useful now.
  • Typedesigner
    Typedesigner Posts: 97
    In this context, RMX Slanter is an excellent solution. Unfortunately, it is not available for Font Lab 8.
    This tool slants glyphs while keeping vertical tangents upright.
  • SCarewe
    SCarewe Posts: 38
    For the entire thread, you have not given a single objective reason why you need vertical extremes in slanted fonts. Can you give us one?

    RMX Slanter deforms the curve in order to achieve vertical extremes. I am opting for curve fidelity instead, which I think is much more important.
  • Yves Michel
    Yves Michel Posts: 236
    @SCarewe
    We are not used to such a unpleasant tone on this forum.
  • SCarewe
    SCarewe Posts: 38
    Fair. I'm not used to people blatantly ignoring every point I make. It's annoying.

    I find using clearly AI-generated responses to my posts (which don't address any actual points I made) extremely rude. Apologies for the tone that provoked in my answers.

    I'd be happy to continue this discussion constructively (this includes myself, of course).
  • Yves Michel
    Yves Michel Posts: 236
    Merci pour le changement de ton ! Et bravo pour les efforts en matière logicielle.
    Thanks for the change of tone ! And hats off for the effort on your software.
  • Simon Cozens
    Simon Cozens Posts: 828
    Typedesigner said:
    FontLab 8’s Font Audit flags this as an error - this isn’t just theoretical, it’s a real production issue.
    What problems does this issue cause?
  • Thomas Phinney
    Thomas Phinney Posts: 3,120
    edited March 30
    Note that when the slanted glyph has round shapes, such as with a typical O, the horizontal distances are just as valid subjects for hinting after slanting as they were before slanting. And they could be hinted before, but can’t after, with this approach.

    I read your linked topic, and I read it originally. That particular DIN-like typeface with its straight-sided rounds does not exhibit the same characteristics in this regard as most typefaces do. Nobody debated you much there, but that is not the same as people agreeing with you.

    I will grant that hinting is much less important than it once was.
  • Typedesigner
    Typedesigner Posts: 97
    SCarewe At this point, I see no value in continuing this discussion, as you have stated that your script will not be available for FontLab 8 and does not meet my requirements.
  • SCarewe
    SCarewe Posts: 38
    edited March 30
    Would you mind actually clarifying why you have this need of nodes on vertical extremes? Is there an objective reason?

    If I can find a significant user base of FL that would buy a plugin, it's a thought for the future. But I can't guarantee anything, since I know maintaining the Glyphs (and potentially Robofont) version will be enough work.
  • Typedesigner
    Typedesigner Posts: 97
    edited March 30
    At this point, I believe I’ve explained my reasoning clearly, so I’ll leave it here and won’t engage further in this thread.
  • SCarewe
    SCarewe Posts: 38
    edited March 30
    You are simply repeating that you want vertical extremes. That's not a reason why you want them.

    If your argument is geometric consistency, then that is wrong. Removing slanted extremes and instead inserting vertical extremes modifies the curve from what it would normally look like following geometric transformation. You are trying to approximate the same curve with a different node structure, which will not give the same results (especially for very unevenly weighted curves, for example in condensed styles). This is precisely one of the reasons why slanted extremes are so important and useful. I understand that FL makes you believe that vertical extremes are technically necessary, but that is not true. As Simon also asked, what problems do slanted extremes actually cause, apart from lengthy discussions on Typedrawers?
  • Thomas Phinney
    Thomas Phinney Posts: 3,120
    I have given a reason, which you have not responded to.

    You are also guilty of the same mistake in discussion: you are assuming that your desired outcome is what other people would want or care about. In your case, that a very specific kind of geometric transformation is the desired goal, and therefore anything that contradicts that is bad.
  • SCarewe
    SCarewe Posts: 38
    edited March 30
    Ah, yes, sorry. I read your point, but was wondering which examples to cite. Are we only talking about an o? Then I can see how hinting would be possible, of course. However, what stems do we care about? Almost all other stems are slanted in an oblique font. Even in an n, which has a curve/stem combination, do we care about the stem that would be at the vertical extremes of the curve on the top right? Hardly.

    So I really think that the hinting argument can be disregarded for fonts where stems are not vertical. Apart from the fact that, as you mention as well, hinting is far less relevant these days.

    In regards to geometrical transformation: do we consider curve approximation a geometrical transformation? I would think that only translation of existing points would count as such.

    Either way, vertical extremes only complicate things in terms of transformation. Italify is an initial tool; Interpolating lighter weights, a narrower width or any other operation falls outside the intended scope, for the simply reason that the perfect tool for that already exists (even in FL). Italify prepares the best possible outlines for interpolation and continuing from there.
  • Typedesigner
    Typedesigner Posts: 97
    edited March 30
    By the way, here's what the Glyphs app handbook says about extremum points:

    "It is considered good practice to have nodes on extremum points. Some font technologies, like hinting, require nodes at extremum positions. Some operations, like offsetting a curve, work better with inflection points placed on the undulating curves. Also, some font renderers may behave unexpectedly if such nodes are not in place. Furthermore, inflection points pose a problem for outline interpolation since they can easily cause kinks in outlines."

Categories