[CLOSED] Xor of two contours.

[Julian_Griffin]

Hello,

If I have two contours that overlay, they are Xor’ed at the overlap. Meaning that where they overlap is white.

But this is only true for point sizes less than 65. For point sizes 65 and above the contours render correctly.

At point size 64:

But at point size 65:

This is the glyph as it appears in the glyph editing window:

I first noticed this when I exported a font and tried it in a document. What was in the Test Font window (F5) was not the same as the exported font. I put this down to improvements to FC9. But I usually have the Test Font (F5) set to 72 point. On creating the logo attached, I changed the point size of Test Font (F5) down in incroments, I found the at 65 point it rendered correctly, but below this the contours rendered as if Xor’ed together; that is, where contours meet they cancel each other out.

The Xor’ing can also be seem on the right two contours of IP 64.PNG, but as the overlap is small it is harder to see.

Regards Julian.

[ErwinDenissen]

@Julian Griffin

If I have two contours that overlay, they are Xor’ed at the overlap. Meaning that where they overlap is white.

I don’t know how the Windows rasterizer works internally, but the OpenType specification clearly states contours that need to be filled black must have a clockwise direction. If we want to make a white area inside an existing contour we must make the direction of the new contour counter clockwise.

Contour direction is determined by seeing in which direction the point index values increase or decrease. Contour direction is from the smaller point index to the larger. The general rule is that the contour direction should be such that “black is on the right”. Using the glyph “O” as an example, the outer contour should travel clockwise, and the inner contour counter clockwise.

Overlapping contours is not recommended, but if it is needed then make sure the contours have the same direction.

Several well known fonts do have composite glyphs which do have overlapping composite glyph members.

[Julian_Griffin]

Thank you Erwin for your quick response,

I think I understand Clockwise and Anticlockwise. The trouble comes when Clockwise contours overlap but are not fully enclosed. And even then it is only a problem if the point size is 64 or below. I have tried this in MS Word, and the same is true, but the point size break is 40 point and below.

Let me try to show the problem in a better way.

I will create a “Plus” symbol “+”.
If I create 2 contours, both Clockwise:

The Real-time Verification shows that both contours are in the Clockwise direction; there are no errors.

Then I overlap them and keep both contours Clockwise:

Which is what I want “+”.

If I make the horizontal contour Anticlockwise, I get this:

Which is not what I want.

Interestingly, when the contours overlap, the Real-time Validation reports a Direction Error. Meaning that whatever the direction of the horizontal contour, when I overlaps the vertical contour the direction is wrong.


As I wish for a ‘Plus’ sign I want both contours to be Clockwise.

But the real point of this bug report is that the Xor’ing is point-size related. At one point size the contours are Xor’ed, at another point size they are not. At point 64 and below they are Xor’ed, at point size 65 and above they are not. And it is even worse than that, in FC9 it is at point size 64/65, In MS Word 2007 it is 40/41.


During development, I like to keep the contours separate as this means that the Bold Transform Wizard produces fewer plaited nodes.

If one contour is fully enclosed in another contour, the Clockwise / Anticlockwise works perfectly. The problem is if one contour is not fully enclosed by the other. When the contours overlap, FC9 reports a direction violation error whatever the direction of the contour, and at large point sizes the contours are rendered correctly, but at smaller point sizes they are Xor’ed. And it is application dependent where the point size break occurs.

I am on Windows 8.1 using FC9 and MS Word 2007.

Regards Julian

[ErwinDenissen]

The Font Test dialog is within FontCreator uses common Window controls, and thus use the Windows rasterizer. Same goes with Word, as it is also from Microsoft. I don’t know why one breaks with 64, but both are not FontCreator related issues.

Best you can do is to join the contours (merge).

During development, I like to keep the contours separate as this means that the Bold Transform Wizard produces fewer plaited nodes.

For a future release it might help if we add a “fix intersecting contours” feature on export.

[MikeW]

I’m using Windows 8.1 64-bit and this doesn’t happen to me. Neither in FC nor Word 2010.

[ErwinDenissen]

@Julian Griffin

Interestingly, when the contours overlap, the Real-time Validation reports a Direction Error. Meaning that whatever the direction of the horizontal contour, when I overlaps the vertical contour the direction is wrong.

It just says it can’t determine such problem due to other problems detected earlier.

[Julian_Griffin]

Hi, Thank you for your responses.

I have just tried Windows Notepad and it exhibits the same problem as I get in FC9 and MS Word. But the break is at 64/65 point; just as in FC9.

