[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 |
Hello,
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.
Regards,
- David Turner
- The FreeType Project (www.freetype.org)
> -----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
> http://lists.nongnu.org/mailman/listinfo/freetype-devel
>
***********************************************************************************
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
message.
***********************************************************************************