Outline Quality Checklist

[vv-monsalve]

@SophiaDesign we've built this checklist to ensure the outlines quality and thus prevent any unwanted/unexpected issues on the resulting fonts.

Please, review it and ensure everything is ok for GF-Foldit. E.g. in the current "decomposed" file, some paths are in the wrong direction.

Outline Quality Checklist

Make sure your font is ready for mastering by fulfilling this checklist. Design is not particularly judged here, we are talking from the point of view of the technical quality aspect of a font, i.e: what you see in your font editor is what will everyone see on their own screen or printed matter.

Contours

Segments

• Mixed outline type : The outlines of one font must be either PostScript (OpenType Fonts font with CFF compression / .otf) or TrueType (OpenType Fonts with TrueType compression / .ttf). Make it sure they are all cubic (PostScript) in the source file.
• Wrong direction: For PS outlines, the outer-shape goes counter-clockwise, and the inner-shape (or counter-shape) goes clockwise in PS outlines.
• Almost straight: If a segment is misaligned by one or two units, it may be a mistake from the designer. This small offset can cause a big misinterpretation from the rasterizer at small ppm sizes.
• Missing inflexion point: It is considered that a curve has a suspicious inflexion when it is a single segment going from convex to concave (and vice versa). We need to divide this segment by adding a node at the point where the curve is changing conditions, therefore the tangent represented by the two handles crosses the curve.
• Collinear: If two line-segments are connected with the same angle (or almost the same angle), or with a slight offset, it means that the entire line could be made with one segment (two points, not more).
• Short: Segments of 1 or 2 units are often unwanted and, again, can be wildly rendered on some screens.
• Open: A contour can only be considered as such if it has a closed path. Otherwise, it won't be rendered at all.
• Overlaying: It disturbs rendering, interpolation and variation.
• Overlapping: The crossing of two independent contours is not such a problem in VF (although small overlaps are preferred) and are generally merged during the generation of static binaries. If you want to control the result of the merging, it is better to do it yourself. If not, try to keep them in a small overlapped area. Also try not to overlap more than 2 contours in the same area (contour crossing a contour itself crossing another contour, like an asterisk, creates confusion during generation and rendering). In any case, try to avoid overlapping shapes that cross a plain shape and a closed counter-shape (typically, Oslash should be manually merged for example).
• Self-crossing: Often known as open-corners, it is very helpful while designing and recommended for nice interpolations. They will be preserved for VF fonts and merged during generation to static binaries. To better control the result, pay attention to its size (not too big, not too small) and not leave portions of it outside the main shape like the stem. It can cause unwanted rendering issues. If you want to control the result of the merging, do it yourself, otherwise do the same advice as above.

On-curve points (nodes)

• Overlaying: Also called "empty segments” because they don't have a length. They are often useless and sometimes confusing for hinting and rendering — except for some rare cases of variations. They ought to be removed.
• Missing on extremes: Points at X and Y extremes of the paths are required for hinting reasons since they attach hints to the extremum of the stem. Also, by having them, you could control better the curves and probably reduce the necessity of extra nodes.
• Fractional coordinates: Coordinates of the nodes need to be integer values. This could be easily solved by running the automatic command "Round coordinates"
• Broken smooth connection: Ensure the right type of node according to the connection, smooth (between two curve segments) or sharp (between a curve and a line segment; or two line segments)

Off-curve points (handles)

• Almost straight Ensure the handles are really aligned with the angle of the shape.
• Inside node If needed they shouldn't be retracted.

Components

• Transformed components: Transformed components ((scaled, mirrored, stretched, rotated) are not processed correctly while generating variable ttf. This could cause issues like the original component being displayed instead, unwanted fractional coordinates, as well as the wrong direction in outlines.
• Nested components: Components referring to another component (nested) are not exported correctly to the ttf variable format. They take back the coordinates of the original glyph. E.g. Issue #2961
• Overlapping components: While generating ttf static binaries, Fontmake doesn't decompose overlapping components, which is good for Variable Fonts but can cause some issues in static TTF.

Kinks

If it is a VF you would like to avoid kinks, so these three situations should be avoided.

• Aligned nodes in the same straight line A straight line ins a VF has three or more nodes that should keep aligned.
• Changes in angle The angle of a segment ideally shouldn’t change a lot between the masters.
• Changes in proportion The proportion and distances of segments drawn by the nodes change considerably

[SophiaDesign]

@vv-monsalve Thank you for this list!

I have some questions.

Segments

• Outline Direction: Since COLRv1 is web-based (Truetype) and doesn’t work in Adobe (postscript) yet, should this be clockwise direction? Or maybe I’m missing something, like one of them is easier to convert to the other?
• Colinear: Necessary in some glyphs for variable compatibility (same as Kinks: Aligned nodes in the same straight line)
• Short segments: Is it possible to keep these? All sharp corners in this design are made to look slightly smoother with 1 unit segments. It's possible to remove these segments, but I'm curious it's worth the tradeoff. Do you have a documentation that I should look at?
• Overlaying/overlapping: Is necessary for variable and good interpolation. Unfortunately can not be avoided because of nature of how gradient elements are used in this design

Components:

• Overlapping components: The project scope is for variable font, no statics. Ignore?

Is it possible to make things work if not all on the list can be completed? Are some or all of these points considered a 'must'?

[vv-monsalve]

Hi @SophiaDesign

• Outline Direction: Since COLRv1 is web-based (Truetype) and doesn’t work in Adobe (postscript) yet, should this be clockwise direction? Or maybe I’m missing something, like one of them is easier to convert to the other?

Typically, out of the easiness, PS outlines are used while designing, so they must follow its direction logic (stated in the checklist). Then, the tool compiling the TTF font will take care to convert them to TT outlines. But it would rely on good PS standards applied.

Regarding the rest of the items in the checklist, all of them should be considered with care on a project-by-project basis. The list is intended to avoid common problems and Warns reported by Fontbakery, but, in many cases, they are design related and could be ignored. However, to be sure about that, it is important to double-check that the results of the interpolation are behaving as expected, with no unwanted paths issues (some couple of examples listed below)

• Overlapping components: The project scope is for variable font, no statics. Ignore this one?

As mentioned in another Issue, currently, the API will always instantiate fallback static ttf fonts. Therefore the design must ensure those static fonts will have good results once exported.

• Overlaps quality for VF #2695
• Glitches #3064 #2637

[vv-monsalve]

Almost straight: If a segment is misaligned by one or two units, it may be a mistake from the designer. This small offset can cause a big misinterpretation from the rasterizer at small ppm sizes.

Overlaying: It disturbs rendering, interpolation and variation.

Related to the Won issue, it has some "almost straight (highlighted in red) and overlying segments. You would like to solve them for this and any other glyph to prevent issues.

The top intersection of paths could be treated as the ones in the bottom.