[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ft-devel] FT_Glyphslot_Embolden is broken at sometimes.

From: Turner, David
Subject: RE: [ft-devel] FT_Glyphslot_Embolden is broken at sometimes.
Date: Thu, 27 Oct 2005 10:26:59 +0200


the problem is that treating such broken glyphs correctly requires
some heavy-lifting algorithms. That's because:

  - any self-intersecting curve cannot be categorized as either
    an "inside" or "outside" curve, since it is both.

  - more generally, any intersections between outlines creates
    odd points that require, for proper emboldening, to basically
    break the curves into non-intersecting ones, which will lead
    you to compute the intersections of liberal bezier arcs, and
    this problem is certainly _not_ easy, is heavy on CPU, and
    prone to significant rounding errors.

  - even if you ignore the problems of intersections, properly
    determining the orientation of non-intersecting outlines is
    equivalent to performing the fill algorithm, i.e. you need
    to compute intersections of bezier arcs with horizontal
    lines, which is also not trivial, and prone to errors.

  - another option is to use heuristics to compute the orientations,
    which is what we currently do, as well as approximation.

It turns out that there is a reason why the Postscript specification
mandates that all outlines are non-intersecting and correctly oriented,
because the PS designed knew their curves pretty well !!

It seems the TrueType designers didn't think they had a problem after
all, since the sub-glyph transform operation allows for outline
reversal :-)

There may be a way to improve the heuristics, but they'll *never*
be 100% accurate. You'll always be capable of finding some badly
designed fonts.However, I've not studied this at the moment.

In theory, we should be able to find quickly wether a given outline
may be problematic or not. It must guarantee 0% false negatives, but
allow for false positives. The "non-problematic" outlines can be treated
with the current algorithm. The "problematic" ones should be passed
into another "reversal" algorithm that tries to compute correct orientations
with a finer heuristic, even if the latter is not 100% foolproof.

However, all of this is rather complex, and I don't have much free
time at the moment. Any one wants to volunteer on this ? You'll need
good knowledge of discrete math and geometry.


- David Turner
- The FreeType Project  (

> -----Message d'origine-----
> De : address@hidden
> [mailto:address@hidden
> la part de
> sunmoon1997
> Envoyé : jeudi 27 octobre 2005 04:03
> À : Chia-I Wu
> Cc : address@hidden
> Objet : Re: [ft-devel] FT_Glyphslot_Embolden is broken at sometimes.
> Thanks all  you guys, but it sounds bad if  it's unable to work around
> this in freetype.
> Chia-I Wu wrote:
> >On Wed, Oct 26, 2005 at 11:00:09PM +0200, Werner LEMBERG wrote:
> >
> >
> >>>    FT_Glyphslot_Embolden works at most of time, but sometimes it
> >>>doesn't(see attachment).  To run the testcase, you need simsun.ttc
> >>>from windows.  Any comments?
> >>>
> >>>
> >>Which FT version?
> >>
> >>Unfortunately, I don't have simsun.ttc so I can't test it.  Chai-I?
> >>
> >>BTW, I don't have cairo either -- can you reproduce the problem with
> >>ftview from the ft2demos package, using the current CVS?
> >>
> >>
> >The character shown in the .png (U+60CA) has a contour of width 0,
> >namely all points have same x value (bug?), in the left top corner.
> >It misleads FT_Outline_Get_Orientation.  Thus instead of emboldened,
> >each stroke got shrinked.
> >
> >Similar issues have already been seen in some free
> traditional Chinese
> >fonts.  They have glyphs consisting of components of different
> >orientations.  I think it's a bug of the font and since
> those fonts are
> >actively maintained, I reported the issue to the font authors, after
> >failed to work around this in freetype.
> >
> >
> >
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
Information contained in this email message is confidential and may be 
privileged, and is intended only for use of the individual or entity named 
above. If the reader of this message is not the intended recipient, or the 
employee or agent responsible to deliver it to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the address@hidden and destroy the original 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]