If merging the overlapping components of a glyph doesn't reduce the number of points, why bother? (Take as a good example '#', where merging doubles the number of points.)
So far, I've been reading that inner glyph intersections should be avoided, but I can only suspect it's a rendering issue.
0
Comments
[Hullo, Filip. Good to see you on TypeDrawers.]
I have always stood for the standards on this, encouraging app developers to do so as well. And for app developers, that means listening to the definition in the standard, and then the user, and then doing the non brain damaged thing. cAd! Fuck me, they rarely kern. Sign cutters with drop shadows and contour treatments should be creating their masters in intelligent apps, like Adobe's, and if they have problems they should tell adobe, who should follow their own standards.
And font tool wise, while others prefer to stand around and tell horror stories, a tool that allows contours, overlapping contours, composites, overlapping composites, contours and composites, as well as overlapping composites and contours, to exist in a source glyph during the design and generalization processes of founding, allowing filters to decide between rasterizer intel and file size requirements* e.g., in the productization stage... You got one?
*if you took a hyphen, duplicated it, spun that duplicate 90 degrees and called it a plus, it should work with but 8 points. Removing overlap, makes 12 points. Doing the same to breve, doubles the size when overlap is removed for the off curve points. Glyphs with multiple curving overlaps drive up the point count dramatically. Scripts with glyphs with lots of these overlaps, triple, or worse, the file sizes of fonts carrying those scripts, perhaps to phones, where sign cutting is rare, so far.
So what do with products, is do everything. What to do about sources, depends, on how good you want to be to yourself and all of your clients, even the ones you don't have yet, IMHO. I.E., manners have nothing to do with it;)
I recently accidentally left overlaps in a pre-release version of a font, sent to my Kickstarter backers. One of them spotted it and complained, because of what the Adobe PostScript outlines rasterizer was doing to it in InDesign. http://www.thomasphinney.com/2014/01/overlapping-paths-in-type-design/
But on the specimen page, the problem is not there as that page has`-webkit-font-smoothing: antialiased` and it seems to hide the overlaps (for Safari and Chrome but not Firefox which needs Firefox specific declaration [?] ).
I can assure you that this is not intended. By default we always flatten all contours before we generate final font files. But in this case it slipped through...
We have notified the good folks at Webtype about the problem, and it should be solved soon.