Re: [ft-devel] Re: possible inefficiency in gray_render_cubic

2010-06-10 Thread Werner LEMBERG
here's what I think is a better version of the start of the function. [...] This is now in the git repository (with small fixes to make it compile). Thanks a lot! Please test. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org

Re: [ft-devel] Problem with ligatures and strikes

2010-06-10 Thread Werner LEMBERG
The Calibri font shipped in Windows XP has bitmap strikes for a variety of sizes, but from what I understand, no bitmap glyphs for many ligature combination it defines in its GSUB table, for example, for 'tt', 'ft', 'ffi' among others. That results in very ugly rendering (see attached).

Re: [ft-devel] Re: possible inefficiency in gray_render_cubic

2010-06-10 Thread Graham Asher
You're welcome - I see that you had to get rid of a check on the return value of gray_render_line, which I forgot about. That is there because I use a modified version of FreeType that can be compiled as pure .NET intermediate language code; and to do that I had to get rid of setjmp and

Re: [ft-devel] Re: possible inefficiency in gray_render_cubic

2010-06-10 Thread Werner LEMBERG
[...] I use a modified version of FreeType that can be compiled as pure .NET intermediate language code; and to do that I had to get rid of setjmp and longjmp; incidentally, with no performance penalty and little extra complexity. Is this something we should consider in general? I mean, are

Re: [ft-devel] Problem with ligatures and strikes

2010-06-10 Thread Graham Asher
In your image, why are the ligatures anti-aliased, while the main text is not? Surely you should generate non-anti-aliased glyphs to go with the non-anti-aliased bitmaps stored in the font file; or, if anti-aliasing is desired, the stored bitmaps should not be used. In general, it should not

Re: [ft-devel] Re: possible inefficiency in gray_render_cubic

2010-06-10 Thread Graham Asher
No, I don't think it's worth worrying about this right now. I worked on this because I wanted to create a version of my CartoType library as a portable .NET assembly, and in fact I managed to compile CartoType as C++/CLI code, which is a tribute to its robustness; but to do that I had to

Re: [ft-devel] Re: possible inefficiency in gray_render_cubic

2010-06-10 Thread Behdad Esfahbod
On 06/10/2010 05:17 AM, Graham Asher wrote: Doing this showed that setjmp and longjmp are not necessary for FreeType; Indeed. They are only used for error-handling in the validator modules. behdad ___ Freetype-devel mailing list

Re: [ft-devel] Re: possible inefficiency in gray_render_cubic

2010-06-10 Thread Behdad Esfahbod
On 06/10/2010 05:17 AM, Graham Asher wrote: Doing this showed that setjmp and longjmp are not necessary for FreeType; Indeed. They are only used for error-handling in the validator modules. behdad ___ Freetype-devel mailing list

Re: [ft-devel] Re: possible inefficiency in gray_render_cubic

2010-06-10 Thread Graham Asher
Unfortunately not only there but in the rasterizer, if memory serves. They were not in any place where I could get rid of them easily by disabling certain features. Graham Behdad Esfahbod wrote: On 06/10/2010 05:17 AM, Graham Asher wrote: Doing this showed that setjmp and longjmp are