On 04/20/2012 11:59 AM, Alexei Podtelezhnikov wrote: > On Thu, Apr 19, 2012 at 2:12 PM, Behdad Esfahbod <[email protected]> wrote: >> On 04/18/2012 01:36 PM, Alexei Podtelezhnikov wrote: >>> When we talk about an outline as a collection of contours, things get >>> out of control very quickly, because to do a good job you have to >>> inspect the whole layout of contours. For example the orientations of >>> both contours is the same in "=" and different in "o". So we may rely >> >> Actually no. Now I guess *you* got confused the same way that I got! In >> '=', >> each contour can have whatever direction it wants. Non-zero winding renders >> all four possibilities fine. > > There is a difference between what the FreeType renderer can handle, > and what is strandard. The opposite orientation of two contours in "=" > would be a font bug.
If it works fine with pretty much all existing rasterizers, font generation tools are allowing it (maybe after a warning), and is out there in the wild, it *is* the standard, not what's written on some webpage... >>> on EITHER the orientation of the contour with the largest area OR the >>> the sum of all contour areas. >>> >>> So here is my simple suggestion. Return NONE when the orientation >>> according to the the largest contour is not the same as the >>> orientation according to the sum of all. >> >> This will result in false positives, and that's bad. > > What do you call false positives? I disagree if you refer to a buggy > font that FreeType can render. What I call false positive is a glyph that has outermost contours with both directions, but FreeType tells me that it's one way or the other. If I ever call this API, I like to be able to trust it's non-NONE return value. Otherwise, I don't see the value of this API. We *know* "non-standard" fonts are out there in the wild... >>> Thoughts? Once again, the current implementation is broken so it is >>> not like we need to care about backwards compatibility. >> >> It isn't impossible to detect the direction of all outer contours, but is >> much >> more involved than your signed-area-based algorithm indeed. > > I'm starting to see some need for the diagnostic function. Perhaps, so > many buggy fonts are out there because FreeType and others never > provided such API. I'll have my intern look into this next week as this is one of the main limitations of GLyphy right now. >> Perhaps the question to be answered is, is anyone using that API right now? > > Internally, only the emboldener and the stroker uses this function. > The renderers are immune. Makes sense. I should try reproducing the misbehavior using the emboldener then. behdad _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
