Problems reported by suyu@cooee.cn.
* src/smooth/ftgrays.c (FT_DEFINE_OUTLINE_FUNCS,
FT_DEFINE_RASTER_FUNCS) [_STANDALONE_]: Define.
[!_STANDALONE_]: Include ftspic.h only here.
(ras): Define/declare after definition of `TWorker'.
Use `RAS_VAR_' where necessary.
* src/smooth/ftsmooth.h declare ft_smooth_renderer_class,
ft_smooth_lcd_renderer_class and ft_smooth_lcd_v_renderer_class
using macros from ftrender.h,
when FT_CONFIG_OPTION_PIC is defined create and destroy
functions will be declared.
* src/smooth/ftsmooth.c when FT_CONFIG_OPTION_PIC is defined
the following structs:
ft_smooth_renderer_class, ft_smooth_lcd_renderer_class
and ft_smooth_lcd_v_renderer_class
will have functions to init or create and destroy them
instead of being allocated in the global scope.
And macros will be used from ftspic.h in order to access
ft_grays_raster from the pic_container (allocated in ftgrays.c).
* src/smooth/ftgrays.h include FT_CONFIG_CONFIG_H
* src/smooth/ftgrays.c when FT_CONFIG_OPTION_PIC is NOT defined
func_interface was moved from gray_convert_glyph_inner function
to the global scope.
When FT_CONFIG_OPTION_PIC is defined
func_interface and ft_grays_raster structs
will have functions to init them
instead of being allocated in the global scope.
And func_interface will be allocated on the stack of
gray_convert_glyph_inner.
New Files:
* src/smooth/ftspic.h declare struct to hold PIC globals for smooth
renderer and macros to access them.
* src/smooth/ftspic.c implement functions to allocate, destroy and
initialize PIC globals for smooth renderer.
* src/smooth/smooth.c add new file to build: ftspic.c.
* src/smooth/jamfile add new files to FT2_MULTI build: ftspic.c.
Problem reported by Tavis Ormandy <taviso@google.com>.
* src/smooth/ftsmooth.c (ft_smooth_render_generic): Don't allow
`width' or `pitch' to be larger than 0xFFFF.
src/smooth/ftgrays.c, src/base/ftobjc.s, src/sfobjs.c:
s/_Err_Bad_Argument/_Err_Invalid_Argument/. The former is for
errors in the bytecode interpreter only.
extern const FT_Module_Class
(or similar for C++). However, the actual types of the variables
being declared are often different, e.g., FT_Driver_ClassRec or
FT_Renderer_Class. (Some are, indeed, FT_Module_Class.)
This works with most C compilers (since those structs begin with an
FT_Module_Class struct), but technically it's undefined behavior.
To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7
paragraph 2:
All declarations that refer to the same object or function shall
have compatible type; otherwise, the behavior is undefined.
(And they are not compatible types.)
Most C compilers don't reject (or even detect!) code which has this
issue, but the GCC LTO development branch compiler does. (It
outputs the types of the objects while generating .o files, along
with a bunch of other information, then compares them when doing the
final link-time code generation pass.)
Patch from Savannah bug #25133.
* src/base/ftinit.c (FT_USE_MODULE): Include variable type.
* builds/amiga/include/freetype/config/ftmodule.h,
include/freetype/config/ftmodule.h, */module.mk: Updated to declare
pass correct types to FT_USE_MODULE.
* include/freetype/internal/t1types.h (CID_FaceRec),
src/type42/t42types.h (T42_FaceRec): Comment out `afm_data'.
* src/smooth/ftgrays.c (gray_raster_render): Don't dereference
`target_map' if FT_RASTER_FLAG_DIRECT is set. Problem reported by
Stephan T. Lavavej <stl@nuwen.net>.
(FT_Outline_Decompose): Decorate with tracing messages.
* src/smooth/ftgrays.c [DEBUG_GRAYS]: Replace with
FT_DEBUG_LEVEL_TRACE.
[_STANDALONE_ && FT_DEBUG_LEVEL_TRACE]: Include stdio.h and
stdarg.h.
(FT_TRACE) [_STANDALONE_]: Remove.
(FT_Message) [_STANDALONE_ && FT_DEBUG_LEVEL_TRACE]: New function.
(FT_TRACE5, FT_TRACE7) [_STANDALONE_]: New macros.
(FT_ERROR) [_STANDALONE_]: Updated.
(gray_hline) [FT_DEBUG_LEVEL_TRACE]: Fix condition.
Use FT_TRACE7.
(gray_dump_cells): Make it `static void'.
(graay_convert_glyph): Use FT_TRACE7.
(FT_Outline_Decompose) [_STANDALONE_]: Synchronize with version in
ftoutln.c.
* src/base/ftadvanc.c (FT_Get_Advance, FT_Get_Advances): Use
FT_ERROR_BASE.
Other minor modifications.
encoded in UTF-16BE. Patch from Rajeev Pahuja <rpahuja@esri.com>.
(tt_name_entry_ascii_from_ucs4): Removed.
* include/freetype/ftxf86.h: Fix and extend comment so that it
appears in the documentation.
* include/freetype/ftchapters.h: Add `font_format' section.
* src/tools/docmaker/tohtml.py (HtmlFormatter::index_exit): Add link
to TOC in index page.
Formatting.
src/base/ftlcdfilt.c, src/smooth/ftsmooth.c: API change for
the LCD filter, the FT_LcdFilter value is a enum describing
which filter to apply, new values FT_LCD_FILTER_LIGHT and
FT_LCD_FILTER_LEGACY (the latter implements the LibXft original
algorithm which produces incredible color fringes for everything
except very-well hinted text)
* src/autofit/aflatin.c: various tiny improvements that drastically
improve the handling of serif fonts and of LCD/LCD_V hinting modes.
for an upcoming 2.2.2 release
* include/freetype/ftlcdfil.h, src/freetype/ftlcdfil.c:
added a new API to support color filtering of subpixel glyph
bitmaps. In default build, the function FT_Library_SetLcdFilter
returns FT_Err_Unimplemented_Feature; you need to #define
FT_CONFIG_OPTION_SUBPIXEL_RENDERING in ftoption.h to compile
the real implementation
* src/smooth/ftsmooth.c: adding support for sub-pixel color
filtering; simplifying a few function calls
* include/freetype/config/ftheader.h: adding FT_LCD_FILTER_H
macro that points to <freetype/ftlcdfil.h>
I. IMPORTANT BUG FIXES
- Various integer overflows have been fixed.
- PFB fonts with MacOS resource fork weren't handled correctly on
non-MacOS platforms.
- The PCF font loarder has been seriously hardened against malformed
font files.
II. IMPORTANT CHANGES
- the unpatented hinter is now part of the default build of the
library, and we added code to automatically support "tricky"
fonts that need it.
what this means is that FreeType should "just work" with certain
Asian fonts, like MingLiu, which cannot properly load without a
bytecode interpreter, but fortunately do not use any of the
patented bytecode opcodes.
Note that the API didn't change, so you can still force
unpatented hinting with a special parameter to FT_Open_Face
as well.
if you're an embedded systems developer, 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 reasons. 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 in this file
if you want to re-enable the feature.
the change only affects the implementation, not the FreeType API.
This means that clients don't need to be modified, because the
library still generates LCD decimated bitmaps, but with the added
constraint that R=G=B on each triplet.
- Some computation bugs in the TrueType bytecode interpreter were found,
which allow us to get rid of very subtle and rare differences we had
with the Windows renderer.
III. MISCELLANEOUS
- TrueType glyph loading is now about 25% faster.
- the anti-aliased rasterizer has been optimized and is now 15% to 25%
percent faster than the previous one, depending on content
- the Type 1 loader has been improved; as an example, it now skips
over top-level dictionaries properly
======================================================================
values which have the upper two bytes set to 0xFF instead of 0xFF
(as it happens in at least two CJKV fonts, `HAN NOM A.ttf' and
`HAN NOM B.ttf').
* src/smooth/ftgrays.c [GRAYS_USE_GAMMA]: Really remove all code.
Formatting.
