TrueType - How to distinguish inner-outer contours
Chavdar Popov
I am testing an application that draws True Type fonts as line contours.
To draw filled fonts, I need to fill the space between the contours and
obviously 'take out' any holes - like you have 2 holes in the character
8.
I wonder if there is a flag or a way to tell if a glyph outline curve is
an 'inside' (hole) contour or an outside (border) contour ?
TIA
--
Chavdar Popov
/*
Please remove the NOSPAM from my address if responding by email.
*/
DaffyDuckMW
If the points go around the contour in clockwise order then it is
filled. If the points go around the contour in counter-clockwise
order it is a "hole". You can also think of it this way: If you
were walking along the contour from point to point the filled
(black) area would always be to your right. This is the case for
truetype fonts. Other types of fonts (like type1) work differently.
Matthew Welch
I Shot the Serif
http://home.att.net/~daffy-duck/
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Erwin Denissen
>filled. If the points go around the contour in counter-clockwise
>order it is a "hole". You can also think of it this way: If you
>were walking along the contour from point to point the filled
>(black) area would always be to your right. This is the case for
>truetype fonts. Other types of fonts (like type1) work differently.
This is almost always true. If you have only one contour, the direction
doesn't matter to Windows (the contour will always be filled).
Correct me if I'm wrong.
Regards,
Erwin Denissen
Louis Vosloo
Type 1: ink is on the left
Chavdar Popov wrote:
>
> Hi all
>
> I am testing an application that draws True Type fonts as line contours.
> To draw filled fonts, I need to fill the space between the contours and
> obviously 'take out' any holes - like you have 2 holes in the character
> 8.
>
> I wonder if there is a flag or a way to tell if a glyph outline curve is
> an 'inside' (hole) contour or an outside (border) contour ?
>
> TIA
>
> --
> Chavdar Popov
> /*
> Please remove the NOSPAM from my address if responding by email.
> */
--
Y&Y, Inc. mailto:sup...@YandY.com http://www.YandY.com
Louis Vosloo
Sort of :-) The built-in "erosion" operator in the Type 1 rasterizer
assumes that the ink is on the left. The Type 1 rasterizer (as far
as anyone knows --- the algorithm is trade secret) appears to draw
(at least conceptually) a contour that is approximately 1/2 pixel
too large all the way around (which is what you get if you ink any
pixel that has any part inside the contour). It then "erodes" this
using binary image processing (at least conceptually) to remove
the extra thickness (this extra 1/2 pixel thickness is there in
the PS "fill" operator also, where it is *not* compensated -
that is, the impllicit "fill" operator in Type 1 is *not* the
same as the PS "fill" operator, because it does the "erosion").
The advantage of this method over one that draws the "right size"
outline right away (TrueType) is that it avoids drop-outs. Which is
one of the worst problems to have to fix with "delta hinting" in
TrueType
fonts (it makes the rasterizer much simplert, but it creates a *lot*
more work for the font designer who has to fix up this unwanted
behaviour of the rasterizer).
Anyway, if you reverse the contour, you run the chance of "eroding"
in the wrong direction, making the character too fat. Already if
you "turn characters into outlines" the character looks too fat
because you are using the PS "fill" operator which does no "eroding".
If you use the built in rasterizer with the contour reversed you
actually get *twice* as much darkening.
A typical example of this problem can be seen in some fonts where
symmetrical characters (like left and right parens) where created
simply by mirroring one of them to create the other. It will look
much darker, even though the outline shape is no thicker...
The mileage you get will depend on the rasterizer ---
I assumed ATM above. And even with ATM what you get will
depend on such things as the character size. Large characters
are drawn using a different algorithm (which you can see when
you have an incorrectly drawn letter "O" where both contours
are drawn counter-clockwise instead of the inner being clockwise
--- in this case at small sizes the inner part will be filled in
black, while in the large size the inside will be white).
Chavdar Popov
>
>If the points go around the contour in clockwise order then it is
>filled. If the points go around the contour in counter-clockwise
>order it is a "hole".
This is really helpful, thanks to all who replied.
Problem now is, how do determine what the CW/CCW direction from just the
point data ? At any time the contour may be going in both directions so
it's no good examining adjacent points as the direction there may differ
from the overall direction...
Any ideas about this please ?
Ian Kemmish
cha...@NOSPAMmerituk.demon.co.uk says...
>
>.
>>
>>If the points go around the contour in clockwise order then it is
>>filled. If the points go around the contour in counter-clockwise
>>order it is a "hole".
>
>This is really helpful, thanks to all who replied.
>
>Problem now is, how do determine what the CW/CCW direction from just the
>point data ? At any time the contour may be going in both directions so
>it's no good examining adjacent points as the direction there may differ
>from the overall direction...
>
>Any ideas about this please ?
Calculate the area inside the contour using the good ole Trapezium rule. If
it's positive the contour goes (mostly) one way, if negative, the other, and
you only need do one example by hand to figure out which. The only flaw with
this method is that it doesn't refuse to give you an answer if the contour is a
figure of eight:-)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Ian Kemmish 18 Durham Close, Biggleswade, Beds SG18 8HZ, UK
i...@five-d.com Tel: +44 1767 601 361
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Behind every successful organisation stands one person who knows the secret
of how to keep the managers away from anything truly important.
Richard Kinch
> Problem now is, how do determine what the CW/CCW direction from just the
> point data ?
Having worked with computing this problem for years, I believe I have the
experience to answer authoritatively.
You'll want to study the Jordan Curve Theorem and winding number concepts
in topology. Computing the winding number is the solution to your problem,
but the hard fact is that it is very difficult to robustly compute winding
numbers in many real cases of Bezier contours.
Richard J. Kinch
More Bezier expertise at http://truetex.com/bezint.htm
Uwe Schröder
>
> you only need do one example by hand to figure out which. The only
> flaw with this method is that it doesn't refuse to give you an answer
> if the contour is a figure of eight:-)
Would it be too presumptuous to consider a font with contours that
intersect themselves as broken?
usch
Richard Kinch
> Calculate the area inside the contour using the good ole Trapezium rule.
I'm not sure what you're referring to by citing that rule, but if it involves
converting the Bezier contour to an approximating polygon and computing the
area of the polygon, that often doesn't work.
Richard J. Kinch
Publisher, TrueTeX brand typesetting software.
See http://truetex.com
Chavdar Popov
d.com> writes
>Calculate the area inside the contour using the good ole Trapezium rule. If
>it's positive the contour goes (mostly) one way, if negative, the other, and
>this method is that it doesn't refuse to give you an answer if the contour is a
>figure of eight:-)
I have done it and it works perfectly - thank you. I just used the b-
spline control points to calculate the area (as a closed polyline) and
it works correctly every time so far.
Chavdar Popov
<tru...@IDT.NET> writes
>Having worked with computing this problem for years, I believe I have the
>experience to answer authoritatively.
>
>You'll want to study the Jordan Curve Theorem and winding number concepts
>in topology. Computing the winding number is the solution to your problem,
>but the hard fact is that it is very difficult to robustly compute winding
>numbers in many real cases of Bezier contours.
This may be so but all I want is to define the direction of the contour
of true type fonts - which can be approximated to a simple polyline for
area computing and that seems to give consistent results - so it looks
like I have found a simple solution to my problem.
Chavdar Popov
<tru...@IDT.NET> writes
>I'm not sure what you're referring to by citing that rule, but if it involves
>converting the Bezier contour to an approximating polygon and computing the
>area of the polygon, that often doesn't work.
Do yo mean it doesn't work in the general case or that it doens't work
in the case of curves used in true type fonts ? I have tried it with
about 30 fonts and so far it works without a hitch. But I have to test
further.
Richard Kinch
> <tru...@IDT.NET> writes
> >I'm not sure what you're referring to by citing that rule, but if it involves
> >converting the Bezier contour to an approximating polygon and computing the
> >area of the polygon, that often doesn't work.
> Do yo mean it doesn't work in the general case or that it doens't work
> in the case of curves used in true type fonts ?
I mean the latter. For example, if three sequential points are colinear
then you don't know which side is in or out, and you don't know whether
the angle is +180 deg or -180 deg. Many such degenerate cases will cause
your method to fail.
Think about it. You're abstracting a complex curved contour as a very simple
polygon. That does not always preserve the toplogical properties.
Dave Opstad
> Would it be too presumptuous to consider a font with contours that
> intersect themselves as broken?
No, they're OK. For TrueType fonts on the Mac, the following are true as
of TT 2.0 and later (that is, since about 1994):
For simple glyphs, you should set bit 6 (0x0040) of the first outline flag
byte if the unhinted glyph outline has overlapping contours, or if
variation or hinting controls can ever cause any of the contours to
overlap.
For compound glyphs, you should set bit 10 (0x0400) of the flags word in
the first component if any of the component glyphs can ever have
overlapping contours, or if any component can ever overlap the contours of
another component in the compound glyph. In some older documentation, bit
4 of the compound glyph flags is designated for overlapping contours. This
bit is now obsolete.
For more info, look for the "Overlapping contours" subsection in the
"Changes from TrueType 1.0" section, near the bottom of this document:
http://17.254.3.162/TTRefMan/RM06/Chap6GXIntro.html
Dave Opstad
Apple Font Technology Guy
Richard Kinch
> For more info, look for the "Overlapping contours" subsection in the
> "Changes from TrueType 1.0" section, near the bottom of this document ...
Is this implemented in the Windows TrueType engine?
How do you download non-overlapping outlines to Type 1 devices?
Dave Opstad
<tru...@IDT.NET> wrote:
> Is this implemented in the Windows TrueType engine?
You'll have to ask Microsoft about this one. As my posting stated, I was
only describing the situation on the Mac.
> How do you download non-overlapping outlines to Type 1 devices?
If overlapping is detected, the TrueType streaming code converts the
outline to a path, simplifies the path to remove overlaps using path
geometry, then converts the path back to an outline. This all happens
internally to TrueType, before the outlines get converted into PostScript
and streamed.
Dave
Richard Kinch
> If overlapping is detected, the TrueType streaming code converts the
> outline to a path, simplifies the path to remove overlaps using path
> geometry, then converts the path back to an outline. This all happens
> internally to TrueType, before the outlines get converted into PostScript
> and streamed.
Really? That's so complicated--lots of Bezier intersections and such--
compared to mere rasterization.
Uwe Schröder
>
> > Would it be too presumptuous to consider a font with contours that
> > intersect themselves as broken?
>
> No, they're OK.
> flag byte if the unhinted glyph outline has overlapping contours,
This is something completeley different. Of course overlapping contours
are ok (you can create a $ sign by overlapping an S with a vertical bar,
for example). What Ian and I were talking about are contours that
intersect *themselves*, not *each other*. If you have a single contour
in the shape of an "8", that would enclose two oval areas, one
clockwise, the other counter-clockwise. I wonder if the standard permits
that.
> For more info, look for the "Overlapping contours" subsection in the
> "Changes from TrueType 1.0" section, near the bottom of this document:
> http://17.254.3.162/TTRefMan/RM06/Chap6GXIntro.html
Very informative link, thanks. But as I said, it only mentions
overlapping, not self-intersecting contours.
usch
Chavdar Popov
<tru...@IDT.NET> writes
>I mean the latter. For example, if three sequential points are colinear
>then you don't know which side is in or out, and you don't know whether
>the angle is +180 deg or -180 deg. Many such degenerate cases will cause
>your method to fail.
Well I have tried it with lots of fonts and thousands of glyphs and it
has not failed yet to identify a hole. For me that is good and reliable
enough - certainly is sellable :) Even if it failed on a 1 in 1000 case
this is the only solution I have and it looks like it is a good one.
>
>Think about it. You're abstracting a complex curved contour as a very simple
>polygon. That does not always preserve the toplogical properties.
The point is not about calculating the exact area in a bezier curve ,
but simply to find the sign of the area of a true type font curve. For
this the approximation with points should be good enough - TTrue type
font curves are only of the second order anyway and they are pretty
tight - there aren't more than 2 or 3 points that are not on the actual
contour. Also , the curve doesn't cross itself. I did some tests and
the deviation in the actual area values from the 'real' one are 1-5% so
I assume the sign would be correct, so I won't even have sub-divide the
curve between its points as it seems reliable as it is.
What I can't figure out now is how to get the actual height of the body
of the capital letters as a parameter for the whole font ?
I can get the glyph in design units and draw it, but I read all the
structures over and over again and could not figure out if just the
height of the capital characters is available at all on font level.
AT the moment I just find the black box of the H char to scale the
whole font's height - works OK but I would like to change it.
Regards
Richard Kinch
> In article <7km1r3$9...@nnrp2.farm.idt.net>, Richard Kinch
> <tru...@IDT.NET> writes
> >I mean the latter. For example, if three sequential points are colinear
> >then you don't know which side is in or out, and you don't know whether
> >the angle is +180 deg or -180 deg. Many such degenerate cases will cause
> >your method to fail.
> Well I have tried it with lots of fonts and thousands of glyphs and it
> has not failed yet to identify a hole. For me that is good and reliable
> enough - certainly is sellable :) Even if it failed on a 1 in 1000 case
> this is the only solution I have and it looks like it is a good one.
I cannot question your experience. But I still don't see how the method
can resolve the example I've given. Think of the point of a cleft in a "B",
the middle of the "cleavage", so to speak. Say the endpoint and incoming and
outgoing control points are colinear. How do you compute that turning angle?
Is it +180 or -180 degrees? If you choose wrongly, you're off by 360 degrees,
which will turn your winding number to 0.
cpo...@my-deja.com
>
> I cannot question your experience. But I still don't see how the
method
> can resolve the example I've given. Think of the point of a cleft in
a "B",
> the middle of the "cleavage", so to speak. Say the endpoint and
incoming and
> outgoing control points are colinear. How do you compute that turning
angle?
> Is it +180 or -180 degrees? If you choose wrongly, you're off by 360
degrees,
> which will turn your winding number to 0.
>
I don't understand your example - why do you need to calculate angles ?
Imagine your B as 2 squares on top of each other but connected only at
the left middle 'cleavage' point - this has the rough topology of a B
letter. The way the trapezium thing works is that it calculates and adds
the area under every straight portion of the approximated contour with a
varying sign. You have 4 horisontal ' strokes' that generate areas in
the total mix. So in the case of the 'cleavage' when you go counter
clockwise into it you will generate a positive area block and when you
get out' of it following the same horisontal line you will generate a
negative one - this is how it should be and it would not cause a problem
- and indeed it doesn't for any of the B's in all fonts on my computer.
Richard Kinch
> The way the trapezium thing works is ...
Maybe I'm not understanding the trapezium thing. What do you mean by that?
The sum for the signed area of a polygon?
Chavdar Popov
<tru...@IDT.NET> writes
>Maybe I'm not understanding the trapezium thing. What do you mean by that?
>The sum for the signed area of a polygon?
Well I found out the other day since the start of this thread that this
is when you approximate the curve with little lines Xi,Yi Xi+1, Yi+1 and
you integrate it as such finding the areas under each of the little
lines as SUM (Xi+1-Xi)*(Yi+1+Yi)/2 . I had no idea this was called
trapezium rule as I am not a native english speaker. So the ones that go
left to right give a plus sign and vice versa so the total sign of the
area depends on the direction of travel - not sure if that is all there
is to it but I it works, especially in my case where I have no
requirement for precision whatsoever. Anyway I tested it with some weird
curves I hand drew on my cad system.
Richard Kinch
> I had no idea this was called
> trapezium rule as I am not a native english speaker.
I had not heard this name either, although I know the formula, and the
several textbooks I own that cite the formula don't call it by that name.
> ... it works, especially in my case where I have no
> requirement for precision whatsoever.
It works in the sense that the area-of-a-polygon formula is true. But it
doesn't work for glyphs where the control-point polygon self-intersects, which
is not uncommon. I can't explain why you haven't run into such cases yet.
My experience is more with 3rd order Beziers than 2nd degree, and this may
account for the rarity in your experience versus mine.
Note that a Bezier outline that does not self-intersect may still have a
control-point polygon that self-intersects. So the TrueType or Type 1
constraint that outlines don't self-intersect is no guarantee about the
non-degeneracy of the control-point polygon.
This is more or less the point I've been making in this thread. I believe
a robust algorithm must of necessity integrate the continuous contour, not
just sum the control polygon. In practice, this means a numerical integration
of unknown tolerance; sometimes the control point polygon is fine enough,
sometimes not.
This is what topology is all about. Analytic geometry is just not enough
horsepower.
Chavdar Popov
<tru...@IDT.NET> writes
>It works in the sense that the area-of-a-polygon formula is true. But it
>doesn't work for glyphs where the control-point polygon self-intersects, which
>is not uncommon.
self-intersects ?
> I can't explain why you haven't run into such cases yet.
>My experience is more with 3rd order Beziers than 2nd degree, and this may
>account for the rarity in your experience versus mine.
True Types seem to be quadratic b-splines always - these I represent as
bezier curves of 3rd order because my graphics engine supports that but
these bezier curves have a 0 as a 3rd order coefficient.
>
>Note that a Bezier outline that does not self-intersect may still have a
>control-point polygon that self-intersects.
I agree but the point is - will that ever happen in a True Type font ?
> So the TrueType or Type 1
>constraint that outlines don't self-intersect is no guarantee about the
>non-degeneracy of the control-point polygon.
I am not so sure about that. One thing I forgot to mention is that I am
using the b-spline control points to calcuate the area - these are not
the same as the bezier points although they describe the same curve
segment. You get a point on the contour, then usually 1 or 2 points in
between and the end point again on the contour. I think it unlikely the
in-between points would ever form a loop within one segment.
>
>This is more or less the point I've been making in this thread. I believe
>a robust algorithm must of necessity integrate the continuous contour, not
>just sum the control polygon. In practice, this means a numerical integration
>of unknown tolerance; sometimes the control point polygon is fine enough,
>sometimes not.
The question is 'Do you need an as precise as possible integration of a
true type curve in order to find its direction' ? .
I think not, I hope we'll come to the true answer eventually.
Richard Kinch
> Can you give me one such example please where a glyph control polygon
> self-intersects ?
Here's what I'm talking about, set forth in PostScript you can just
print out or view. It can even be considered 2nd order, since the
off-curve points in the curveto are identical.
%!PS
%
% PostScript example of a Bezier contour which
% is non-self-intersecting, yet which has a control
% polygon which self-intersects.
%
% Richard Kinch, June 1999
% ki...@truetex.com
%
100 100 moveto
300 100 lineto
300 200 lineto
200 80 200 80 100 200 curveto
closepath gsave 0.9 setgray fill grestore stroke
%
100 200 moveto
200 80 lineto
300 200 lineto
[1 5] 0 setdash stroke
%
showpage
Richard Kinch
> Can you give me one such example please where a glyph control polygon
> self-intersects ?
Here's another example. This is a dingbat character which has positive area,
but the control point polygon has zero area, causing your method to fail.
A similar example could easily be made from 2nd order curves.
%!PS
%
% PostScript example of a Bezier contour which
% is non-self-intersecting and of positive area,
% yet which has a control polygon of zero area.
%
% Richard Kinch, June 1999
% ki...@truetex.com
%
100 200 moveto
200 200 200 200 200 100 curveto
200 200 200 200 300 200 curveto
200 200 200 200 200 300 curveto
200 200 200 200 100 200 curveto
closepath gsave 0.9 setgray fill grestore stroke
%
showpage
Chavdar Popov
> 300 100 lineto
> 300 200 lineto
> closepath gsave 0.9 setgray fill grestore stroke
This example does not have 0 area so the direction will be defined
correctly.
Chavdar Popov
>> self-intersects ?
>
>Here's another example. This is a dingbat character which has positive area,
>but the control point polygon has zero area, causing your method to fail.
>A similar example could easily be made from 2nd order curves.
>
I see your point but the shape you are describing is not a real
character as it would be described in a TrueType font, is it ?
I think if that were a TrueType character it would have had intermediate
points along the contour. Anyway I put a trap for 0 area in my program
and ran it though about 40 fonts and it did not locate any 0 areas.
While trying it I found though that in the Dixieland font all the
directions are reversed compared with the other fonts - so I wonder how
windows draws that font correctly.
Chavdar Popov
<cha...@NOSPAMmerituk.demon.co.uk> writes
>
>>If the points go around the contour in clockwise order then it is
>>filled. If the points go around the contour in counter-clockwise
>>order it is a "hole".
Guys
I have just found out that al the characters in the Dixieland font
are described in reverse direction to all other fonts I tried - i.e the
holes appear as the solids and the solids are described as holes.
Is this possible - or should I look for bugs in my program ?
Thanks
Louis Vosloo
> In article <giy$iCAPyP...@merituk.demon.co.uk>, Chavdar Popov
> <cha...@NOSPAMmerituk.demon.co.uk> writes
> >
> >>If the points go around the contour in clockwise order then it is
> >>filled. If the points go around the contour in counter-clockwise
> >>order it is a "hole".
>
> Guys
>
> I have just found out that al the characters in the Dixieland font
> are described in reverse direction to all other fonts I tried - i.e the
> holes appear as the solids and the solids are described as holes.
>
> Is this possible - or should I look for bugs in my program ?
There are quite a few fonts that have the wrong winding direction
for some glyphs. In Type 1 this "works" if the character has
no holes (or if you use a rasterizer that uses eofill instead of fill).
but it means the character will bedrawn "too fat".
Werner Lemberg
> In article <giy$iCAPyP...@merituk.demon.co.uk>, Chavdar Popov
> <cha...@NOSPAMmerituk.demon.co.uk> writes
>>
>>>If the points go around the contour in clockwise order then it is
>>>filled. If the points go around the contour in counter-clockwise
>>>order it is a "hole".
> Guys
> I have just found out that al the characters in the Dixieland font
> are described in reverse direction to all other fonts I tried - i.e the
> holes appear as the solids and the solids are described as holes.
> Is this possible - or should I look for bugs in my program ?
In the FreeType library (www.freetype.org), you can enable/disable the
correct rendering of such fonts during compilation.
Werner
Dave Fawthrop
Louis Vosloo <sup...@YandY.com> wrote in message
news:37775E10...@YandY.com...
> Chavdar Popov wrote:
>
> > In article <giy$iCAPyP...@merituk.demon.co.uk>, Chavdar Popov
> > <cha...@NOSPAMmerituk.demon.co.uk> writes
> > >
> > >>If the points go around the contour in clockwise order then it
is
> > >>filled. If the points go around the contour in counter-clockwise
> > >>order it is a "hole".
> >
> > Guys
> >
> > I have just found out that al the characters in the Dixieland font
> > are described in reverse direction to all other fonts I tried -
i.e the
> > holes appear as the solids and the solids are described as holes.
> >
> > Is this possible - or should I look for bugs in my program ?
>
> There are quite a few fonts that have the wrong winding direction
> for some glyphs. In Type 1 this "works" if the character has
> no holes (or if you use a rasterizer that uses eofill instead of
fill).
> but it means the character will bedrawn "too fat".
>
I have just made my font so that it works :-( some with the outer
contour clockwise and the hole clockwise, and some the outer contour
clockwise and the hole counter clockwise.
It is important that these are rendered exactly the same size, because
in use a continuous "string" appears to go from one glyph to the next.
If I understand Louis properly I must go back and make all the outer
contours clockwise and the holes counter clockwise. :-(((((((
Or have I got it wrong.
--
Dave Fawthrop <hyp...@c-h.win-uk.net> <http://www.win-uk.net/~hyphen>
Computer Hyphenation Ltd, Hyphen House, 8 Cooper Grove, Halifax HX3
7RF, UK Tel/Fax/Answer +44 (0)1274 691092.
Hyphenologist is sold as C source code and splits 50 languages.
Also on WWW site: Wordlist FAQ, VDU Glasses, SpiralsCeltic Font.
Richard Kinch
> >> Can you give me one such example please where a glyph control polygon
> >> self-intersects ?
> >
> >Here's another example. This is a dingbat character which has positive area,
> >but the control point polygon has zero area, causing your method to fail.
> >A similar example could easily be made from 2nd order curves.
> >
> I see your point but the shape you are describing is not a real
> character as it would be described in a TrueType font, is it ?
It certainly is a plausably real example, although I just made it up.
> I think if that were a TrueType character it would have had intermediate
> points along the contour.
No reason to think so. It works, and it expresses the shape most economically.
I satisfied your challenge. Are you now retreating into a claim that
curves should first be bisected to fit your theory? I can construct cases
which will still fail.
My point stands: a robust solution to the general orientation problem is
difficult.
Chavdar Popov
>
>> I think if that were a TrueType character it would have had intermediate
>> points along the contour.
>
>No reason to think so. It works, and it expresses the shape most economically.
>
>I satisfied your challenge.
But you didn't ! The shape you refer to is not a real one. If you find
such a character in an existing font then I guess you would prove me
wrong.
My guess is there wouldn't be a character designed in such a minimalist
way, especially considering that some 'hand' fonts in windows have
glyphs with 400-500 hundred segments in one contour. The closest to your
char I could find was in the dixieland font and that had 2 segments per
side - each with 3 control points.
> Are you now retreating into a claim that
>curves should first be bisected to fit your theory? I can construct cases
>which will still fail.
The point is - can you use this method reliably with actual fonts - not
with imaginary characters designed to fail it. I have tried it with
about 50 fonts and it works. It may sound a bit cynical but this rate of
success it pretty good considering the level of bugs you find in today's
commercial software. The smallest area I found in any font was about 200
in design units - safely above 0 even for the most weird characters.
If you have some 'suspect' fonts in mind - please send me them so I can
try them for 0 area with my program.
>
>My point stands: a robust solution to the general orientation problem is
>difficult.
I have never questioned your point that finding the orientation of a
general bezier curve is difficult. But we are talking here about finding
the direction of a truetype contour - this I think is quite easy as you
only need simple arithmetic to calculate it. In fairness this is only
based on my two weeks experience with truetype fonts but even if your
chimaeric 0 area character existed then all you need to do is add a
middle point to each curve at t=0.5 and redo the calculation just once
more.