So this would suggest that the problem is in the Windows rasteriser. Either in the interaction of Windows rasteriser and the data written to the font file by FC9, or the interaction of Windows rasteriser and TrueType &/or OpenType file format. It may be in the font smoothing technology in use on a particular machine, because other glyphs (ones with fine detail) change how they are rendered at the 64/65 point mark.

MikeW, if I could imposes, would you run your test again at other point sizes, just to see if your’s is correct all the way down to small point sizes.

I too am on Windows 8.1 64 bit.

I get the same effect with TextMaker.

So it would seem to be Windows at fault. But two overlapping Clockwise contours seems to be a legitimate construct in TrueType & OpenType. By the time the font is rasterised it is out of FC’s hands. But unless every single other font created on every other font editing application merges all contours prior to writing the installable font file, this effect should be commonly evident. As it is not, it suggests that there is something in the data of fonts created in other font editors that may not be written or is written in FC9.

"Fix intersecting contours" or  "Merge intersecting contours" on export and Test Font, seems a good way forward.

Thank you both for your patience Julian.

[MikeW]

@Julian Griffin

…MikeW, if I could imposes, would you run your test again at other point sizes, just to see if your’s is correct all the way down to small point sizes.

Yep, this is in Word at point sizes ranging from 10 to 72. This is the same display no matter what application I use (including FC).

@Julian Griffin

Thank you both for your patience Julian.

Absolutely no worries.

This issue you are having is one reason why software developers, no matter if they are Microsoft down to the lowliest shareware developer, have so much fun making Windows applications. There is a near endless combination of hardware and software in a particular computer that it is mind boggling.

My personal opinion as regards the issue you are facing is that it could be video drivers. First thing I would do is to go to the video card maker’s site and check if there are new drivers.

[Julian_Griffin]

Hello MikeW,

The video driver did indeed update, but to no avail.

I then updated every driver listed in the Device Manager, and then I run a WIndows Update. And again some video hardware was updated. But again to no avail.

If anyone has a suggestion let me know and I’ll try it out.

Until we post again, Julian

[ErwinDenissen]

Do send me the font project file and I’ll test it on my system.

[PJMiller]

I do not experience this problem, I am using Windows 7, 64 bit. However I tested a font created by Font Creator on a Windows XP machine at work and it did exhibit the problem.

However this should not be an issue, for a simple glyph you should not overlap contours, if you are going to overlap contours you should make them into a union. For a composite glyph it is legitimate to overlap contours from different components of the composite.

Hope this helps.

[Julian_Griffin]

Hello Erwin,

My font is attached. It is still underdevelopment.

There are two glyphs that show this effect, U+E010 and U+E741.

And just to make sure it was not because I am using the Private Use area, I have added an overlapping Square and Circle to the Double Quote glyph U+0022, ", Shift+2.

1. Open the font
2. Test font (F5)
3. Type a "
4. Change the font size incrementally from 12 to 144

At some point you should see a Square & Circle with a hole become a fully black glyph.


NOTE: The fourth glyph in the screen shots is U+2219. At point 64 it is grey [the effect I wanted]. But at point size 65 it looks like radiating lines. It is in fact a set of concentric circles.

I also changed all the setting of WIndows Clear Type, but this had no effect on the result either.

Regards Julian
TPA No Custom Names WiP.fcp (164 KB)

[MikeW]

I don’t have time tonight to try and figure this out, it does happen in your project file. However, if I copy offending glyphs to a new file, or into one of my projects, it doesn’t happen.

Mike

[ErwinDenissen]

I didn’t see any additional contours with the " sign, but I was able to test U+E010 and can confirm this odd behavior.

Within the font project you have set the export settings to CFF outline format. While replying to this topic I assumed you where generating a TrueType based OpenType font.

This post at typedrawers discusses this as well, but no solution either, except for making sure contours don’t overlap:
http://typedrawers.com/discussion/517/whats-so-bad-about-overlapping-contours

Better avoid overlapping contours, but if you need them you might be better off with TrueType based outlines.

[Alfred]

@Erwin Denissen

This post at typedrawers discusses this as well, but no solution either, except for making sure contours don’t overlap:
http://typedrawers.com/discussion/517/whats-so-bad-about-overlapping-contours

Better avoid overlapping contours, but if you need them you might be better off with TrueType based outlines.

I’ve just read this in the submission guidelines at MyFonts:

@MyFonts

All overlaps between glyph parts must be removed from font files (you can keep them in your private work files).