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. Uh, oh, I have no idea what you are talking about. Please provide more context, especially the formulae you are referring to. It would also help if you use lines to connect the control points in the image. Werner ___ 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] cubic clean up
I am really annoyed by run-arounds and overzealous protection of code by authors. I was proposing a minor benign improvement. I am touching the water so to speak. What's the big deal? Way to attract developers, freetypers! You go! ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] cubic clean up
I think I can get though to this guy... 2010/11/12 David Bevan david.be...@pb.com: 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. Think about it a little more. Imagine a long chord of a dozen pixels. Those white areas are vanishing. Now think about a short chord of a pixel and a half. Those areas are large. However, do you really want to flatten a curve which pitches orthogonally? Think about it. 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. Let's face it. It's only you and me who understand these conditions. You were able to understand my code. Let's drop the opaque argument. I changed the comment for a reason. We can improve it more. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] cubic clean up
Aleksei, you really shouldn't be annoyed. My earlier patch was shown to be inferior to David Bevan's, and I was obliged to accept the fact. The only possible criteria are objective ones: does it work? is it faster? is it simpler? I believe David has shown using objective arguments that the patch should not be included. That's not a run-around. It is a courteous consideration of your suggestion, and you should be grateful for it. Also, you don't help your case at all by remarks like I think I can get though to this guy... and It's only you and me who understand these conditions. which are at best patronising and at worst impolite. Best regards, Graham - Original Message From: Алексей Подтележников apodt...@gmail.com To: freetype-devel freetype-devel@nongnu.org Sent: Friday, 12 November, 2010 12:16:14 Subject: Re: [ft-devel] cubic clean up I am really annoyed by run-arounds and overzealous protection of code by authors. I was proposing a minor benign improvement. I am touching the water so to speak. What's the big deal? Way to attract developers, freetypers! You go! ___ 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] cubic clean up
All, If you at least admitted that my patch would produce a better code... If you at least admitted that my patch is interesting... I would gladly provide more explanation. Instead, I hear should not be applied for some bogus reasons, actually just one reason I do not understand it. Now you are pulling the politeness argument... Please stop. Alexei 2010/11/12 GRAHAM ASHER graham.as...@btinternet.com: Aleksei, you really shouldn't be annoyed. My earlier patch was shown to be inferior to David Bevan's, and I was obliged to accept the fact. The only possible criteria are objective ones: does it work? is it faster? is it simpler? I believe David has shown using objective arguments that the patch should not be included. That's not a run-around. It is a courteous consideration of your suggestion, and you should be grateful for it. Also, you don't help your case at all by remarks like I think I can get though to this guy... and It's only you and me who understand these conditions. which are at best patronising and at worst impolite. Best regards, Graham - Original Message From: Алексей Подтележников apodt...@gmail.com To: freetype-devel freetype-devel@nongnu.org Sent: Friday, 12 November, 2010 12:16:14 Subject: Re: [ft-devel] cubic clean up I am really annoyed by run-arounds and overzealous protection of code by authors. I was proposing a minor benign improvement. I am touching the water so to speak. What's the big deal? Way to attract developers, freetypers! You go! ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel -- Alexei A. Podtelezhnikov, PhD ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] cubic clean up
On 11/12/10 07:56, Алексей Подтележников wrote: Let's face it. It's only you and me who understand these conditions. Not really. The rest of us just don't care. Because it's just a Bezier flattener after all... No personal attacks on this list. We're grown ups. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: About Gsub table in opentype.
[+harfbuzz list, Kenichi Handa] On 11/06/10 05:22, mpsuz...@hiroshima-u.ac.jp wrote: Hi, To parse OpenType tables at low level and obtain the substituted glyph index, libotf might be useful. http://www.m17n.org/libotf/ Interesting. I had totally forgotten about libotf. I hope now that new harfbuzz is in a usable state Kenichi abandons the libotf and helps with harfbuzz. behdad It does not provide the database of the tags of script, language and features, and no dependency/conflict checker of each features. So libotf client programmer have to read OpenType spec and choose appropriate script/language/feature to apply to the serie of the glyph index. Regards, mpsuzuki On Sat, 06 Nov 2010 09:50:28 +0100 (CET) Werner LEMBERG w...@gnu.org wrote: do you know any other small open source library can do this job? No. i just want to display the vertical characters, the layout engine is to big for me. Then load the GSUB table with FT_Load_Sfnt_Table and parse the data by yourself. This is rather straightforward. Werner ___ 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
