Color font with overlapping letters

Shoko Mugikura

Hello!

I want to make a display font like the sketch 1 (see below) with color font. The space between the glyphs are drawn separately in white. So it is a colour font but black and white color font.

But then I realised that it is tricky: as it seems text is always rendered in the way that the right hand glyph covers over the left hand glyph. So the sketch 2 (see below) is possible, but this is not what I want.

Is there any solution to this?
It appears that using several individual fonts could be a solution, but not so user-friendly.

Any help is much appreciated, thank you!

Mark Simonson

I've wondered about this myself, although I haven't made a font like this (yet).

One, probably impractical, solution would be to (somehow) make the font set right-to-left, like Hebrew, and then type everything backwards. Not sure this is possible with latin scripts or, even if it is, whether it would be acceptable for users.

The other, maybe a little less impractical, solution I've thought of is to simulate the overlap by creating multiple versions of each character designed to match the shape of the character to the left, and then use contextual substitution to select them. (This is essentially what one does when drawing letters like this.) But this would require an enormous character set unless it was limited to, say, capital letters. Even then, you'd need at least 19 or 20 versions of each letter (depending on the design). Also, no tracking allowed, like a connecting script.

Fontfruits

I'm not sure if there is a solution to this - but if all else fails , I would just instruct the user to write from last letter to first with paragraph aligned right..not a wonderful solution I know, but a way to use the font nonetheless Hoping someone here pipes up with a proper solution that is to do with the actual font software...

Mark Simonson

@Fontfruits That wouldn't work because text is always rendered from left to right in latin scripts regardless of the order the letters are typed or the paragraph alignment.

Shoko Mugikura

Thank you both for your reply! The idea of setting up the font like Hebrew is brilliant, though it would be too unusual for the users. 

If the people responsible for color font formats are reading this, would it be possible to think about updating the spec so that the design like above becomes possible in the future?

Thomas Phinney

The problem with the order of glyph rendering is mostly outside the font specs, in the font rendering engines. Unfortunately, there are many of them, not just one. And for them to do anything different would cause problems in other situations; I don’t think there is an obvious solution here.  

Ray Larabie

I did a project like this that looked like example 1 with a system like @Mark Simonson
described. I abandoned the project because my initial design wasn't appealing enough. Here's how it works:

Each letter will have an uncut version and a version with a cut-out for each letter. If you design your alphabet to be as modular as possible, you can reduce it to 19 shapes. That's only 494 glyphs for the alphabet and you'll need to consider other characters you want to include. You can reduce numerals to four. (8,3 = B and 4 can be flat-sided) Let's say period and comma are the same shape and you're still only at 728 glyphs.

Use a script to generate "cutters" I'm not sure with app you're using but in FontLab 5, it's ctrl G then copy/paste a script like this:

A=A.cut
J=J.cut
O=O.cut
S=S.cut
etc.

Apply a bold effect to those "cutter" characters and reverse contours.

Ctrl G and copy/paste a script like this
A_A.cut=AAcut
B_A.vut=BAcut
C_A.cut=CAcut
etc.

Delete all .cut glyphs.
Copy/paste special the original glyph metrics to the .cut glyphs.
Select all and remove overlap.
Use the magic wand on each glyph to select and remove unwanted shapes.

Make an OpenType "calt" feature to substitute them. You can use classes to reduce the size of the program. Each cutter type is a class.

When I had designed this, I had planned to use a substitution system with blank glyphs for accented letters. Those would be substituted for the cut version with a combining (zero space) diacritical. Aacute would be substituted for AAcut acutecomb. But I don't know if it would have worked. I suspect the presense of the diacritical would prevent the following character from detecting the glyph to the left.

Edit: I just realized I could have saved a step by setting the cutters to zero width.

TimAhrens

Thomas Phinney said:

The problem with the order of glyph rendering is mostly outside the font specs, in the font rendering engines.

My understanding is that inside the color font, the layer z-order is defined.

The spec could require the rendering engine to first render the bottom layer for all glyphs in the string, then the top layer for all glyphs. Effectively like using several old-fashioned fonts on top of each other, like it was done in the 90s already, but without the need for several user-handled text layers (and without breaking the Don’t Repeat Yourself rule).

That would allow the above version 1. One would draw the white gaps only for the right half of the glyph, which would give the desired result. If the document has a different background color than the white gaps then it would get a bit ugly, of course.

Georg Seifert

I’ve suggested the layering as Tim explained a couple of times as it is tremendously useful (for overlaps like here or for drop shadows or for connected scripts). For Latin fonts, this could be worked around as mentioned above but that doesn't works for almost all other writing systems. Try cutting out each shape for a Chines typeface. 

I hope that this is the first (or even the only) item on the list for CORLv2.

Mikhail Vasilev

I think the only more or less generally working solution is to create alternates of the second letter for each letter pair. This would work only for the software that support alternates. Yes it is a lot of glyphs to generate (e.g. for 26 letters there will be 650 glyphs). 

It is possible to automate the process, if you have the paths of the white part of given letter it can be extracted from the next letter path. Then remove all white parts (for the common font usage) or leaveit if you want underlay color control. And disable all kerning of course. 

But I can't help with that further, never did this in practice.

Peter Constable

This kind of interaction between colour glyphs is actually very complicated in a couple of ways. Note that there are several different types of effects a designer might want. 

- In the above example, each glyph is opaque, and the designer wants to control the z-order of overlapping glyphs.

- In a font like Grzegorz Luk's Use Your Imagination, the z-order of overlapping glyph is the opposite (as seen in the small drop shadow). Also, the glyphs are translucent, and the desired blending mode is simple alpha blending.

- Not long ago, Frederick Brennan was working on an Arabic font with overlaps for cursive connections. The z-order didn't matter, but the glyphs were translucent, and simple alpha blending was _not_ what he wanted.

- Some time ago what this was brought up, someone (I think it was Georg Seifert) suggested that each glyph could have multiple layers—something like a background layer, a main layer, and a highlight layer—and that the layers interact across glyph pairs (e.g., the main layer of a glyph is always above in z-order the background layer of adjacent glyphs).

Also note that in all these cases there are only two overlapping glyphs, side-by-side left/right. What if there's an area where three glyphs overlap? Or what if the overlaps are above or below?

So, given all the possibilities, it's non-trivial to figure out how to represent such glyph interactions in font data.

It's also not obvious what the implications would be for how text engines would need to render. In COLR v1, you can think of a colour glyph description as a list of 2D graphic drawing operations. (E.g., (i) fill a surface with a gradient; (ii) apply a clip mask; (iii) fill a second surface with a solid colour; (iv) apply a clip mask to the second surface; (v) compose the two surfaces using mode X.) That readily lends itself to rendering each glyph separately and then using simple alpha blending if they overlap. But if more complex interactions are desired, would that entail each glyph can't be rendered separately (with the result cached) before they are composed together?


I understand why more control would be desirable. It's just really complicated.

For now, as you consider designs, I would assume that text engines will render glyphs from left to right (even for RTL scripts) in the final glyph-run order (so a mark glyph will be rendered after its base glyph), and that they will be composed using simple alpha blending.

Mark Simonson

The standardization of color font formats has mostly made the layered text approach obsolete for multi-color type effects, but in cases like this it still seems to be the best solution. It's not as simple or automatic, but it least it works and doesn't require crazy or possibly unreliable tricks in the font.

Georg Seifert

Peter Constable said:

 It's just really complicated.

I might not fully understand the process of text rendering but I would think that each layer is rendered fully individually. So each run is like a it’s own COLR glyph. Just as you would render a layer effect with multiple fonts. 

All those consideration on how glyphs overlap/interact with neighboring glyphs (left and right or above and below) have nothing to do with the layering but are already present in a single layer setup.

RichardW

Mark Simonson said:

@Fontfruits That wouldn't work because text is always rendered from left to right in latin scripts regardless of the order the letters are typed or the paragraph alignment.

I think the idea is to type something like <RLO>IKAYOKAT<PDF> where RLO and PDF are the characters U+202E and U+202C; in HTML this would be <bdo dir="rtl">IKAYOKAT</bdo>.  Of course, that will still fail if the rendering system insists on painting the glyphs from left to right regardless of directionality.

John Hudson

I might not fully understand the process of text rendering but I would think that each layer is rendered fully individually. So each run is like a it’s own COLR glyph. Just as you would render a layer effect with multiple fonts. 

To make sure I understand how this idea would apply to the design in the original post:

1. The black layer would consist of full letter shapes.

2. The white layer would consist only of counters and edging on the right side of the letters—critically, not on the left side, i.e. the white would not outline the whole letter, just one side.

3. The black layer would be painted first across the whole glyph run (glyph run defined how? same as OTL?)

4. The white layer of the glyph run would be painted second.

Shoko Mugikura

Yes, exactly like you describe, John.

Fontfruits

Maybe it would be better to make this into a layered font ( with 2 fonts) , instead of a color font? See image attached...excuse the rough edit

Georg Seifert

@John Hudson
To make it more general useful, one could cut the letter vertically somewhere in the middle. Put everything on the left on layer1 and everything on the right on layer 2. (the gray/black fill is only to show two halves) 

Adam Twardoch

A solution would indeed be to split each glyphs into 2 »halves«, produce a number of the right half of the glyph that depends on what’s coming next, and use contextual substitution.

Or split each letter into 2 or 3 parts and make »ligatures« that combine the right half/third of one glyph with the left half/third of the next one. 

So from /T/A/K/O you’d go to /T.init/T_A/A_K/K_O/O.fina or to /T.init/T.medi/T_A/A.medi/A_K/K.medi/K_O/O.medi/O.fina

Alex Visi

How about substituting AB with BA and negatively kerning them to appear as AB?
ABC > CBA
ABCD > DCBA

Not sure what’s the easiest solution to the amount of kerning though. Just manually ‘over’-kern all letter combinations?

Dave Crossland

Mark Simonson said:

The other, maybe a little less impractical, solution I've thought of is to simulate the overlap by creating multiple versions of each character designed to match the shape of the character to the left, and then use contextual substitution to select them. (This is essentially what one does when drawing letters like this.) But this would require an enormous character set unless it was limited to, say, capital letters. Even then, you'd need at least 19 or 20 versions of each letter (depending on the design). Also, no tracking allowed, like a connecting script.

Reminds me of House's Ed Interlock (https://fontsinuse.com/typefaces/40498/ed-interlock).

Possibly one can avoid drawing the huge amount of glyphs by scripting their creation using boolean ops in a more graphically-rich canvas (drawbot etc)