Re: [ft-devel] FreeType 2.3.0 release candidate 1 is available
Mike FABIAN [EMAIL PROTECTED] さんは書きました: I don't know whether this is related, but I found that the rendering of the font Consolas from Windows Vista has become worse. This problem is still unchanged in freetype 2.3.1. For details of the problem with a screen shot see http://lists.gnu.org/archive/html/freetype/2007-01/msg00032.html By the way, freetype 2.3.1 packages for various versions of openSUSE/SuSE Linux are available here: http://software.opensuse.org/download/M17N/ -- Mike FABIAN [EMAIL PROTECTED] http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。 I � Unicode ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft] Re: [ft-devel] FreeType 2.3.0 release candidate 1 is available
I think Suzuki-San's changes here may need elaboration. Perhaps just something along the lines of if you use ftmac.c, please note that it is now Mac OS X-only, and that some old APIs now return errors. Thus your code should still build unchanged, but may change in behaviour. I've added this to the CHANGES file, thanks. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft] Re: [ft-devel] FreeType 2.3.0 release candidate 1 is available
Dear Werner, Sorry for my inactivity during this 4 weeks. On Sat, 13 Jan 2007 09:52:29 +0100 (CET) Werner LEMBERG [EMAIL PROTECTED] wrote: I think Suzuki-San's changes here may need elaboration. Perhaps just something along the lines of if you use ftmac.c, please note that it is now Mac OS X-only, and that some old APIs now return errors. Thus your code should still build unchanged, but may change in behaviour. I've added this to the CHANGES file, thanks. Please check JPEG picture summarizing the difference from 2.1.10 and 2.2, http://www.gyve.org/mpsuzuki/ft23-history.jpeg http://www.gyve.org/mpsuzuki/ft23-behaviour.jpeg and please review attached patch for documents. I think the important change is only FT_GetFile_From_Mac_Name(). However, appropriate configure option can make fully compatible libfreetype. I was going to add new function FT_GetFileRef_From_Mac_ATSName(). If adding new function in release-candidate phase is acceptable, please let me know. I will do that within 24 hours. Regards, mpsuzuki freetype2-macdoc.patch Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft] Re: [ft-devel] FreeType 2.3.0 release candidate 1 is available
and please review attached patch for documents. Committed (with slight modifications). Please check. I was going to add new function FT_GetFileRef_From_Mac_ATSName(). If adding new function in release-candidate phase is acceptable, please let me know. I will do that within 24 hours. This is fine for me, if it helps to resolve compatibility issues with older FreeType versions. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft] Re: [ft-devel] FreeType 2.3.0 release candidate 1 is available
On Sun, 14 Jan 2007 00:00:42 +0100 (CET) Werner LEMBERG [EMAIL PROTECTED] wrote: and please review attached patch for documents. Committed (with slight modifications). Please check. I've checked, your modification improves well, thank you. I was going to add new function FT_GetFileRef_From_Mac_ATSName(). If adding new function in release-candidate phase is acceptable, please let me know. I will do that within 24 hours. This is fine for me, if it helps to resolve compatibility issues with older FreeType versions. No, FT_GetFileRef_From_Mac_ATSName() won't help the behaviour compatibility issues with older FreeType2 versions, at all. It is a public function for (near-)future Mac OS X missing the functions and data-types that have been announced as deprecated. On such system missing deprecated Carbon function data-types, I cannot provide behaviour-compatible function (of FT_GetFile_xxx), only I can do is providing a function with similar behaviour (FT_GetFileRef_xxx) to help the migration. If adding new symbol in 2.3.0 - 2.3.1 is better than that in 2.2.1 - 2.3.0, I will postpone. # IMHO, FT_GetFileRef_xxx() will be deprecated in long-future. # The incompatible behaviour issues will continue until Carbon- # free Mac font support (that I'm working but long work). # The root of problem was introduced between 2.0.5 and 2.0.6. # http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/base/ftmac.c?r1=1.15r2=1.16 Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType 2.3.0 release candidate 1 is available
Excuse me, I cancell my previous post. On Sun, 14 Jan 2007 09:17:18 +0900 [EMAIL PROTECTED] wrote: I was going to add new function FT_GetFileRef_From_Mac_ATSName(). If adding new function in release-candidate phase is acceptable, please let me know. I will do that within 24 hours. This is fine for me, if it helps to resolve compatibility issues with older FreeType versions. No, FT_GetFileRef_From_Mac_ATSName() won't help the behaviour compatibility issues with older FreeType2 versions, at all. # IMHO, FT_GetFileRef_xxx() will be deprecated in long-future. # The incompatible behaviour issues will continue until Carbon- # free Mac font support (that I'm working but long work). Considering the compatibility stability in freetype-2.3.x series, I want to postpone FT_GetFileRef_From_Mac_ATSName(). Considering the direction to remove Carbon dependency, the introduction of API using FSRef (Carbon dependent data type) is not good idea, FT_GetFilePath_From_Mac_ATSName() may be more stable API and it is easy for programmers to replace it by fontconfig library. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FreeType 2.3.0 release candidate 1 is available
Hello everyone, just to inform you that FreeType 2.3.0rc1 is now available at the following web addresses: http://david.freetype.org/freetype/freetype-2.3.0rc1.tar.gz http://david.freetype.org/freetype/freetype-2.3.0rc1.tar.bz2 http://david.freetype.org/freetype/ft230rc1.zip you can also grab it from the CVS using the VER-2-3-0-RC1 tag as the name suggest, this is a release candidate, not the final package. We now need to build and install it on many systems to check that everything works fine. The minor version number was increased due to what I believe are numerous improvements in auto-hinting, performance, memory usage, as well as new features like automatic support for unpatented hinting, LCD color filtering and a few more things. There should be *no* break of ABI or API since the last two releases (2.2.1 and 2.1.10), if you detect a severe problem when installing this version, that's clearly a bug that should be reported on this mailing list. Building/Installation volunteers are welcomed. I'm especially curious about warning messages happening during compilations on exotic platforms, since we try to *completely* prevent them in our official releases. Regards and enjoy, - David Turner - The FreeType Project (www.freetype.org) copy of docs/CHANGES CHANGES BETWEEN 2.3.0 and 2.2.1 I. IMPORTANT BUG FIXES - The PCF font loader is now much more robust while loading malformed font files. - Various memory leaks have been found and fixed. - The TrueType name loader now deals properly with some fonts that encode their names in UTF-16 (the specification was vague, and the code incorrectly assumed UCS-4). - Fixed the TrueType bytecode loader to deal properly with subtle monochrome/gray issues when scaling the CVT. Some fonts exhibited bad rendering artifacts otherwise. - FT_GlyphSlot_Embolden now supports vertical layouts correctly (it mangled the vertical advance height). II. NEW API FUNCTIONS - `FT_Library_SetLcdFilter' allows you to select a special filter to be applied to the bitmaps generated by `FT_Render_Glyph' if one of the FT_RENDER_MODE_LCD and FT_RENDER_MODE_LCD_V modes has been selected. This filter is used to reduce color fringes; several settings are available through the FT_LCD_FILTER_XXX enumeration. Its declaration and documentation can be found in file `include/freetype/ftlcdfil.h' (to be accessed with macro FT_LCD_FILTER_H). *IMPORTANT*: This function returns an error (FT_Err_Unimplemented_Feature) in default builds of the library for patent reasons. See below. - `FT_Get_Gasp' allows you to query the flags of the TrueType `gasp' table for a given character pixel size. This is useful to duplicate the text rendering of MS Windows, when the native bytecode interpreter is enabled (which isn't the default for other patent reasons). Its declaration and documentation can be found in file `include/freetype/ftgasp.h' (to be accessed with macro FT_GASP_H). III. IMPORTANT CHANGES - The auto-hinter has been tuned a lot to improve its results with serif fonts, resulting in much better font rendering of many web pages. - The unpatented hinter is now part of the default build of the library; we have added code to automatically support `tricky' fonts that need it. This means that FreeType should `just work' with certain Asian fonts, like MingLiU, which cannot properly be loaded without a bytecode interpreter, but which fortunately do not use any of the patented bytecode opcodes. We detect these fonts by name, so please report any font file that doesn't seem to work with FreeType, and we shall do what we can to support it in a next release. Note that the API hasn't changed, so you can still force unpatented hinting with a special parameter to FT_Open_Face as well. This might be useful in same cases; for example, a PDF reader might present a user option to activate it to deal with certain `tricky' embedded fonts which cannot be clearly identified. If you are a developer for embedded systems, you might want to *disable* the feature to save code space by undefining TT_CONFIG_OPTION_UNPATENTED_HINTING in ftoption.h. - LCD-optimized rendering is now DISABLED in all default builds of the library, mainly due to PATENT issues. For more information see: http://lists.gnu.org/archive/html/freetype/2006-09/msg00064.html A new configuration macro FT_CONFIG_OPTION_SUBPIXEL_RENDERING has been introduced in ftoption.h; manually define it
Re: [ft] Re: [ft-devel] FreeType 2.3.0 release candidate 1 is available
On Fri, 12 Jan 2007 11:14:35 -0500, Sean McBride [EMAIL PROTECTED] said: On 2007-01-11 12:52, David Turner said: There should be *no* break of ABI or API since the last two releases (2.2.1 and 2.1.10) Except for ftmac.c right? At least, depending on a *great many* defines, some functions now *potentially* have different behaviour. For example: that's not exactly a breakage. An ABI breakage is when installing a new version of the library breaks other programs that depend on it (e.g. they crash or refuse to start, due to unmet symbols/dependencies). An API breakage is when existing sources can't compile with the new release of a package anymore, because some ugly things happened in the public headers. What you described my be flagged as a regression though, I don't know exactly; what do you mean when you say that the function may have done more previously ? Was it even a correct behaviour ? Regards, - David Turner - The FreeType Project (www.freetype.org) http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/base/ftmac.c? r1=texttr1=1.48r2=texttr2=1.49diff_format=l For example, FT_GetFile_From_Mac_Name() now always returns an error, where before, depending on #defines, it may have done more. This is the whole gutting of Mac OS 9 cruft that was discussed here previously. Building/Installation volunteers are welcomed. I'm especially curious about warning messages happening during compilations on exotic platforms, since we try to *completely* prevent them in our official releases. See: http://www.mail-archive.com/freetype-devel@nongnu.org/msg01648.html Additionally I have confirmed that RC1 builds on several different Mac configs. CHANGES BETWEEN 2.3.0 and 2.2.1 *SNIP* - Better support for Mac Fonts on POSIX systems, plus compilation fixes for PPC64. I think Suzuki-San's changes here may need elaboration. Perhaps just something along the lines of if you use ftmac.c, please note that it is now Mac OS X-only, and that some old APIs now return errors. Thus your code should still build unchanged, but may change in behaviour. -- Sean McBride, B. Eng [EMAIL PROTECTED] Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
