Oops, sorry for all those brackets.

this should not be a problem with apps that send an outline font to the OS's rendering and get a bitmap back to send to the screen or to print. there, bitmaps are combined so no holes appear. if an app goes from font to outline, like illustrator allows, sometimes holes might appear.

This is a path direction thing, as far as I know. If two overlapping paths have paths in opposite directions, the overlap knocks out. But that's an old PostScript thing. I assume it affects TrueType paths also, but do not know for sure.

It's definitely a path direction thing. Check and make sure all paths, outside and inside are going in the correct direction.

If not , the overlapping parts will give you those 'white holes', as you call them.

Last 2 posts are simply not correctly informed. Sorry! Read TT spec.

What then about http://www.microsoft.com/typography/cursivescriptguidelines.mspx ?

Here is what I get from the Adobe Type 1 Font Format spec.

If two filled subpaths in a character overlap, there may be no problem when the character is filled. However, a Type 1 font program can also be stroked along its outline when the user changes the PaintType entry in the font dictionary to 2. In this case, overlapping subpaths will be visible in the output; this yields undesirable visual results in outlined characters. Always construct the character paths with outlined output in mind.

Of course, you can always do such a thing with the appropriate software (left, the letters were stroked individually, right, they were merged and then stroked)

[...] is it is possible [...] to make a script font that could be stroked?

I mean a connected script.

What a confusing thread. Isn't there a difference between overlaps within the definitions of single glyphs (no good), and overlaps that happen on the font level between different glyphs? Isn't the latter necessarily what happens in connecting scripts? (Bear with me, I've never made one.)

The distinction "single glyph" versus "font level" is no so clear when you consider big composed characters in mathematical formulas. Here is an example where the overlap is made clear after converting to outlines.

Sorry, I am afraid I was mistaken about the parts for the braces. Here I took them apart to better see, after realizing things were not so clear as I first thought.

Here is however how Adobe's Bickham script characters fit together.

Hmm, and, after all, the little pieces that are part of the braces overlap with the other parts. Here is a closer look after moving just a little the small piece.

I am in a process of making a connected script and I encountered no problems with overlapping characters. The only requirement is for the paths of your glyphs to be in the same direction.

Same goes for overlapping paths in an individual glyph.

There is indeed a problem if you want to visualize the outlines of the font, but any software that lets you do that must also provide you with an option to merge the separate forms into one (as in the Q&A example above). In Adobe Illustrator that is done with the "pathfinder" option

I am with Nina. My take would be that each glyph is an instruction for the PS or TT-interpreter, and thus that won’t be interference from glyph to glyph.

(Where are the tech-savvy guru’s when you need them : ))

My take would be that each glyph is an instruction for the PS or TT-interpreter, and thus that won’t be interference from glyph to glyph.

That seems to be true for text editors, though I'd like to see it explicitly specified. On the other hand, Inkscape (and probably Adobe Illustrator) keeps track of the winding direction. Here, I installed and used in Inkscape a (postscript otf) font with a small o that winds opposite to the small ô. If I put the o on top of the ô, there is no problem, they merge nicely and give the ô on the left. If I copy them and appy path > combine on the copy, I get the ô on the right hand side; the two glyphs o almost cancel.

Illustrator doesnt keep track of directions. For it, holes are just holes, not separate shapes.

If you want to make webfonts, the Bickham method will cause som rendering issues.

@ Alexander: I haven’t tested in recent versions of Illy, but up to v 5 Illy was very direction-conscious. Ungrouped outlines had to be carefully monitored re the directions to prevent non-holes : )

I cant know about that - Version 5 has been released before I've learned the alphabet. Probably that is why I dont dig the whole "directions" concept: shouldn't a shape that has a hole in it, should be just that - a shape with a hole.