Re: [ft-devel] [patch] emboldening rework v1

[Behdad Esfahbod]

On 04/20/2012 11:59 AM, Alexei Podtelezhnikov wrote:
> On Thu, Apr 19, 2012 at 2:12 PM, Behdad Esfahbod <address@hidden> 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