Re: [ft-devel] FT_Get_Char, FT_Get_Next_Char
Nicolas,
It looks to me like you terminate the loop too early. gindex == 0 is the last
glyph; you could use do {} while (); rather than while () {}.
David %^
From: freetype-devel-bounces+david.bevan=pb@nongnu.org
[mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of
Nicolas Rougier
Sent: 23 September 2011 16:52
To: Freetype-devel@nongnu.org
Subject: [ft-devel] FT_Get_Char, FT_Get_Next_Char
Hi folks,
Using the following code with the attached (very small) font:
#include stdio.h
#include ft2build.h
#include FT_FREETYPE_H
int main(int argc, char **argv)
{
FT_Face face;
FT_UInt gindex;
FT_ULong charcode;
FT_Library library;
FT_Init_FreeType( library );
FT_New_Face( library, ./zapf.cff, 0, face );
fprintf( stderr, Num glyphs: %ld\n, face-num_glyphs );
charcode = FT_Get_First_Char( face, gindex );
while ( gindex != 0 )
{
fprintf( stderr, char: %ld (index = %d)\n, charcode, gindex );
charcode = FT_Get_Next_Char( face, charcode, gindex );
};
FT_Done_Face( face );
FT_Done_FreeType( library );
}
I'm getting the following output:
Num glyphs: 3
char: 32 (index = 1)
char: 160 (index = 1)
How do I get the last char ? (or did I do something wrong ?)
Nicolas
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Get_Char, FT_Get_Next_Char
In fact, even if/when the synthesizing of the Unicode charmap for ZapfDingbats
is corrected, so that FT gives you
0: platform 3, encoding 1, language 0 (active)
0x0020 = 1
0x00a0 = 1
0x25bc = 2
you will only get two glyphs (but three characters) with the loop.
David %^
-Original Message-
From: freetype-devel-bounces+david.bevan=pb@nongnu.org
[mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of
David Bevan
Sent: 26 September 2011 09:13
To: Nicolas Rougier
Cc: Freetype-devel@nongnu.org
Subject: Re: [ft-devel] FT_Get_Char, FT_Get_Next_Char
Nicolas,
My response was perhaps too hasty. It wasn't clear what character/glyph you
believed you weren't getting.
I (possibly incorrectly) assumed that what you wanted was access to the .notdef
character (which is what is returned with gindex == 0).
As Werner has pointed out, the Unicode charmap (charmap 0) is incorrectly
synthesised, so the a77 glyph is not associated with any character. I'm still
not sure whether this fact really answers your question.
Note the difference between glyphs and characters. The example code returns the
glyphs for all the characters defined in the charmap. If you want the .notdef
(to use for characters not defined in the charmap), then you need my
suggestion. If you want all the glyphs (as opposed to all the characters) in
the font, then you can just increment gindex up to face-num_glyphs - 1.
Perhaps you already understood all that though.
However, you did say:
The actual question was related to the number of glyphs (3) and the
use of first/next char. Am I not supposed to be able to get all
glyphs using them? Obviously I only get 2 of them while I would have
expect 3.
The simple answer is no; you only get glyphs associated with characters using
first/next char.
If you had selected charmap 1 (which is correctly handled by FT):
1: platform 7, encoding 2, language 0
0x0020 = 1
0x0074 = 2
then you would (still) get only two characters/glyphs with your loop / the
example code.
Hth a bit.
David %^
-Original Message-
From: Nicolas Rougier [mailto:nicolas.roug...@inria.fr]
Sent: 26 September 2011 08:47
To: David Bevan
Cc: Freetype-devel@nongnu.org
Subject: Re: [ft-devel] FT_Get_Char, FT_Get_Next_Char
I used the example code from the documentation:
http://freetype.sourceforge.net/freetype2/docs/reference/ft2-base_interface.html#FT_Get_First_Char
I'm not sure the do{} while() your proposed would change anything (I'm getting
0 as a charcode after the loop).
Nicolas
On Sep 26, 2011, at 9:38 , David Bevan wrote:
Nicolas,
It looks to me like you terminate the loop too early. gindex == 0 is the last
glyph; you could use do {} while (); rather than while () {}.
David %^
From: freetype-devel-bounces+david.bevan=pb@nongnu.org
[mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of
Nicolas Rougier
Sent: 23 September 2011 16:52
To: Freetype-devel@nongnu.org
Subject: [ft-devel] FT_Get_Char, FT_Get_Next_Char
Hi folks,
Using the following code with the attached (very small) font:
#include stdio.h
#include ft2build.h
#include FT_FREETYPE_H
int main(int argc, char **argv)
{
FT_Face face;
FT_UInt gindex;
FT_ULong charcode;
FT_Library library;
FT_Init_FreeType( library );
FT_New_Face( library, ./zapf.cff, 0, face );
fprintf( stderr, Num glyphs: %ld\n, face-num_glyphs );
charcode = FT_Get_First_Char( face, gindex );
while ( gindex != 0 )
{
fprintf( stderr, char: %ld (index = %d)\n, charcode, gindex );
charcode = FT_Get_Next_Char( face, charcode, gindex );
};
FT_Done_Face( face );
FT_Done_FreeType( library );
}
I'm getting the following output:
Num glyphs: 3
char: 32 (index = 1)
char: 160 (index = 1)
How do I get the last char ? (or did I do something wrong ?)
Nicolas
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [bug #33992] heap underflow in ft_stroke_border_close
Werner,
The following is preferable to fix this:
--- old\ftstroke.c Sat Jul 02 11:37:30 2011
+++ new\ftstroke.c Mon Aug 15 15:46:29 2011
@@ -,9 +,13 @@
if ( error )
goto Exit;
- error = FT_Stroker_EndSubPath( stroker );
- if ( error )
-goto Exit;
+ /* don't try to end the path if no segments have been generated */
+ if ( !stroker-first_point )
+ {
+error = FT_Stroker_EndSubPath( stroker );
+if ( error )
+ goto Exit;
+ }
first = last + 1;
}
Thanks.
David %^
-Original Message-
From: Werner LEMBERG [mailto:invalid.nore...@gnu.org]
Sent: 12 August 2011 07:55
To: Werner LEMBERG; David Bevan
Subject: [bug #33992] heap underflow in ft_stroke_border_close
Update of bug #33992 (project freetype):
Status:None = In Progress
Assigned to:None = wl
___
Follow-up Comment #1:
David, please check the bug fix.
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?33992
___
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [ft] outline get cropped when render chinese simkai.ttf font
This is also fixed by the fix for Savannah bug #33992.
Thanks.
David %^
-Original Message-
From: freetype-bounces+dbevan=emtex@nongnu.org
[mailto:freetype-bounces+dbevan=emtex@nongnu.org] On Behalf Of seayoung
Sent: 11 August 2011 03:55
To: Werner LEMBERG
Cc: freetype
Subject: Re: [ft] outline get cropped when render chinese simkai.ttf font
in freetype 2.4.6,I still use this demo with a font call STCaiyun(u can
download it from http://www.fontineed.com/font/STCaiyun ),while i render the
letter '@' with size 18,and then i meet a assert,in the file ftstroke.c,line
420。
this is what I call,
-华丽的分隔符-
WriteGlyphAsTGA(library,
argv[2],
L'@',
face,
18,
Pixel32(255, 90, 30),
Pixel32(255, 255, 255),
1.0f);
-华丽的分隔符-
and this is where the assert is:
-华丽的分隔符-
static FT_Error
ft_stroke_border_lineto( FT_StrokeBorder border,
FT_Vector* to,
FT_Bool movable )
{
FT_Error error = FT_Err_Ok;
FT_ASSERT( border-start = 0 );
-华丽的分隔符--
then I found if i comment the ftstroke.c from line 1265 to line 1372,I can
avoid the assert。
/* if all control points are coincident, this is a no-op; */
/* avoid creating a spurious corner */
if ( FT_IS_SMALL( stroker-center.x - control-x )
FT_IS_SMALL( stroker-center.y - control-y )
FT_IS_SMALL( control-x- to-x )
FT_IS_SMALL( control-y- to-y ) )
{
stroker-center = *to;
goto Exit;
}
-华丽的分隔符-
I think something should be added before statement goto Exit;,suck as set the
stroker's border-start。but my knowledge of the stroker is not enough to fix
this problem, so I send this mail for a resolvent.thank u.
seayoung
2011-08-11
发件人： Werner LEMBERG
发送时间： 2011-08-02 15:35:27
收件人： seayoung
抄送： freetype
主题： Re: [ft] outline get cropped when render chinese simkai.ttf font
In January, I wrote this:
Thanks. Using this font, I can repeat the problem. It's a bug in
the stroker.
Compile the attached program and feed it with
./example2-scaled kt.ttf example2-scaled.tga
It scales the image of `全' by 1000% after the border has been applied
(see attached image).
Unfortunately, I don't have time to fix that currently since my
knowledge of the stroker is not deep enough.
BTW, this is Savannah bug #27312. Any help in debugging this is
highly welcomed.
I've just checked: It's fixed now with version 2.4.6.
Werner
.
___
Freetype mailing list
freet...@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] stroker fixes - documentation
Werner, I think only the documentation for FT_Stroker_LineJoin will need updating to match the new ftstroker.h. Perhaps this happens automatically. David %^ -Original Message- From: David Bevan Sent: 01 July 2011 11:40 To: 'Werner LEMBERG'; graham.as...@cartotype.com; freetype-devel@nongnu.org Subject: stroker fixes Werner, Please find attached a major revision of ftstroke.c/h. The changes address the following issues: 1. If FT_STROKER_LINEJOIN_BEVEL was specified, unlimited miter joins (not bevel joins) were generated. Indeed, the meanings of miter and bevel were incorrectly reversed (consistently) in both the code and comments. 2. The way bevel joins were constructed (whether specified explicitly, or created as a result of exceeding the miter limit) did not match what is required for stroked text in PostScript or PDF. The behaviour of FT_STROKER_LINEJOIN_BEVEL has been corrected. * Used to render beveled line joins. The outer corner of * the joined lines is filled by enclosing the triangular * region of the corner with a straight line between the * outer corners of each stroke. A new line join style, FT_STROKER_LINEJOIN_MITER_FIXED, has been introduced to support PostScript / PDF miter joins. * Used to render mitered line joins, with fixed bevels if the * miter limit is exceeded. The outer edges of the strokes * for the two segments are extended until they meet at an * angle. If the segments meet at too sharp an angle (such * that the miter would extend from the intersection of the * segments a distance greater than the product of the miter * limit value and the border radius), then a bevel join (see * above) is used instead. This prevents long spikes being * created. FT_STROKER_LINEJOIN_MITER_FIXED generates a miter * line join as used in PostScript and PDF. FT_STROKER_LINEJOIN_MITER_VARIABLE has been introduced as an alias for FT_STROKER_LINEJOIN_MITER. * Used to render mitered line joins, with variable bevels if * the miter limit is exceeded. The intersection of the * strokes is clipped at a line perpendicular to the bisector * of the angle between the strokes, at the distance from the * intersection of the segments equal to the product of the * miter limit value and the border radius. This prevents * long spikes being created. * FT_STROKER_LINEJOIN_MITER_VARIABLE generates a mitered line * join as used in XPS. FT_STROKER_LINEJOIN_MITER is an alias * for FT_STROKER_LINEJOIN_MITER_VARIABLE, retained for * backwards compatibility. 3. A variety of stroking errors have been fixed. These would cause various artefacts (including points 'at infinity'), especially when stroking poor quality fonts. In remedying these, I have worked with the attached CFF font and the 16 fonts in the two downloads at http://code.google.com/p/libass/issues/detail?id=2 (which is linked to from http://lists.nongnu.org/archive/html/freetype-devel/2009-08/msg00022.html). The FT stroker now produces results very similar to that produced by GhostScript and Distiller for these fonts. The following problems have been resolved: 3a. Inside corners could be generated incorrectly. Intersecting the inside corner could cause a missing triangular area and other effects. See the attached insidecorner.pdf for an example. The intersection point can only be used if the join is between two lines and both lines are long enough. The optimisation condition in ft_stroker_inside() has been corrected; this requires the line length to be passed into various functions and stored in FT_StrokerRec. 3b. Incorrect cubic curves could be generated. The angle calculations in FT_Stroker_CubicTo() have been corrected to handle the case of the curve crossing the +/-PI direction. 3c. If the border radius was greater than the radius of curvature of a curve, then the negative sector would end up outside (not inside) the border. See the attached widestroke.pdf. This situation is now recognised and the negative sector is circumnavigated in the opposite direction. (If round line joins are being used, this code is disabled because the line join will always cover the negative sector.) 3d. When a curve is split, the arcs may not join smoothly (especially if the curve turns sharply back on itself). Changes in direction between adjacent arcs were not handled. A round corner is now added if the deviation from one arc to the next is greater than a suitable threshold. 3e. The current direction wasn't retained if a the outline contained a zero length lineto or a curve that was determined to be basically a point. This could cause a spurious join to be added. 3f. Cubics with close control points could be mishandled. All eight cases are now distinguished correctly. 4. Borders for cubic curves could be too 'flat
Re: [ft-devel] stroker - bevel joins
Swapping the directions of the outer and inner borders seems to make sense. I'll include that in my fixes. David %^ From: Graham Asher [mailto:graham.as...@cartotype.com] Sent: 27 June 2011 17:14 To: David Bevan Cc: Werner LEMBERG; freetype-devel@nongnu.org Subject: Re: [ft-devel] stroker - bevel joins I use the stroker - not in anger, but sometimes in sorrow ;-) Actually it seems quite good, but it could do with some speed optimisation, which I have discussed before with Werner; I made some concrete suggestions based on a comparison with CartoType's stroker, which is somewhat faster. I also discovered that - for my purposes, which may be different from other people's, but I think this is a general bug - the direction of the outer and inner borders is swapped for envelopes of closed strokes, thus: ft_stroke_border_close( stroker-borders + 0, TRUE ); ft_stroke_border_close( stroker-borders + 1, FALSE ); should be ft_stroke_border_close( stroker-borders + 0, FALSE ); ft_stroke_border_close( stroker-borders + 1, TRUE ); The effect of the bug is to produce voids when filling envelopes of closed strokes that overlap other closed paths, because the outer border is clockwise and the inner is anti-clockwise; for correct filling, the outer should be anti-clockwise and the inner clockwise. That's based on a slightly out-of-date version, so forgive me if it's been fixed. Graham Asher CartoType Ltd On 27/06/2011 16:05, David Bevan wrote: Hi! While developing code to support stroked text, we encountered a number of significant issues with the FT stroker. I will be submitting various fixes later in the week. However, one of the issues requires discussion (or at least agreement) beforehand. The PostScript/PDF References specify that the form of a bevel join (whether specified explicitly, or created as a result of exceeding the miter limit) is not dependent on the value of the miter limit. See the attached miter.pdf for an example. The current FreeType code generates the bevel join using a different algorithm that does depend on the miter limit. This actually accords with the way the miter limit is handled in XPS (see attached extract from the spec). NB: Be aware, if you look at the current code, that a miter join is called a bevel join and vice versa (and hence explicit bevel joins are implemented incorrectly). This will be fixed. What do we want to do? Change the implementation to match the PS/PDF References, discarding the XPS-style approach. Support both, with FT_STROKER_LINEJOIN_MITER matching the PS/PDF References, and a new FT_STROKER_LINEJOIN_VARIABLE_MITER for the XPS-style approach. Support both, with FT_STROKER_LINEJOIN_MITER unchanged, and a new FT_STROKER_LINEJOIN_FIXED_MITER for the PS/PDF approach. Support both, with FT_STROKER_LINEJOIN_FIXED_MITER and FT_STROKER_LINEJOIN_VARIABLE_MITER, and FT_STROKER_LINEJOIN_MITER an alias for FT_STROKER_LINEJOIN_VARIABLE_MITER (the existing behaviour). Something else. 1 2 introduce a backwards incompatibility, but is anyone actually using the stroker in anger? As long as FT supports the PS/PDF approach, any of these is acceptable for us. What do others think? Thanks. David %^ David Bevan Development Manager Pitney Bowes Emtex Software Tel: +44 (0)1923 279300 david.be...@pb.commailto:david.be...@pb.com ___ Freetype-devel mailing list Freetype-devel@nongnu.orgmailto:Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] stroker - bevel joins
Graham, Certainly the FT stroker could be speeded up by limiting the use of trigonometric functions as far as possible. However, that would be quite a lot of extra work, so I won't be making any changes in that direction at this time. Thanks. David %^ From: Graham Asher [mailto:graham.as...@cartotype.com] Sent: 28 June 2011 15:43 To: David Bevan Cc: freetype-devel@nongnu.org Subject: Re: [ft-devel] stroker - bevel joins David, here's a quote concerning optimisation from an e-mail of mine to Werner back in March when I was looking into this - key quote in bold below: I have also discovered that CartoType's method of stroking paths is much faster than FreeType's (more than twice as fast, I think - at any rate, it makes CartoType benchmark at about 10 seconds as opposed to 15 seconds, and CartoType does a lot of other things; this was disappointing to me because I had hoped to speed up CartoType by using the FreeType method). I don't have time to create a FreeType version of the CartoType system right now, but I think it's because CartoType uses the intersections of parallels to get inner join positions, while FreeType calculates them using trigonometry. I'm happy to share CartoType's system with the world if it's of interest - but again, it's a matter of time, because I am very busy and CartoType's C++ coding style is very different from FreeType's C, so I'd have to do a lot of conversion. Credit for CartoType's system is due to my colleague Lex Warners (now inactive, alas), who also implemented the fixed-point trigonometric routines. I haven't had time to think about the mitre limit yet. Best regards, Graham On 28/06/2011 09:01, David Bevan wrote: Graham, Thanks for the feedback. I'm glad you're using it. At least there's someone who will be able to review / test my changes. I'll look into the issue you mention. Perhaps you could forward me your ideas for increasing performance, since I'm working on the code at the moment. Do you have any view on handling the miter limit? I will implement option 4 below unless I receive feedback in favour of a different approach. Thanks. David %^ From: Graham Asher [mailto:graham.as...@cartotype.com] Sent: 27 June 2011 17:14 To: David Bevan Cc: Werner LEMBERG; freetype-devel@nongnu.orgmailto:freetype-devel@nongnu.org Subject: Re: [ft-devel] stroker - bevel joins I use the stroker - not in anger, but sometimes in sorrow ;-) Actually it seems quite good, but it could do with some speed optimisation, which I have discussed before with Werner; I made some concrete suggestions based on a comparison with CartoType's stroker, which is somewhat faster. I also discovered that - for my purposes, which may be different from other people's, but I think this is a general bug - the direction of the outer and inner borders is swapped for envelopes of closed strokes, thus: ft_stroke_border_close( stroker-borders + 0, TRUE ); ft_stroke_border_close( stroker-borders + 1, FALSE ); should be ft_stroke_border_close( stroker-borders + 0, FALSE ); ft_stroke_border_close( stroker-borders + 1, TRUE ); The effect of the bug is to produce voids when filling envelopes of closed strokes that overlap other closed paths, because the outer border is clockwise and the inner is anti-clockwise; for correct filling, the outer should be anti-clockwise and the inner clockwise. That's based on a slightly out-of-date version, so forgive me if it's been fixed. Graham Asher CartoType Ltd On 27/06/2011 16:05, David Bevan wrote: Hi! While developing code to support stroked text, we encountered a number of significant issues with the FT stroker. I will be submitting various fixes later in the week. However, one of the issues requires discussion (or at least agreement) beforehand. The PostScript/PDF References specify that the form of a bevel join (whether specified explicitly, or created as a result of exceeding the miter limit) is not dependent on the value of the miter limit. See the attached miter.pdf for an example. The current FreeType code generates the bevel join using a different algorithm that does depend on the miter limit. This actually accords with the way the miter limit is handled in XPS (see attached extract from the spec). NB: Be aware, if you look at the current code, that a miter join is called a bevel join and vice versa (and hence explicit bevel joins are implemented incorrectly). This will be fixed. What do we want to do? 1. Change the implementation to match the PS/PDF References, discarding the XPS-style approach. 2. Support both, with FT_STROKER_LINEJOIN_MITER matching the PS/PDF References, and a new FT_STROKER_LINEJOIN_VARIABLE_MITER for the XPS-style approach. 3. Support both, with FT_STROKER_LINEJOIN_MITER unchanged, and a new
Re: [ft-devel] stroker - bevel joins
Graham, Thanks for the feedback. I'm glad you're using it. At least there's someone who will be able to review / test my changes. I'll look into the issue you mention. Perhaps you could forward me your ideas for increasing performance, since I'm working on the code at the moment. Do you have any view on handling the miter limit? I will implement option 4 below unless I receive feedback in favour of a different approach. Thanks. David %^ From: Graham Asher [mailto:graham.as...@cartotype.com] Sent: 27 June 2011 17:14 To: David Bevan Cc: Werner LEMBERG; freetype-devel@nongnu.org Subject: Re: [ft-devel] stroker - bevel joins I use the stroker - not in anger, but sometimes in sorrow ;-) Actually it seems quite good, but it could do with some speed optimisation, which I have discussed before with Werner; I made some concrete suggestions based on a comparison with CartoType's stroker, which is somewhat faster. I also discovered that - for my purposes, which may be different from other people's, but I think this is a general bug - the direction of the outer and inner borders is swapped for envelopes of closed strokes, thus: ft_stroke_border_close( stroker-borders + 0, TRUE ); ft_stroke_border_close( stroker-borders + 1, FALSE ); should be ft_stroke_border_close( stroker-borders + 0, FALSE ); ft_stroke_border_close( stroker-borders + 1, TRUE ); The effect of the bug is to produce voids when filling envelopes of closed strokes that overlap other closed paths, because the outer border is clockwise and the inner is anti-clockwise; for correct filling, the outer should be anti-clockwise and the inner clockwise. That's based on a slightly out-of-date version, so forgive me if it's been fixed. Graham Asher CartoType Ltd On 27/06/2011 16:05, David Bevan wrote: Hi! While developing code to support stroked text, we encountered a number of significant issues with the FT stroker. I will be submitting various fixes later in the week. However, one of the issues requires discussion (or at least agreement) beforehand. The PostScript/PDF References specify that the form of a bevel join (whether specified explicitly, or created as a result of exceeding the miter limit) is not dependent on the value of the miter limit. See the attached miter.pdf for an example. The current FreeType code generates the bevel join using a different algorithm that does depend on the miter limit. This actually accords with the way the miter limit is handled in XPS (see attached extract from the spec). NB: Be aware, if you look at the current code, that a miter join is called a bevel join and vice versa (and hence explicit bevel joins are implemented incorrectly). This will be fixed. What do we want to do? 1. Change the implementation to match the PS/PDF References, discarding the XPS-style approach. 2. Support both, with FT_STROKER_LINEJOIN_MITER matching the PS/PDF References, and a new FT_STROKER_LINEJOIN_VARIABLE_MITER for the XPS-style approach. 3. Support both, with FT_STROKER_LINEJOIN_MITER unchanged, and a new FT_STROKER_LINEJOIN_FIXED_MITER for the PS/PDF approach. 4. Support both, with FT_STROKER_LINEJOIN_FIXED_MITER and FT_STROKER_LINEJOIN_VARIABLE_MITER, and FT_STROKER_LINEJOIN_MITER an alias for FT_STROKER_LINEJOIN_VARIABLE_MITER (the existing behaviour). Something else. 1 2 introduce a backwards incompatibility, but is anyone actually using the stroker in anger? As long as FT supports the PS/PDF approach, any of these is acceptable for us. What do others think? Thanks. David %^ David Bevan Development Manager Pitney Bowes Emtex Software Tel: +44 (0)1923 279300 david.be...@pb.com ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] [FYI] MingLiU identifier
Some of these tables are very short (a total of only 44 bytes on the Mac), so what is the likelihood that they match tables in other fonts that don't require TT hinting? We need some guarantee that comparing these values will uniquely identify the relevant fonts. David %^ -Original Message- From: freetype-devel-bounces+david.bevan=pb@nongnu.org [mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of mpsuz...@hiroshima-u.ac.jp Sent: 17 November 2010 02:29 To: freetype-devel Subject: [ft-devel] [FYI] MingLiU identifier Hi all, Since freetype-2.4.3, TrueType hinter is enabled for the fonts without family name. It was a fallbacking solution of MingLiU embedded in PDF, without family name (according to Type42 spec, name table is optional, so embedded TrueType in PDF may lack family name). Recently, Gentoo people request to revert it to disable the hinter by default, because it makes TimesNewRoman embedded by Mac OS X Quartz ContextPDF (a generic framework in Mac OS X to generate PDF document) ugly. Thus, now I'm trying to identify problematic fonts which cannot be readable if rendered without hinter, by the checksum (or the pair of checksum length?) of required table for Type42. cvt, fpgm and prep are the candidates because their content is tightly bound to glyf programs, so they are usually preserved in the TrueType subsetting process. # the proof of idea was posted at: # http://lists.nongnu.org/archive/html/freetype-devel/2010-08/msg00019.html Here I collected the checksums of various versions of MingLiU. During the check, I found that recent MingLiU (post-Vista, and Microsoft Office for Mac) don't cause broken shape issue anymore. I checked various versions mentioned at: http://zh.wikipedia.org/zh/%E6%96%B0%E7%B4%B0%E6%98%8E%E9%AB%94 From the result, I think, the checksum of cvt/fpgm/prep can be classified into 2 groups, older newer, I'm happy to see that we (may) don't have to maintain long list of the checksum for all versions of MingLiU. Regards, mpsuzuki Microsoft Windows NT 4.0: ver 2.00 (1996-May-15, second release) tag cvt offset 0x0023dc7c length 0x02e4 checkSum 0x05bcf058 tag fpgm offset 0x0023df60 length 0x87c4 checkSum 0x28233bf1 tag prep offset 0x005fb248 length 0x01e1 checkSum 0xa344a1eb Microsoft OfficeXP Proof Kit: ver 3.00 tag cvt offset 0x0038bb94 length 0x02e4 checkSum 0x05bcf058 tag fpgm offset 0x0038be78 length 0x87c4 checkSum 0x28233bf1 tag prep offset 0x0082fe78 length 0x01e1 checkSum 0xa344a1eb Microsoft Windows XP: ver 3.21 tag cvt offset 0x003a101c length 0x02e4 checkSum 0x05bcf058 tag fpgm offset 0x003a1300 length 0x87c4 checkSum 0x28233bf1 tag prep offset 0x0086a004 length 0x01e1 checkSum 0xa344a1eb (Microsoft Office for Mac v.X: MingLiU is not bundled) Microsoft Office for Mac 2004: ver 4.55 Microsoft Office for Mac 2008: ver 4.55 Microsoft Office for Mac 2011: ver 4.55 tag cvt offset 0x0001cdf8 length 0x0008 checkSum 0x tag fpgm offset 0x0001cdd0 length 0x0011 checkSum 0xf40ddf13 tag prep offset 0x0001cde4 length 0x0013 checkSum 0x6286ee0a Microsoft Windows Vista: ver 6.02 tag cvt offset 0x004a437c length 0x0008 checkSum 0x tag fpgm offset 0x004a4384 length 0x0011 checkSum 0xf40ddf13 tag prep offset 0x019fc218 length 0x0013 checkSum 0x6286ee0a Microsoft Windows 7: ver 7.00 tag cvt offset 0x00499f78 length 0x0008 checkSum 0x tag fpgm offset 0x00499f80 length 0x0011 checkSum 0xf40ddf13 tag prep offset 0x019f4064 length 0x0013 checkSum 0x6286ee0a ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] [FYI] MingLiU identifier
In general scope, I think, you raised a concern that the checksum in TTF header is too simple (it's a sum of 32-bit values of the table) to guarantee the identity. It's reasonable. My concern is that the (small) tables may actually be the same in a variety of fonts. If I check the fonts bundled to Microsoft Windows, Mac OS (Classic OS X), and distributed in GNU/Linux distribution and I find no conflict, is it sufficient guarantee? That seems reasonable. If not, I cannot access wider coverage of the fonts, so, the possible solution would be... 1) identify by family name comparison is used too, and add a fallback by sfnt table checksum. 2) in addition to the tag-name of the table and the checksum, the length should be checked. 3) if it's still insufficient... should we use our own hash value instead of the checksum in sfnt header. Only 1) would address my concern. David %^ ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] cubic clean up
Aleksei, If you relax the condition, you increase the number of splits. Normally, making such a change is a mistake because the benefit of simplifying the condition is easily outweighed by the greater cost of increasing the recursive depth. This is the very reason why we ended up with a much more complex set of conditions than in earlier version of FT: it reduces the number of splits very significantly. I've just had a brief chance to look at your proposal, and I now understand why it makes no difference to the output. The chances of your relaxed condition causing a split when the current (theoretically correct) condition doesn't is very small: a control point would have to be in the small white areas in the bottom corners of the rectangle in your diagram. Note that this check is only made after subdivisions for the distance from the chord. Since this is the most expensive test, it is done last, and normally only once. Since there is no performance improvement, I don't believe that your proposal should be included in the code. It would make the code more opaque: It is obvious why the current code [if P1 or P2 is outside P0-P3, split the curve] does what it does (especially if reference is made to Hain's paper); it would not be at all clear why your condition for splitting [if P1 or P2 is far from the center of P0-P3, split the curve] was there. If you do come up with an improvement to the algorithm that is significantly faster (and still provably correct), then by all means submit it for review (but don't expect a quick or uncritical response). Thanks. David %^ -Original Message- From: freetype-devel-bounces+david.bevan=pb@nongnu.org [mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of ??? ? Sent: 11 November 2010 20:23 To: GRAHAM ASHER Cc: freetype-devel Subject: Re: [ft-devel] cubic clean up Shaded areas Before and After in the attached figures show where control points have should be to permit flattening. Is this a risky change? If anything, it is slightly more conservative, yet the conditional is quite a bit simpler. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
Alexei,
Since there are two changes, (the value of FT_MAX_CURVE_DEVIATION and the
algorithm), each must be tested independently.
Which has broken the rendering?
We need trace info: Does the new algorithm actually do what it claims. I.e. is
the actual deviation really limited to the FT_MAX_CURVE_DEVIATION value, or has
the code change broken this?
I've attached a(n old) version of the trace code I used. It'll probably need
some modifying, but it includes what is required to calculate the *actual*
maximum deviation.
David %^
-Original Message-
From: freetype-devel-bounces+david.bevan=pb@nongnu.org
[mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of
??? ?
Sent: 14 October 2010 02:03
To: Werner LEMBERG
Cc: freetype-devel@nongnu.org
Subject: Re: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
Hi all,
On Wed, Oct 13, 2010 at 9:41 AM, Werner LEMBERG w...@gnu.org wrote:
I guess my version has PIXEL_BITS = 6. Sorry, didn't notice the
discrepancy. Yes, FT_MAX_CURVE_DEVIATIO ought to be defined so that
it's always 1/4 of a pixel.
Alexej, can you provide a patch to fix that?
The patch is below. As was intended in the original code, it aims at the
max
deviation of ONE_PIXEL / 4. Remember that the original code actually used
ONE_PIXEL / 16. The speed-up is nice:
ftbench -b c -s 36 /usr/share/fonts/default/Type1/p052003l.pfb
Render: 29.216 us/op (before, see 243.png)
Render: 25.480 us/op (after, see 244.png)
Frankly, I think I am starting to notice the quality down a bit.
Please judge for yourself.
One quater is probably too close to the size of subpixels, so I
would consider
ONE_PIXEL / 8 instead. Would I make it tunable? No way, I don't want
people
to ever curse at freetype because someone misjudged his eyesight. It's too
subjective for one person to decide.
diff --git a/src/smooth/ftgrays.c b/src/smooth/ftgrays.c
index 17d172f..4828013 100644
--- a/src/smooth/ftgrays.c
+++ b/src/smooth/ftgrays.c
@@ -91,11 +91,6 @@
#define FT_COMPONENT trace_smooth
- /* The maximum distance of a curve from the chord, in 64ths of a pixel;
*/
- /* used when flattening curves.
*/
-#define FT_MAX_CURVE_DEVIATION 16
-
-
#ifdef _STANDALONE_
@@ -891,14 +886,14 @@ typedef ptrdiff_t FT_PtrDist;
if ( dx dy )
dx = dy;
-if ( dx = FT_MAX_CURVE_DEVIATION )
+if ( dx = ONE_PIXEL / 4 )
{
gray_render_line( RAS_VAR_ UPSCALE( to-x ), UPSCALE( to-y ) );
return;
}
level = 1;
-dx /= FT_MAX_CURVE_DEVIATION;
+dx /= ONE_PIXEL / 4;
while ( dx 1 )
{
dx = 2;
@@ -1074,7 +1069,7 @@ typedef ptrdiff_t FT_PtrDist;
goto Split;
/* Max deviation may be as much as (s/L) * 3/4 (if Hain's v = 1).
*/
-s_limit = L * (TPos)( FT_MAX_CURVE_DEVIATION / 0.75 );
+s_limit = L * (TPos)( ONE_PIXEL / 3 );
/* s is L * the perpendicular distance from P1 to the line P0-P3.
*/
dx1 = arc[1].x - arc[0].x;
#define TRACE_CUBIC
#ifdef TRACE_CUBIC
#include math.h
#endif
#ifdef TRACE_CUBIC
/*/
/* */
/* Returns the one-dimensional position of the Bezier point with */
/* parametric value t and control point values s0 .. s3. */
/* */
static double bez_param(double s0, double s1, double s2, double s3, double t)
{
double u = 1 - t;
return u * u * u * s0
+ 3 * t * u * (u * s1 + t * s2)
+ t * t * t * s3;
}
/*/
/* */
/* Returns the unnormalised s-coordinate of the point p in the r-s */
/* coordinate system for the Bezier curve defined by the points */
/* arc[0..3].*/
/* */
static FT_Pos s_dist(FT_Vector* arc, FT_Vector* p)
{
return (arc[0].y - p-y) * (arc[3].x - arc[0].x)
- (arc[0].x - p-x) * (arc[3].y - arc[0].y);
}
/*/
/* */
/* Returns the distance between points p and q. */
/* */
static double dist(FT_Vector* p, FT_Vector* q)
{
FT_Pos dx = q-x - p-x;
FT_Pos dy = q-y - p-y;
return sqrt(dx * dx + dy * dy);
}
/*/
/*
RE: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
Alexei, Similarly, I don't have the time necessary to validate and performance-test your new algorithm. Perhaps a good start would be for you to produce trace and performance results comparing your algorithm against what Graham checked in (as I did, for example, in my message of Tue, 7 Sep 2010 12:39:12 -0400). I don't think that s and s_limit should be considered as areas. They are (strangely scaled) linear measurements. The only reason for the strange scaling is to improve speed. Btw, your earlier comment about the overflow protection is correct. Removing it isn't acceptable though (since you're still squaring dx, etc.) Regards, David %^ -Original Message- From: freetype-devel-bounces+david.bevan=pb@nongnu.org [mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of GRAHAM ASHER Sent: 13 October 2010 09:45 To: Алексей Подтележников; freetype-devel Subject: Re: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL Alexei, I don't have much time or energy for this at the moment - sorry. Of course I will be looking at it again, but I believe that the solution hammered out by David Bevan and myself is a good one - it solves the bug I introduced while retaining the speed increases I first made the changes for. Please note that the definition of FT_MAX_CURVE_DEVIATION as 16 gives a value of 1/4, not 1/16 as you suggest. This code works in units of 1/64 of a pixel. Best regards, Graham - Original Message From: Алексей Подтележников apodt...@gmail.com To: freetype-devel freetype-devel@nongnu.org Sent: Wednesday, 13 October, 2010 2:25:40 Subject: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL Guys, Currently smooth/ftgrays.c contains this: /* The maximum distance of a curve from the chord, in 64ths of a pixel; */ /* used when flattening curves. */ #define FT_MAX_CURVE_DEVIATION 16 and this: /* must be at least 6 bits! */ #define PIXEL_BITS 8 #define ONE_PIXEL ( 1L PIXEL_BITS ) Wouldn't that make sense to reconcile the two and possibly just use an explicit fraction of ONE_PIXEL instead? If I am not confused FT_MAX_CURVE_DEVIATION could be replaced with a larger value. 16 / 256th is really very conservative and you still make too many splits. Also, s and s_limit actually mean some sort of an area measure. It would make perfect sense to use TArea as type of these variables. Finally, I have more geometrical suggestions, but I'll wait with the patch, until I hear back Re this and my previous message. Best, Alexei ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] latest patch file for spline flattening
Graham, Here are the results of my performance testing. I was a bit surprised by the results. In gray_convert_glyph, the time is distributed as follows: OLDNEW render_line 20%15% render_cubic 15%33% render_scanline 14%10% split_cubic6% 9% OLD is the pre-2.4.0 code; NEW is the latest patch from you. These percentages are the fraction of time spent in the specific function (excluding children). Including children, we have the following actual times per call for handling cubic curves: OLDNEW render_cubic 142us 220us I wasn't expecting your new code to be slower. So I ran my trace code on it with the following results: OLD NEW average line segs per arc13.5 11.3 min line segs per arc 21 max line segs per arc32 133 average deviation per line seg0.29 0.44 min deviation per line seg00 max deviation per line seg 22.2 15.8 Some arcs are creating a very large number of line segments. I expect (though I haven't verified) that it is this that is causing the slow-down. Below is the data for one curve that gets broken down into many tiny line segments. David %^ 4604,0 2080,0 40,2020 40,4496 40,4496 - 40,4436 40,4436 - 40,4379 40,4379 - 41,4321 41,4321 - 44,4264 44,4264 - 47,4206 47,4206 - 51,4149 51,4149 - 56,4092 56,4092 - 62,4036 62,4036 - 68,3979 68,3979 - 74,3922 74,3922 - 81,3865 81,3865 - 90,3811 90,3811 - 99,3754 99,3754 - 109,3700 109,3700 - 119,3645 119,3645 - 131,3591 131,3591 - 142,3535 142,3535 - 154,3481 154,3481 - 166,3427 166,3427 - 181,3373 181,3373 - 195,3319 195,3319 - 210,3265 210,3265 - 225,3211 225,3211 - 243,3160 243,3160 - 259,3106 259,3106 - 277,3055 277,3055 - 295,3002 295,3002 - 314,2951 314,2951 - 333,2900 333,2900 - 354,2849 354,2849 - 375,2798 375,2798 - 397,2748 397,2748 - 418,2697 418,2697 - 440,2646 440,2646 - 463,2595 463,2595 - 487,2547 487,2547 - 536,2450 536,2450 - 588,2354 588,2354 - 641,2258 641,2258 - 697,2165 697,2165 - 756,2073 756,2073 - 817,1984 817,1984 - 879,1894 879,1894 - 943,1807 943,1807 - 1009,1720 1009,1720 - 1079,1637 1079,1637 - 1149,1554 1149,1554 - 1222,1474 1222,1474 - 1297,1395 1297,1395 - 1375,1319 1375,1319 - 1452,1243 1452,1243 - 1533,1169 1533,1169 - 1614,1097 1614,1097 - 1698,1028 1698,1028 - 1782,959 1782,959 - 1869,894 1869,894 - 1958,830 1958,830 - 2049,769 2049,769 - 2140,708 2140,708 - 2233,651 2233,651 - 2328,595 2328,595 - 2425,543 2425,543 - 2522,491 2522,491 - 2570,467 2570,467 - 2621,443 2621,443 - 2671,419 2671,419 - 2722,397 2722,397 - 2773,375 2773,375 - 2825,354 2825,354 - 2876,332 2876,332 - 2927,311 2927,311 - 2978,290 2978,290 - 3031,272 3031,272 - 3082,253 3082,253 - 3136,235 3136,235 - 3190,217 3190,217 - 3244,202 3244,202 - 3297,184 3297,184 - 3351,169 3351,169 - 3405,154 3405,154 - 3460,140 3460,140 - 3514,126 3514,126 - 3570,114 3570,114 - 3625,102 3625,102 - 3682,91 3682,91 - 3736,79 3736,79 - 3793,69 3793,69 - 3849,59 3849,59 - 3906,50 3906,50 - 3963,41 3963,41 - 4020,34 4020,34 - 4077,28 4077,28 - 4136,22 4136,22 - 4193,16 4193,16 - 4251,11 4251,11 - 4308,7 4308,7 - 4368,4 4368,4 - 4425,1 4425,1 - 4485,0 4485,0 - 4544,0 4544,0 - 4604,0 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] latest patch file for spline flattening
After trying various other fonts, I settled on using a single large (14,000 glyphs; 800,000 Bezier curves) CID-keyed Type 1 font, which seemed to show pretty average behaviour. I'm working on an implementation of something like Hain's algorithm now. It'll be interesting to see how it compares. David %^ -Original Message- From: GRAHAM ASHER [mailto:graham.as...@btinternet.com] Sent: 07 September 2010 13:46 To: David Bevan Cc: freetype-devel Subject: Re: [ft-devel] latest patch file for spline flattening That is very interesting and very useful - in fact I think the more surprising a test is, the more useful it is. I'll have to look into your test case carefully as well. I might not be able to do it for a day or to, though. Where does your test data come from? Actual fonts, cooked up data, or a mixture of both? Best regards, Graham - Original Message From: David Bevan david.be...@pb.com To: Graham Asher graham.as...@btinternet.com Cc: freetype-devel freetype-devel@nongnu.org Sent: Tuesday, 7 September, 2010 12:40:21 Subject: RE: [ft-devel] latest patch file for spline flattening Graham, Here are the results of my performance testing. I was a bit surprised by the results. In gray_convert_glyph, the time is distributed as follows: OLDNEW render_line 20%15% render_cubic 15%33% render_scanline 14%10% split_cubic6% 9% OLD is the pre-2.4.0 code; NEW is the latest patch from you. These percentages are the fraction of time spent in the specific function (excluding children). Including children, we have the following actual times per call for handling cubic curves: OLDNEW render_cubic 142us 220us I wasn't expecting your new code to be slower. So I ran my trace code on it with the following results: OLD NEW average line segs per arc13.5 11.3 min line segs per arc 21 max line segs per arc32 133 average deviation per line seg0.29 0.44 min deviation per line seg00 max deviation per line seg 22.2 15.8 Some arcs are creating a very large number of line segments. I expect (though I haven't verified) that it is this that is causing the slow-down. Below is the data for one curve that gets broken down into many tiny line segments. David %^ 4604,0 2080,0 40,2020 40,4496 40,4496 - 40,4436 40,4436 - 40,4379 40,4379 - 41,4321 41,4321 - 44,4264 44,4264 - 47,4206 47,4206 - 51,4149 51,4149 - 56,4092 56,4092 - 62,4036 62,4036 - 68,3979 68,3979 - 74,3922 74,3922 - 81,3865 81,3865 - 90,3811 90,3811 - 99,3754 99,3754 - 109,3700 109,3700 - 119,3645 119,3645 - 131,3591 131,3591 - 142,3535 142,3535 - 154,3481 154,3481 - 166,3427 166,3427 - 181,3373 181,3373 - 195,3319 195,3319 - 210,3265 210,3265 - 225,3211 225,3211 - 243,3160 243,3160 - 259,3106 259,3106 - 277,3055 277,3055 - 295,3002 295,3002 - 314,2951 314,2951 - 333,2900 333,2900 - 354,2849 354,2849 - 375,2798 375,2798 - 397,2748 397,2748 - 418,2697 418,2697 - 440,2646 440,2646 - 463,2595 463,2595 - 487,2547 487,2547 - 536,2450 536,2450 - 588,2354 588,2354 - 641,2258 641,2258 - 697,2165 697,2165 - 756,2073 756,2073 - 817,1984 817,1984 - 879,1894 879,1894 - 943,1807 943,1807 - 1009,1720 1009,1720 - 1079,1637 1079,1637 - 1149,1554 1149,1554 - 1222,1474 1222,1474 - 1297,1395 1297,1395 - 1375,1319 1375,1319 - 1452,1243 1452,1243 - 1533,1169 1533,1169 - 1614,1097 1614,1097 - 1698,1028 1698,1028 - 1782,959 1782,959 - 1869,894 1869,894 - 1958,830 1958,830 - 2049,769 2049,769 - 2140,708 2140,708 - 2233,651 2233,651 - 2328,595 2328,595 - 2425,543 2425,543 - 2522,491 2522,491 - 2570,467 2570,467 - 2621,443 2621,443 - 2671,419 2671,419 - 2722,397 2722,397 - 2773,375 2773,375 - 2825,354 2825,354 - 2876,332 2876,332 - 2927,311 2927,311 - 2978,290 2978,290 - 3031,272 3031,272 - 3082,253 3082,253 - 3136,235 3136,235 - 3190,217 3190,217 - 3244,202 3244,202 - 3297,184 3297,184 - 3351,169 3351,169 - 3405,154 3405,154 - 3460,140 3460,140 - 3514,126 3514,126 - 3570,114 3570,114 - 3625,102 3625,102 - 3682,91 3682,91 - 3736,79 3736,79 - 3793,69 3793,69 - 3849,59 3849,59 - 3906,50 3906,50 - 3963,41 3963,41 - 4020,34 4020,34 - 4077,28 4077,28 - 4136,22 4136,22 - 4193,16 4193,16 - 4251,11 4251,11 - 4308,7 4308,7 - 4368,4 4368,4 - 4425,1 4425,1 - 4485,0 4485,0 - 4544,0 4544,0 - 4604,0 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] latest patch file for spline flattening
I've now implemented something based on Hain's research and it seems to be
measurably faster than previous FT approaches. I have used Hain's paper (now
available from http://tinyurl.com/HainBez) to provide some sensible heuristics
rather than implement all his stuff in detail, and done so without using square
roots or even any divisions.
First, here are the trace results:
OLD NEW HAIN
average line segs per arc13.5 11.32.1
min line segs per arc 21 1
max line segs per arc32 133 16
average deviation per line seg0.29 0.44 6.5
min deviation per line seg00 0
max deviation per line seg 22.2 15.8 15.7
By using reasonably accurate heuristics when deciding whether to split the
curve, we create 5.5 x fewer line segments. This cuts down the number of calls
to split_cubic and the number of iterations within render_cubic.
And now the performance results:
In gray_convert_glyph, the time is distributed as follows:
OLDNEWHAIN
render_line 20%15% 12%
render_cubic 15%33% 9%
render_scanline 14%10% 10%
split_cubic6% 9% 2%
The time spent in these functions has been significantly reduced as a fraction
of processing time.
Including children, we have the following actual times per call for handling
cubic curves:
OLDNEWHAIN
render_cubic 142us 220us 61us
render_cubic is now more than twice as fast as it ever has been.
The effect of the speed-up is even measurable as a 5-10% speed-up of my font
rasterisation program (which is reading and writing data on top of using FT to
do the actual rendering).
These tests are with the same Unicode font as before. I'll run some more test
with Latin-only fonts, though previous testing didn't show any significant
performance differences between Latin and CJK. CJK glyphs just have more cubic
Bezier curves on average, but a Bezier curve is a Bezier curve wherever it
comes from.
The code is below. I hope I've tried to follow Werner's coding standards as far
as I know what they are.
Thanks.
David %^
static void
gray_render_cubic( RAS_ARG_ const FT_Vector* control1,
const FT_Vector* control2,
const FT_Vector* to )
{
FT_Vector* arc;
arc = ras.bez_stack;
arc[0].x = UPSCALE( to-x );
arc[0].y = UPSCALE( to-y );
arc[1].x = UPSCALE( control2-x );
arc[1].y = UPSCALE( control2-y );
arc[2].x = UPSCALE( control1-x );
arc[2].y = UPSCALE( control1-y );
arc[3].x = ras.x;
arc[3].y = ras.y;
for (;;)
{
/* Check that the arc crosses the current band. */
TPos min, max, y;
min = max = arc[0].y;
y = arc[1].y;
if ( y min ) min = y;
if ( y max ) max = y;
y = arc[2].y;
if ( y min ) min = y;
if ( y max ) max = y;
y = arc[3].y;
if ( y min ) min = y;
if ( y max ) max = y;
if ( TRUNC( min ) = ras.max_ey || TRUNC( max ) 0 )
goto Draw;
/* Decide whether to split or draw */
/* See Hain's paper at http://tinyurl.com/HainBez for more info */
{
TPos dx, dy, L, dx1, dy1, dx2, dy2, s1, s2;
/* dx and dy are x- and y- components of the P0-P3 chord vector */
dx = arc[3].x - arc[0].x;
dy = arc[3].y - arc[0].y;
/* L is an (under)estimate of the Euclidean distance P0-P3 */
L = ( 236 * FT_MAX(labs(dx), labs(dy))
+ 97 * FT_MIN(labs(dx), labs(dy))) 8;
/* avoid possible arithmetic overflow below by splitting */
if (L 32767)
goto Split;
/* s1 is L * the perpendicular distance from P1 to the line P0-P3 */
s1 = labs( dy * (dx1 = arc[1].x - arc[0].x)
- dx * (dy1 = arc[1].y - arc[0].y));
/* max deviation is at least (s1 / L) * sqrt(3)/6 (if v = -1) */
if (s1 L * (TPos)(FT_MAX_CURVE_DEVIATION / 0.288675))
goto Split;
/* s2 is L * the perpendicular distance from P2 to the line P0-P3 */
s2 = labs( dy * (dx2 = arc[2].x - arc[0].x)
- dx * (dy2 = arc[2].y - arc[0].y));
/* max deviation may be as much as (max(s1,s2)/L) * 3/4 (if v = 1) */
if (FT_MAX(s1, s2) L * (TPos)(FT_MAX_CURVE_DEVIATION / 0.75))
goto Split;
/* if P1 or P2 is outside P0-P3, split */
if ( dy * dy1 + dx * dx1 0
|| dy * dy2 + dx * dx2 0
|| dy * (arc[3].y - arc[1].y) + dx * (arc[3].x - arc[1].x) 0
|| dy * (arc[3].y - arc[2].y) + dx * (arc[3].x - arc[2].x) 0
)
goto Split;
/* no reason to split */
goto Draw;
}
Split:
gray_split_cubic( arc );
arc += 3;
continue;
Draw:
gray_render_line( RAS_VAR_ arc[0].x, arc[0].y );
if (arc == ras.bez_stack)
return;
arc -=
RE: [ft-devel] latest patch file for spline flattening
Here are some test results with Latin fonts (40 thousand curves from fonts at various point sizes). Trace results: CJK CJK CJK LATIN LATIN OLD NEW HAINNEW HAIN average line segs per arc13.5 11.32.1 30.96.1 max line segs per arc32 133 16 163 18 average deviation per line seg0.29 0.44 6.5 0.37 7.4 max deviation per line seg 22.2 15.8 15.7 7.9 15.7 Performance results: In gray_convert_glyph, the time is distributed as follows: CJKCJKCJK LATIN LATIN OLDNEWHAINNEWHAIN render_line 20%15% 12%14%11% render_cubic 15%33% 9%34%11% render_scanline 14%10% 10%10%11% split_cubic6% 9% 2%10% 3% Including children, we have the following actual times per call for handling cubic curves: CJKCJKCJK LATIN LATIN OLDNEWHAINNEW HAIN render_cubic 142us 220us 61us546us 176us Conclusions: The performance improvement is as evident with Latin fonts as with CJK ones. However, on average Bezier curves from Latin fonts require more flattening (6 segments versus 2 with the Hain implementation), so processing them takes longer. As Graham pointed out to me: The curves used in Latin and other Latin-like alphabets are very often used to navigate 90-degree corners; P0 and P1 lie on a grid line, and so do P2 and P3. This is very rarely true in Han characters. On the other hand, Latin glyphs contain fewer Bezier curves than CJK (6 versus 57 on average with my data). The upshot of both of these together is that the performance change is very similar (the CJK and Latin time distribution figures are so similar they could be from the same test). David %^ ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] latest patch file for spline flattening
Graham, That's looking much closer to what I would have thought we needed; only splitting the curve when required. However, your fast heuristic can be very inaccurate. Consider P0: 0,0 P1: 5,5 P2: 95,5 P3: 100,0 The max deviation is 3.75 (0.75 * 5 since Hain's v == 1), but your heuristic gives a value of 45 - twelve times too great. Btw, I think that dx1, dy1, ... need to be of type TPos, not int. On the issue of avoiding square roots, a little bit of algebra shows that it is possible to estimate r = sqrt(dx^2 + dy^2) with a simple linear combination of dx and dy. For example, if an overestimate is required, and dx = dy, you can use r_upperbound = dx + (sqrt(2) - 1) * dy which overestimates by no more than 8.5%. For integer arithmetic, sqrt(2) - 1 can be (over)estimated by 107/256. For example, you could use this approximation to do something like this: dx1 = abs(control1-x - midx); dy1 = abs(control1-y - midy); if (dx1 = dy1) dr1 = dx1 + (107 * dy1 + 255) 8; else dr1 = dy1 + (107 * dx1 + 255) 8; dx2 = abs(control2-x - midx); dy2 = abs(control2-y - midy); if (dx2 = dy2) dr2 = dx2 + (107 * dy2 + 255) 8; else dr2 = dy2 + (107 * dx2 + 255) 8; /* deviation never exceeds 75% of control point dist */ if (dr1 = dr2) dev_max = (3 * dr1 + 3) 2; else dev_max = (3 * dr2 + 3) 2; if (dev_max = FT_MAX_CURVE_DEVIATION) ... Of course, this doesn't resolve the problem I mentioned above; for the example curve, this gives dev_max a value of 36 - still nine times too great. I hope to have something based a bit more closely on Hain's paper by the end of tomorrow. I may use something like the square-root avoiding estimate above to approximate his L value. David %^ -Original Message- From: freetype-devel-bounces+david.bevan=pb@nongnu.org [mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of Graham Asher Sent: 6 September 2010 11:10 To: freetype-devel Subject: [ft-devel] latest patch file for spline flattening Here's a new version of my spline flattening patch. (I would like to be able to push this to the git repository but am having authentication problems; Werner has been helping me, but no success so far, probably because of my ineptitude in these matters.). The nub of the latest change is that I found that predicting the number of recursion levels is not reliable when splitting a cubic spline for flattening. A better way is to check the flatness inside the loop - using the fast heuristic of taking the maximum coordinate difference of a control point from the chord midpoint. This also makes the code simpler - and, surprisingly, faster, according to my benchmark; however, my benchmark is based on cartographic, not typographic, use, so will need confirmation. The patch obviously still solves the bug involving s-shaped curves (control points on both sides of the chord). Graham ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] latest patch file for spline flattening
I'll do that. I wonder how much of the cost of FT_Load_Glyph is actually spent in gray_render_cubic and how much impact reducing the number of line segments has on later phases of the rendering process. I'm also trying to see if I can come up with a heuristic that is both fast (i.e. simple linear combinations of positions) and accurate (i.e. always correct and any overestimate is reasonably bounded). Then we may be able to avoid the complexities of Hain's approach. We so seem to be converging towards something that meets all the requirements. I probably won't achieve much today, but hope to spend most of tomorrow on this. David %^ -Original Message- From: Graham Asher [mailto:graham.as...@btinternet.com] Sent: 6 September 2010 12:36 To: David Bevan Cc: freetype-devel Subject: Re: [ft-devel] latest patch file for spline flattening David, in fact I coded up and tested a different version using an accurate calculation of the control point deviation, but it was slower than the version I am proposing. I'll try your version; and I would be grateful if you could also do some benchmarking, because obviously we are not trying to minimise the number of straight line segments the curve is dissected into, but the overall speed. My aims, and my benchmarking, are rather biased, because my main use of cubic splines is for approximations to arcs of circles, used as parts of path envelopes when drawing maps. Graham David Bevan wrote: Graham, That's looking much closer to what I would have thought we needed; only splitting the curve when required. However, your fast heuristic can be very inaccurate. Consider P0: 0,0 P1: 5,5 P2: 95,5 P3: 100,0 The max deviation is 3.75 (0.75 * 5 since Hain's v == 1), but your heuristic gives a value of 45 - twelve times too great. Btw, I think that dx1, dy1, ... need to be of type TPos, not int. On the issue of avoiding square roots, a little bit of algebra shows that it is possible to estimate r = sqrt(dx^2 + dy^2) with a simple linear combination of dx and dy. For example, if an overestimate is required, and dx = dy, you can use r_upperbound = dx + (sqrt(2) - 1) * dy which overestimates by no more than 8.5%. For integer arithmetic, sqrt(2) - 1 can be (over)estimated by 107/256. For example, you could use this approximation to do something like this: dx1 = abs(control1-x - midx); dy1 = abs(control1-y - midy); if (dx1 = dy1) dr1 = dx1 + (107 * dy1 + 255) 8; else dr1 = dy1 + (107 * dx1 + 255) 8; dx2 = abs(control2-x - midx); dy2 = abs(control2-y - midy); if (dx2 = dy2) dr2 = dx2 + (107 * dy2 + 255) 8; else dr2 = dy2 + (107 * dx2 + 255) 8; /* deviation never exceeds 75% of control point dist */ if (dr1 = dr2) dev_max = (3 * dr1 + 3) 2; else dev_max = (3 * dr2 + 3) 2; if (dev_max = FT_MAX_CURVE_DEVIATION) ... Of course, this doesn't resolve the problem I mentioned above; for the example curve, this gives dev_max a value of 36 - still nine times too great. I hope to have something based a bit more closely on Hain's paper by the end of tomorrow. I may use something like the square-root avoiding estimate above to approximate his L value. David %^ -Original Message- From: freetype-devel-bounces+david.bevan=pb@nongnu.org [mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of Graham Asher Sent: 6 September 2010 11:10 To: freetype-devel Subject: [ft-devel] latest patch file for spline flattening Here's a new version of my spline flattening patch. (I would like to be able to push this to the git repository but am having authentication problems; Werner has been helping me, but no success so far, probably because of my ineptitude in these matters.). The nub of the latest change is that I found that predicting the number of recursion levels is not reliable when splitting a cubic spline for flattening. A better way is to check the flatness inside the loop - using the fast heuristic of taking the maximum coordinate difference of a control point from the chord midpoint. This also makes the code simpler - and, surprisingly, faster, according to my benchmark; however, my benchmark is based on cartographic, not typographic, use, so will need confirmation. The patch obviously still solves the bug involving s-shaped curves (control points on both sides of the chord). Graham ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] more thoughts on cubic spline flattening
, there is an assumption that every bisection of a cubic spline increases its flatness fourfold. 7. Here is the proof that the assumption in (6) is wrong. A cubic spline with control points on different sides of the chord, symmetrically arranged, will be bisected at the point where it crosses the chord. The two halves will have exactly the same maximum deviation as the whole. This leads to the big question. Is it possible to determine the minimum number of bisections needed at the start, using a formula that does not itself apply the bisections - that is, something simpler than the exhaustive calculation? (Perhaps flatness does increase fourfold if the control points are the same side of the chord, so all we need do is add one iteration for an initial contrary case.) I suspect that the answer is no, but I am sure David Bevan will want to comment. If the answer is no, then I shall need to code up a fix that estimates flatness efficiently on each iteration of the bisection loop. Some queries: A. Perhaps it's obvious to someone familiar with the FreeType code, but (to save me time trying to work it out), in the units being used in gray_render_cubic, what is the maximum acceptable deviation value that should be used as a cut-off for stopping subdivision? Perhaps the answer could briefly explain the use of DOWNSCALE and UPSCALE. B. Would it be possible to have a copy of the font that was the catalyst for the changes in 2.4.0, along with details of the character / resolution / point-size which shows the problem. C. Similarly, would it be possible to have a copy of the font that showed up the bug in the changed code (with similar details). Thanks. David %^ David Bevan Development Manager Pitney Bowes Emtex Software Tel: +44 (0)1923 279300 david.be...@pb.com Comments please. Thanks in advance, Graham ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] more thoughts on cubic spline flattening
Some brief comments inline. More feedback from my investigations later. -Original Message- From: Graham Asher [mailto:graham.as...@btinternet.com] Sent: 3 September 2010 13:56 To: David Bevan Cc: FreeType Subject: Re: [ft-devel] more thoughts on cubic spline flattening David, you are of course correct that my point 5 is wrong. That is just carelessness on my part. Some clarifications: You point out that p0 and p3 can have coordinates outside the range 0...1 in Hain's r/s system. I deliberately ignore that, and I should have explained why in more explicit terms. The aim of FreeType is to rasterize the outline of a closed curve, and for this purpose I believe that, just as we can ignore deviations from the curve of greater than a certain tolerance, we can ignore spikes with maximum width less than that tolerance. P0 and P3 coordinates of this type create such spikes. That does not follow the recommended PostScript Language scan-conversion rules for path fills (PLRM3 7.5.1) - a shape is scan-converted by painting any pixel whose square region intersects the shape, however small the intersection is. Whether that rule should actually be applied to character shapes is another matter though (see the last paragraph of 7.5.1). But if we a heuristic based on the maximum distance of control point coordinates from the middle of the chord, the problem doesn't arise anyway. It arises only if we use Hain's algorithm fully. That's a very good point. You said my reading of Hain's paper is that the evaluation of square roots is never actually needed. To get the deviations of the control points we need to either (i) rotate the points into the r/s coordinate system, and the simplest way of creating a rotation transform requires square roots (convert chord vector to unit vector by dividing by vector length obtained by Pythagoras, then sine and cosine needed for transform are x and y coords of vector); or (ii) use the standard method of finding the distance of a point from a line, which again needs Pythagoras to get the lengths of vectors. I hope I've missed some simpler way of doing it, in which case please tell me. Hain explains how to do the calculations in section 3. The rotation is simply achieved by using the equation for s (where the denominator of L^2 can be ignored as Hain further explains). The last paragraph of section 3 then describes how to do the necessary comparison thereby avoiding a square root evaluation. The challenge will be ensuring that we can use the widest range of integer values without overflow. Squaring the P0-P3 distance seems unavoidable. Using unsigned 32-bit values (which we should be able to use for values which are always positive) allows us up to 65536 = 1023 pixels = 1.7 at 600dpi. However, there is one very simple heuristic solution to this: subdivide once automatically if the chord length is too great. In answer to your question A: the units are 64ths of a pixel, so 16 is a quarter pixel. That is for the normal case; FreeType can be configured to use different numbers of bits per pixel. The controlling macro is PIXEL_BITS in ftgrays.c Thanks for the answer; obviously your previous email gave a big hint! Regards, David %^ ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] more thoughts on cubic spline flattening
I've added some trace code to gray_render_cubic to report the average number of line segments created for a Bezier arc, and to calculate for each segment the (exact) deviation of the arc segment it replaces. I've still only tested this with the pre-2.4.0 code. Here are the results with my test data: For screen resolutions, an average of about 9 segments are generated per arc, with an average deviation of about 1.5 (x 1/64 pel) and a maximum deviation of about 11 (x 1/64 pel). For printer resolutions, an average of about 12 segments are generated per arc, with an average deviation of about 2.5 (x 1/64 pel) and a maximum deviation of about 20 (x 1/64 pel). In both cases, about 20% of the segments have a deviation less that 0.5 (x 1/64 pel). Assuming I have the time, next week I'll attempt to implement something based on Hain's paper. I will also do some profiling (timing) of the code, so we can compare performance. David %^ ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] Re: preliminary analysis of the problem with cubic spline optimisation
-Original Message- From: freetype-devel-bounces+david.bevan=pb@nongnu.org [mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of Graham Asher Sent: 29 August 2010 20:01 To: James Cloos Cc: freetype-devel Subject: Re: [ft-devel] Re: preliminary analysis of the problem with cubic spline optimisation It can happen, though. In fact I now don't think it can happen. If there are any good mathematicians out there (better than me at this, which sets quite a low bar), please confirm that no point on a cubic spline curve with both control points on the same side of the straight line from start to end can be further from the line than the curve's midpoint as defined by bisection of the curve. The point at maximal distance is the midpoint ONLY if the control points are equidistant from the chord. David %^ ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] a satisfactory fix for the cubic spline bug
Rather than piecemeal reinventing of the wheel, I would have thought that FT
should implement a mathematically rigorous flattener. The following might be a
good place to start:
http://www.cis.southalabama.edu/~hain/general/Publications/Bezier/Camera-ready%20CISST02%202.pdf
Or:
http://www.cis.usouthal.edu/~hain/general/Publications/Bezier/bezier%20cccg04%20paper.pdf
Naively, I had assumed that this sort of issue would have been resolved
properly back in the pre-history of FT, since it is obviously of critical
importance for correct output.
Since it apparently hasn't been, we can make use of the latest research.
David %^
-Original Message-
From: freetype-devel-bounces+david.bevan=pb@nongnu.org
[mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of
Graham Asher
Sent: 30 August 2010 10:59
To: freetype-devel
Subject: [ft-devel] a satisfactory fix for the cubic spline bug
I thought about this overnight and realised that we can slightly modify
the existing heuristic to get a much simpler fix. Instead of trying to
find points on the curve or trying to measure the distance from a point
to a straight line, we adapt the earlier idea, used in existing FreeType
code, of finding the maximum coordinate difference (that is, whichever
is greater of dx and dy):
* existing method: use max coordinate difference between middle of
spline, found by bisection, and middle of straight line
* new method: use max coordinate difference between either of the two
control points and the middle of the straight line
This yields the following code (start of gray_render_cubic), which
works, fixes the bug, and is probably faster, because it is certainly
simpler. I don't think I'll go any further than this.
static int
gray_render_cubic( RAS_ARG_ FT_Vector* control1,
FT_Vector* control2,
FT_Vector* to )
{
int top, level;
int*levels;
FT_Vector* arc;
int error = 0;
/*
Find the furthest distance of a coordinate of a control point from the
midpoint of the line.
*/
int dx1, dy1, dx2, dy2;
int midx = (DOWNSCALE(ras.x) + to-x) / 2;
int midy = (DOWNSCALE(ras.y) + to-y) / 2;
dx1 = control1-x - midx; if (dx1 0) dx1 = -dx1;
dy1 = control1-y - midy; if (dy1 0) dy1 = -dy1;
dx2 = control2-x - midx; if (dx2 0) dx2 = -dx2;
dy2 = control2-y - midy; if (dy2 0) dy2 = -dy2;
if (dx1 dy1)
dx1 = dy1;
if (dx1 dx2)
dx1 = dx2;
if (dx1 dy2)
dx1 = dy2;
if (dx1 = ras.cubic_level)
return gray_render_line( RAS_VAR_ to-x, to-y );
level = 1;
dx1 /= ras.cubic_level;
while ( dx1 0 )
{
dx1 = 2;
level++;
}
Graham
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] a satisfactory fix for the cubic spline bug
Graham/Werner, Perhaps I have misunderstood something. If so, I apologize. I hadn't been following this closely until I noticed an email saying that the curve flattening algorithm failed under some circumstances. That seemed very shocking to me. I would have presumed that the flattening algorithm would be defined in a mathematically rigorous manner and hence would be known to always work (bar any 'typos' in the code). Checking through the ft-devel archive suggests that the beginning of this issue was the message of 7th June, which starts, I have discovered a possible inefficiency in gray_render_cubic in ftsmooth.c. Removing it (by means of what I admit is a hack based on a limited understanding of the code) gives a vast speedup with no apparent loss of quality. For something as critical as the curve flattening, I wouldn't consider a hack of any sort appropriate. I haven't followed the message trail in detail but my understanding is that some version of this hack was accepted into the source and was subsequently shown to be incorrect. Fixes are now being proposed to the hack, and this is being done by someone who states that they are somewhat ignorant of the mathematics of cubic splines. If I was managing this project, I would certainly consider this an unacceptable approach / sequence of events. Better to keep the inefficiency than (a) break the functionality, and (b) end up with code that is not obviously correct. I didn't respond to the following query earlier: If there are any good mathematicians out there (better than me at this, which sets quite a low bar), please confirm that no point on a cubic spline curve with both control points on the same side of the straight line from start to end can be further from the line than the curve's midpoint as defined by bisection of the curve. A simple continuity/smoothness argument shows that the maximum deviation of a cubic spline is not always at the curve's midpoint: If with the control points on either side, the maximal deviation can be elsewhere, and a smooth movement of the control points leads to a smooth change in the curve then the position of the maximal deviation moves smoothly too (and hence is in fact hardly ever actually at the mid-point). I don't have time to investigate this in detail for a while, but might be able to do so sometime next week. David %^ P.S. I have a degree in mathematics from Oxford University. -Original Message- From: GRAHAM ASHER [mailto:graham.as...@btinternet.com] Sent: 31 August 2010 12:19 To: David Bevan; freetype-devel Subject: Re: [ft-devel] a satisfactory fix for the cubic spline bug David, Thank you very much for the citations, which are very interesting, but I don't think anybody is proposing reinventing anything - least of all me. The problem here is not whether there are known rigorous methods of determining the flatness of a curve. We are looking for a very fast heuristic that reduces the number of bisections of a cubic spline to the minimum in most cases, and behaves reasonably in other cases; in that it never reduces the number of bisections below the minimum, or produces far too many. Any system that always results in at least as many bisections as the minimum number required to flatten the curve to satisfy our definition of flatness, and does not enter an infinite loop, will give correct output.We know how to do the job correctly; the problem is doing it fast. After looking at the papers you cite for a short while my impression is that they cannot easily be used without floating-point arithmetic, which is not used in FreeType (and that policy certainly won't be relaxed for a while, I am sure). Fixed-point is never a satisfactory substitute where multiplication and squaring of coordinates is used, because it can easily lead to overflows of the need for elaborate work-arounds for overflows. Methods relying on the cubic spline formula will inevitably require cubes of coordinates. FreeType works in 64ths of pixels, so in signed 32-bit arithmetic we are restricted to a maximum coordinate size of sqrt(2^31) = 1290 64ths, or 20 pixels, which makes it impossible. The method described in the first paper you cite requires as a starting point the distance of the control points from the straight line, which needs squares and square roots, posing more problems for integer overflow and speed. If you can code up a better fix than mine, using one of the algorithms you cite, I will be very happy to withdraw my suggestion in favour of yours. I think an insuperable difficulty will be the possibility of overflow and the speed of the code. I hope to be proved wrong! Best regards, Graham - Original Message From: David Bevan david.be...@pb.com To: freetype-devel freetype-devel@nongnu.org Sent: Tuesday, 31 August, 2010
RE: [ft-devel] rasterization without sorting - in defence of my approach
-Original Message- From: freetype-devel-bounces+david.bevan=pb@nongnu.org [mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of GRAHAM ASHER Sent: 23 July 2010 08:57 To: Werner LEMBERG Cc: FreeType Subject: [ft-devel] rasterization without sorting - in defence of my approach ... I am also aware that FreeType's sole purpose is to rasterize glyphs, while mine is also to rasterize large arbitrary shapes. Nevertheless, these aims tend to converge as display resolution improves; at modern resolutions of around 200dpi, 18pt glyphs are as large as 50 x 50 pixels. Graham, Since some of us use FreeType to render glyphs at printer (300dpi or 600dpi) resolutions, any performance improvement, especially for Far Eastern fonts will be appreciated. Thanks. David %^ ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] charmap index should be same with cmap subtable index?
Hi! Our software uses the FreeType charmap index directly to access the appropriate cmap. (In retrospect, that was perhaps a poor design decision.) We will need to be able to retain the existing behaviour. However, if the original index is available somehow, we would have no problems with a change in what we need to do to retrieve it. Thanks. David %^ -Original Message- From: freetype-devel-bounces+david.bevan=pb@nongnu.org [mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of mpsuz...@hiroshima-u.ac.jp Sent: 7 July 2010 10:47 To: freetype-devel@nongnu.org Subject: [ft-devel] charmap index should be same with cmap subtable index? Hi all, When I was working with Savannah bug #30059, http://savannah.nongnu.org/bugs/?30059 I had a question about the relation between the index for FT_Face-charmap[] and the index for cmap subtable in TTF/OTF. When FT2 handles clean TTF/OTF, they are exactly same. # In Microsoft TrueType spec, having 2 subtables # with same platformID/encodingID was prohibited. # But now ISO/IEC 14496-22 permits such as far # as languageID are different. OpenType spec recommends to sort cmap subtables by platformID/encodingID/languageID. Looking at the encodingID naming convention for (Apple's) Unicode, ISO and Microsoft platforms, the search from the last to the first is best to find the widest cmap subtable for Unicode. However, the sorting is recommended but not required. In Apple's TrueType specification, I could not find any request to sort cmap subtables. Thus, there is a possibility that the last cmap subtable is the widest Unicode cmap. In the case of Savannah bug #30059, the sample font including so many cmap subtables (ca. 400, about 100 subtables can be parsed, 300 tables are heavily broken) was used to make FT2 cache system crashed. This is extreme case, but it is true that FT2 cannot handle a TTF/OTF including cmap subtables 15. In addition, if cmap includes some seriously broken subtables, FT2 ignores them, give no index for them. Considering this behaviour, I want to try a re-sort of cmap subtables in FT2 during the parsing of cmap table (as an experiment). It will completely disconnect the index in FT_Face-charmaps[] and the index for TTF/OTF cmap subtables. Does the disconnection cause serious problem in FT2 clients? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] charmap index should be same with cmap subtable index?
The requirement for our software is backwards compatibility with current FT2 behaviour - not for identity between FT2 charmap index and TrueType cmap subtable index. It is possible, however, that we have never seen heavily broken subtables and that (some of) our code does in fact depend on the FT2 charmap index and the TT cmap subtable index being the same - and would need changing if we did encounter a broken TTF. David %^ -Original Message- From: mpsuz...@hiroshima-u.ac.jp [mailto:mpsuz...@hiroshima-u.ac.jp] Sent: 12 July 2010 09:31 To: David Bevan Cc: freetype-devel@nongnu.org Subject: Re: [ft-devel] charmap index should be same with cmap subtable index? Dear David, Thank you for information! I'm not pushing the charmap sorting features to default behaviour, but knowing the exist of softwares that requires the consistency between FT2 charmap index versus TTF/OTF cmap subtable index. I want to ask another question about your software: FT2 charmap index should be exactly same with TrueType cmap subtable index? As described in my previous post, FT2 charmap index is not exactly same. If TrueType cmap table includes heavily broken subtables, FT2 does not assign the index to them, they are automatically ignored. It is negligible if we use clean fonts only, but if FT2 user want to use FT2 as an inspector of TTF/OTF this skipping behaviour might be confusing. I think it is possible for FT2 to assign the index even to broken subtable and make charmap index same with TTF/OTF cmap subtable index. Regards, mpsuzuki On Mon, 12 Jul 2010 04:12:28 -0400 David Bevan david.be...@pb.com wrote: Hi! Our software uses the FreeType charmap index directly to access the appropriate cmap. (In retrospect, that was perhaps a poor design decision.) We will need to be able to retain the existing behaviour. However, if the original index is available somehow, we would have no problems with a change in what we need to do to retrieve it. Thanks. David %^ -Original Message- From: freetype-devel-bounces+david.bevan=pb@nongnu.org [mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of mpsuz...@hiroshima-u.ac.jp Sent: 7 July 2010 10:47 To: freetype-devel@nongnu.org Subject: [ft-devel] charmap index should be same with cmap subtable index? Hi all, When I was working with Savannah bug #30059, http://savannah.nongnu.org/bugs/?30059 I had a question about the relation between the index for FT_Face-charmap[] and the index for cmap subtable in TTF/OTF. When FT2 handles clean TTF/OTF, they are exactly same. # In Microsoft TrueType spec, having 2 subtables # with same platformID/encodingID was prohibited. # But now ISO/IEC 14496-22 permits such as far # as languageID are different. OpenType spec recommends to sort cmap subtables by platformID/encodingID/languageID. Looking at the encodingID naming convention for (Apple's) Unicode, ISO and Microsoft platforms, the search from the last to the first is best to find the widest cmap subtable for Unicode. However, the sorting is recommended but not required. In Apple's TrueType specification, I could not find any request to sort cmap subtables. Thus, there is a possibility that the last cmap subtable is the widest Unicode cmap. In the case of Savannah bug #30059, the sample font including so many cmap subtables (ca. 400, about 100 subtables can be parsed, 300 tables are heavily broken) was used to make FT2 cache system crashed. This is extreme case, but it is true that FT2 cannot handle a TTF/OTF including cmap subtables 15. In addition, if cmap includes some seriously broken subtables, FT2 ignores them, give no index for them. Considering this behaviour, I want to try a re-sort of cmap subtables in FT2 during the parsing of cmap table (as an experiment). It will completely disconnect the index in FT_Face-charmaps[] and the index for TTF/OTF cmap subtables. Does the disconnection cause serious problem in FT2 clients? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] FT_LOAD_VERTICAL_LAYOUT?
Thanks for the feedback on this.
Does anyone have access to any PDF files which contain vertical writing mode
text? If so, would it be possible to send some to me off-line?
Thanks.
David %^
-Original Message-
From: Behdad Esfahbod [mailto:behdad.esfah...@gmail.com] On Behalf Of Behdad
Esfahbod
Sent: 05 May 2010 20:40
To: David Bevan
Cc: freetype-devel@nongnu.org; Antony Bush; Stephen Brazier; Houjie Tu
Subject: Re: [ft-devel] FT_LOAD_VERTICAL_LAYOUT?
On 05/05/2010 08:55 AM, David Bevan wrote:
And how /should/ FreeType be used for vertical writing mode?
This is how cairo handles it:
/*
* Translate glyph to match its vertical metrics.
*/
static void
_cairo_ft_scaled_glyph_vertical_layout_bearing_fix (void*abstract_font,
FT_GlyphSlot glyph)
{
cairo_ft_scaled_font_t *scaled_font = abstract_font;
FT_Vector vector;
vector.x = glyph-metrics.vertBearingX - glyph-metrics.horiBearingX;
vector.y = -glyph-metrics.vertBearingY - glyph-metrics.horiBearingY;
if (glyph-format == FT_GLYPH_FORMAT_OUTLINE) {
FT_Vector_Transform (vector, scaled_font-unscaled-Current_Shape);
FT_Outline_Translate(glyph-outline, vector.x, vector.y);
} else if (glyph-format == FT_GLYPH_FORMAT_BITMAP) {
glyph-bitmap_left += vector.x / 64;
glyph-bitmap_top += vector.y / 64;
}
}
behdad
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FT_LOAD_VERTICAL_LAYOUT?
freetype.h (and the online documentation) contains the following for FT_LOAD_VERTICAL_LAYOUT * FT_LOAD_VERTICAL_LAYOUT :: * Load the glyph for vertical text layout. _Don't_ use it as it is * problematic currently. Is the warning still valid? If it is, in what ways is FT_LOAD_VERTICAL_LAYOUT problematic? And how should FreeType be used for vertical writing mode? David %^ David Bevan Development Manager Pitney Bowes Emtex Software Tel: +44 (0)1923 279300 david.be...@pb.commailto:david.be...@pb.com ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] freetype compilation warnings
All the proposed solutions assume that there is a (known) integer size which matches the pointer size. This is clearly a compiler-specific requirement. For example, in the latest proposal below, if unsigned long is 32-bit and void* is 64-bit [which I believe is the case with 64-bit MSVC - which is LLP64], ALL_POINTS receives the value 0x (~0UL) rather than the expected 0x - hence the helpful compiler warning. I would expect something like the following to work (though I don't have a suitable compiler to hand to test). #define ALL_POINTS (FT_UShort*)((FT_Byte*)(NULL) - 1); Hth, David %^ -Original Message- From: freetype-devel-bounces+dbevan=emtex@nongnu.org [mailto:freetype-devel-bounces+dbevan=emtex@nongnu.org] On Behalf Of Ken Sharp Sent: 12 January 2010 08:12 To: Sean McBride Cc: freetype-devel@nongnu.org Subject: Re: [ft-devel] freetype compilation warnings At 12:28 11/01/2010 -0500, Sean McBride wrote: #define ALL_POINTS (FT_UShort*)(void*)( ~0UL ) I don't have the compiler in question, so the only way for me to test is commit the change to VTK CVS then wait for the next automated nightly build. :( Anyone here have Visual Studio? Yes, any particular version required ? Ken Sean McBride s...@rogue-research.com wrote: On 1/9/10 6:40 AM, Werner LEMBERG said: What about a double cast? #define ALL_POINTS (FT_UShort*)(void*)( -1 ) Since NULL is normally defined as `(void*)0' I can imagine that the above works. Can you try this, please? That did not work. :( The warning only changed to: warning C4306: 'type cast' : conversion from 'int' to 'void *' of greater size Does it work better this way: #define ALL_POINTS (FT_UShort*)(void*)( ~0 ) or #define ALL_POINTS (FT_UShort*)(void*)( ~0UL ) ? -- Dmitry. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
