Re: [ft-devel] Re: possible inefficiency in gray_render_cubic
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 http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problem with ligatures and strikes
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). My question is, how does Windows deal with this? Do they turn certain features off if using strikes? Not form the ligature if not found in the current strike? I need help understanding this to implement the correct behavior since I don't have access to Windows. I'm interested in an answer too. Anyone here who has some insight? Otherwise we should probably contact the OpenType list for more information. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: possible inefficiency in gray_render_cubic
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 longjmp; incidentally, with no performance penalty and little extra complexity. Best regards, Graham Werner LEMBERG wrote: 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 http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: possible inefficiency in gray_render_cubic
[...] 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 there benefits for removing setjmp/longjmp except portability to other programming languages? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problem with ligatures and strikes
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 matter if some bitmaps are missing from the set of stored bitmaps; they are (or should be) guaranteed to be the same as the bitmaps which would be generated from the outline and instructions in the font file. And that should include generated ligatures. Graham Behdad Esfahbod wrote: Hi, 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). My question is, how does Windows deal with this? Do they turn certain features off if using strikes? Not form the ligature if not found in the current strike? I need help understanding this to implement the correct behavior since I don't have access to Windows. behdad ___ 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] Re: possible inefficiency in gray_render_cubic
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 remove setjmp/longjmp and change a few symbols which conflicted with new keywords, like 'generic'. It was an interesting exercise, but proved to be a dead end (for the moment) because C++/CLI is not supported for Windows Mobile, and 'portable' .NET assemblies seem not in fact to be portable. Doing this showed that setjmp and longjmp are not necessary for FreeType; and perhaps they should be removed in future; but there's no compelling reason to do so right now. Graham Werner LEMBERG wrote: [...] 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 there benefits for removing setjmp/longjmp except portability to other programming languages? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: possible inefficiency in gray_render_cubic
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 Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: possible inefficiency in gray_render_cubic
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 Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: possible inefficiency in gray_render_cubic
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 not necessary for FreeType; Indeed. They are only used for error-handling in the validator modules. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
