How to fix XOR rendering behaviour in overlapping glyph elements?

zoetropik

New Member
Hi, everyone.

I'm experiencing a strange issue and hope someone out there can help. I've recently been working on a font for a conlang and, whilst everything looks fine in the font design software itself, when the font is exported to OpenType format, installed, and then used to type some sample text out in MS Word, some – but, mysteriously, not all – of the glyphs that contain overlapping elements display white-for-black in one or more regions where two elements overlap. In case I'm not explaining this well, imagine a lowercase Latin letter "t", but where the intersection of the vertical and horizontal elements is not black, but white. (Like a tiny trapped "cube" of white surrounded on four sides by the remaining filled [i.e. black] contours forming the lines of the "t".)

At first, I assumed that there must be something different about the way the elements were being superimposed in the font design software, but I've checked and it's simply not the case. I've even found places where I'm using an identical element reference in two slightly different versions of the same compound glyph, and in one the "inverting black to white fill" issue appears whilst in the other, it doesn't. Opening each glyph in the editor shows that both element references point to the same original element, which is oriented in the same direction, has not undergone different transformations from one of these glyphs to the other... and in fact overlaps the same portion of the background element in both cases. I've even tried using "reverse contour direction" on either element to no avail, and am running out of ideas on other things I could do to make two identically filled, identically contour-oriented, identically-transformed overlapping elements not randomly invert their intersection fill colour.

Hopefully someone with a lot more experience in font design than me – which I imagine would describe most of the folks in this forum – can suggest some "likely suspects" to double-check... because whilst the font is usable enough as it stands, it isn't aesthetically pleasing for random characters to experience these little visual dropouts.

Many thanks in advance for your help! ;-)
 
If you are using compound glyphs that consist of multiple overlapping elements, try converting them into composite glyphs instead. In composite glyphs, the overlapping areas are rendered differently and might behave as expected.
 
If you are using compound glyphs that consist of multiple overlapping elements, try converting them into composite glyphs instead. In composite glyphs, the overlapping areas are rendered differently and might behave as expected.
Thanks for responding to my query!

I'm using FontLab and since my conlang uses an abjad, all of the combined glyph forms (e.g. consonant + vowel + glide) are generated using auto layers (i.e. I enter a 'recipe' of which individual glyphs to combine, and FontLab generates a combined glyph from those).

I don't know whether these 'auto layer' combined glyphs qualify as 'compound' or 'composite'. For instance, when I select one of the combined forms and go into the glyph editing window in FontLab, the interface implies I cannot directly edit the individual elements... which makes sense since these are only referencing the original elements in the non-combined individual glyphs.

If you have experience using FontLab and can suggest the names of some commands/actions that would be appropriate to check on the compound/composite status, I'd be grateful. But even if you use a different font design application and can't provide any further help, I appreciate you having taken the time to write me back. I'll go search the online FontLab documentation for mentions of 'compound glyph' and 'composite glyph' and see what I can turn up. ;-)
 
Back
Top