RE: [ft-devel] Force PMingLiU like font do HINTING
After some thinking I can imagine that the following works. . Add `FT_FACE_FLAG_TRICKY'. If set, the font is tricky. To access it, add a macro `FT_IS_TRICKY'. [This is a read-only flag.] . Change the meaning of `FT_LOAD_NO_HINTING' so that fonts which always need TrueType instructions (these are fonts which have FT_FACE_FLAG_TRICKY set) ignore it. . Instead of adding a new `FT_LOAD_RAW' flag which would do what `FT_LOAD_NO_HINTING' currently does, I propose that we get the behaviour of `raw' loading if both `FT_LOAD_NO_HINTING' and FT_LOAD_NO_AUTOHINT are set. Werner, For the patented hinter, the FT_LOAD_NO_HINTING turns off the hinting. Do you want to change that behavior for the applications that use the patented hinter? Thanks, Sergey ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] Force PMingLiU like font do HINTING
Hello, How is it possible to decide from the font it is unusable with FT_LOAD_NO_HINTING? Thank you, Sergey Tolstov -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Werner LEMBERG Sent: Thursday, December 04, 2008 12:06 AM To: [EMAIL PROTECTED] Cc: freetype-devel@nongnu.org Subject: Re: [ft-devel] Force PMingLiU like font do HINTING The tricky fonts like PMingLiU need unpatented hinting. Those fonts are unusable at all when programmers accidently turns on FT_LOAD_NO_HINTING. So I think freetype should force fonts like those to ignore FT_LOAD_NO_HINTING. This is a fundamental question. My opinion is that shifting of glyph elements using TrueType instructions clearly is (a kind of) hinting. In other words, I don't like to change the current behaviour of FreeType without good reasons. However, it might be helpful if FreeType emits a warning message that the font is probably unusable. Hmm. Opinions, please. Maybe most of you disagree, so please chime in. And detecting of tricky font should be outside of this defines: #if defined( TT_CONFIG_OPTION_UNPATENTED_HINTING) \ !defined( TT_CONFIG_OPTION_BYTECODE_INTERPRETER ) otherwise, the fonts are not detected on my debian box. This is probably fixed already in the CVS: 2008-11-05 Werner Lemberg [EMAIL PROTECTED] * devel/ftoption.h, include/freetype/config/ftoption.h [TT_CONFIG_OPTION_BYTECODE_INTERPRETER]: Undefine TT_CONFIG_OPTION_UNPATENTED_HINTING. This fixes the return value of `FT_Get_TrueType_Engine_Type' (and makes it work as documented). Reported in bug #441638 of bugzilla.novell.com. Please test. Otherwise, please report the vales of those two macros on your box. 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
RE: [ft-devel] TrueType bytecode interpreter enhancements
Hello, This is really good news! The GetFontData API allows to retrieve the data of the actual font selected into the device context. Use 0 as the table name for all but ttc fonts. For ttc use 'ttcf'. Then you can load it into memory with FT functions, or find corresponding font file on disk by comparing important fields. Thanks, Sergey Tolstov -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Turner Sent: Friday, August 25, 2006 11:48 PM To: freetype-devel@nongnu.org Subject: [ft-devel] TrueType bytecode interpreter enhancements Hello everyone, I've commited last week some improvements to the bytecode interpreter in order to get rid of some of the remaining differences with the Windows rendering engine. I've only tested it by hand, i.e. by comparing the results produced with previous versions and known defects, which means I'm still unsure if the CVS code is correct or if it did introduce regressions. In order to make real testing, I'm trying to write a small Win32 program that compares the output of the GetGlyphOutline function with FreeType's output, in order to spot differences automatically. I'm however currently blocked because there seems to be no way to retrieve the path of an installed font file on Windows from its logical font name. Does anyone has any idea on how to deal with this ? In the meantime, I encourage you to test the CVS code, and report any discrepancies or improvements that would strike you. Note that this doesn't solve certain problems (like extraneous pixels in the '8' or Verdana at size 11pt/72dpi, which don't appear on Windows due to a bug in its rasterizer) Regards, ___ 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
[ft-devel] Test. Ignore, please.
I have subscribed to the list quite a while ago, but have not received a single message yet. Sergey Tolstov ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
