Overlap in variable fonts
Adam Jagosz
Posts: 689
Should I remove overlap and perform other ordinary clean up operations before exporting a variable font? It seems a sane thing to do, however FontLab doesn't do it automatically on export despite the proper checkboxes being checked.
Tagged:
0
Comments
-
I would be paranoid to the moon letting it do it automatically anyway.1
-
It seems reasonable as it might ruin master compatibility. So, shortly: yes?
0 -
Variable fonts are allowed to have overlaps. No reason to remove them.3
-
Quite right.
There are times when things can be made to interpolate nicely with overlapping paths, but removing the overlaps will create problems. That's why overlaps are completely legal in variable fonts, and FontLab VI does not remove them by default.0 -
Are they removed at some point internally, or are they simply all rendered? If the latter, what happens with contours of opposite directions overlapping? (I sort of remember having this discussion way back, but can't remember the conclusion...)
BTW no risk with older RIPs? (I'm guessing they can't handle varfonts anyway?)0 -
The OS-level support for variable fonts must be sending flattened instance-fonts to the printer drivers, with the result that old RIPs are just fine. It may also remove overlap as part of this process.0
-
I don't trust that.Thomas Phinney said:It may also remove overlap as part of this process.0 -
Are they removed at some point internally, or are they simply all rendered? If the latter, what happens with contours of opposite directions overlapping?
The winding rules specified to be used with OT variable fonts should not be a problem in this respect. This is one of the key reasons for the CFF2 table spec, because Adobe's CFF format couldn't handle the overlaps. In a variable font, you typically want an overlaps whenever a curve or diagonal is intersected by another stem, e.g. the crossbar of A or the slash of Ø, in order to get smooth interpolation of the curve or diagonal.
There's one case that turns out to still present problems, which is when you have overlapping elements of a glyph knocked out of a solid, e.g.
This issue is being looked at.I don't trust that.I trust a system that knows about variable fonts and can instantiate them for download to a printer to remove the overlaps more than I trust the printer to correctly interpret overlaps.
2 -
My instincts tell me this is a topological Pandora's Box...
Whoever is looking at it, good luck.
Sure.I trust a system that knows about variable fonts and can instantiate them for download to a printer to remove the overlaps more than I trust the printer to correctly interpret overlaps.
Neither holds a candle to a human finessing a grid that I think we agree is quite coarse.
1 -
I usually draw glyphs with lots of overlaps. It would be silly to leave all of them in the shipped font, because the contours would contain a lot more points than necessary. I would remove all overlaps that do not influence interpolation before exporting the font.
Overlaps that influence interpolation are usually crossing diagonals (as in A), or lines crossing curves, as in Ø.
There is no readymade way to automate this, though. It could be done by a machine: Make a copy of the glyph, and compare the two versions 1) interpolate, then remove overlaps and 2) remove overlaps, then interpolate. If they are identical, or sufficiently similar, overlaps can be removed in the variable font.
Of course, there are some glyphs which don't interpolate anymore if you remove overlaps. They need to be kept as is, too.
None of these are necessary for interpolation:
32 points, versus 28 when overlaps are removed.4 -
My concern is exactly that the desire/need to interpolate could end up degrading another dimension of quality. But it could be an incorrect hunch.Jens Kutilek said:
there are some glyphs which don't interpolate anymore if you remove overlaps.
Digression:
That said, allowing overlapping contours and/but rendering them faithfully according to direction, along with supporting boolean operations, enables a very powerful new way to implement notan. What I'm getting at is, imagine a black countour with a white one cutting into it (while not itself appearing black outside the overlap). What boggles the mind a bit more is contemplating how layering should factor in... This is something I've been "working on" :-) since 2013, and I know it sounds a bit sci-fi, but it would be the final emancipation of notan from the black.0 -
imagine a black countour with a white one cutting into it
That's doable in a colour font, if you're talking about actual black and white, but presumably you want the 'white' to be the background colour of whatever ground to which you apply the font.0 -
Indeed.0
-
I think this might be the right place to ask if an idea like this is doable? I've been asking around for advice or suggestions (i'm not a programmer) on how something like this might be achievable. I'd hope that this would be very easy for a typographer or designer to use.
Ideally, a designer could adjust the tracking and the leading and the overlaps would happen through booleanOperations (?) Also, ideally the color of each letter could be changed and the white shapes would be transparent, ie: not filled with white to achieve the overlap. (i'd like for this to not be a layer font)
i am able to get a very basic, but very time-consuming version of this to work, but the two limitations i'm running across are:
1. i'm substituting a whole letter for two halves, then replacing the right half of the letter, with a combination of that half of the letter and the left half of the next letter (kind of like a ligature) - which means there is no tracking available and when i go to color one of the letters, i end up coloring the two halves.
2. i have no idea how to get the overlaps to happen on the leading.
thank you in advance,
0 -
Supporting boolean composition requires a serious specification update, and it is hard to maintain full compatibility with existing API.Micah Hahn said:I think this might be the right place to ask if an idea like this is doable? I've been asking around for advice or suggestions (i'm not a programmer) on how something like this might be achievable. I'd hope that this would be very easy for a typographer or designer to use.
Ideally, a designer could adjust the tracking and the leading and the overlaps would happen through booleanOperations (?) Also, ideally the color of each letter could be changed and the white shapes would be transparent, ie: not filled with white to achieve the overlap. (i'd like for this to not be a layer font)
i am able to get a very basic, but very time-consuming version of this to work, but the two limitations i'm running across are:
1. i'm substituting a whole letter for two halves, then replacing the right half of the letter, with a combination of that half of the letter and the left half of the next letter (kind of like a ligature) - which means there is no tracking available and when i go to color one of the letters, i end up coloring the two halves.
2. i have no idea how to get the overlaps to happen on the leading.
thank you in advance,
But — you can go color fonts for now.1 -
The overlaps here go both ways. Color fonts would only allow for the following glyph to overlap the previous glyph, right?Belleve Invis said:
But — you can go color fonts for now.
0 -
@Belleve Invis Is really keen on the idea of revising the OpenType spec to enable boolean composition. I'm not sure how realistic a proposition this is. There are so many display and layout implementations of the existing font format spec that any radical change requires buy-in from a lot of different players if it is to have any chance of being implemented widely and interoperably.1
-
ah, ok, what I'm hearing is that what I'd ideally like to do is just not possible at the moment. I could make a layered font I suppose, but they feel so clunky, (maybe because i'm not used to using them) so I'd like to avoid that. I do appreciate your input, time and consideration of the idea. thank you.0
-
Apart from the vertical overlaps, you could do something similar with a combination of ligatures and left cutouts. Design an alphabet to minimize the variety of silhouettes on the right side. For example the X and K could share the same right silhouette. Q could have more vertical stroke to avoid interfering with the right side silhouette...maybe get it down to 18 types. Each letter would have 18 variations with left cutouts that match each silhouette type which is less than 500 glyphs. Then add loads of ligatures with interesting interlocking overlaps. Those ligatures could be cleverly chosen to avoid having to make 18 variations of each. For example, if you had a CR ligature, you might be able to skip the P cutout unless you care about unlikely words like CAMPCRAFT or TOPCROSS. And then add some intricate OT code to deal with it all. Still doesn't solve the tracking/color issue but I think it's possible to make something approaching this idea if you're willing to compromise.
1st edit: Just thought of this after posting: mix in unicase forms to further reduce the number of silhouettes. Lowercase B and P forms with scenders could have the same right side silhouette as O.
2nd edit: wait, you could use variable fonts to adjust tracking withing a certain range. Since the lines have thickness you could alter the depth of the cutouts and there's probably enough threshold to tuck redundant points under the overlapping line of the previous letter and hide the distortion. That way you could add extra anchor points along the curves near the cutouts. This would allow you to move the cutaway left and right which, in concert with moving the sidebearings, would essentially let you adjust tracking and retain the overlap effect. But there's a limit to how much you can vary it before the curves near the cutaway would distort too much or entire shapes would vanish. With good planning I think it would work. If you can't picture what I mean, look at the way the D overlaps the E in the above example. See how it overlaps 3 white stripes? Picture it overlapping 2 white stripes. Now imagine a variable font where there's an axis with two versions of the E.
0 -
@Ray Larabie Thank you for the thoughts! I've been looking into variable fonts too. (thanks to a suggestion from @Georg Seifert on the glyphs forum) I don't know much about them (or how to go about setting them up) but from what little I have uncovered, I think that may be the way to go. I love the idea of having a specific range for the tracking distances, ie: the letters would only overlap according to the stripe distances. I need to do some more research and read some more glyphs tutorials :-) Again, thank you for your feedback, it's thoroughly appreciated!0
-
Just to check, what about "looped corners", do they count as legitimate overlaps, or should be flattened before the export?
I know they are not a good idea in some cases because you don't have full control over where the intersecting node will be (integer rounding) so vertical/horizontal might end up not being actually straight.
But in terms of winding rules and rendering, is it fine?0 -
Overlaps are bad juju for notan.0
-
Just to check, what about "looped corners", do they count as legitimate overlaps, or should be flattened before the export?
Yes, they're legitimate in TTF and in variable fonts. The only thing you need to watch out for is overlaps of overlaps, which can produce knockouts. So, for example, you can't use this construction for an inktrap
but you can use this construction
4 -
Like I said... ;-)
2
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 798 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports