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!
Comments
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.
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?
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.
I hope that this is the first (or even the only) item on the list for CORLv2.
- 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.
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.
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.
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)
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
ABC > CBA
ABCD > DCBA
Not sure what’s the easiest solution to the amount of kerning though. Just manually ‘over’-kern all letter combinations?
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)