| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Watcom C compiler does not recognize typedef-only code as something valid.
|
|
|
|
| |
Watcom C compiler refuses too huge structure type > 64k.
|
|
|
|
| |
because it is always false on 16bit & 32bit systems.
|
|
|
|
| |
ft_mem_primes[] is originally typed to FT_Int, it could not track the memory allocation on 16bit (I16-LP32) system.
|
| |
|
|
|
|
| |
and MD5_u32plus is changed from unsigned int to FT_UInt32.
|
|
|
|
| |
due to the limitation that internal face_index is typed int.
|
| |
|
|
|
|
|
|
|
|
| |
bias calculation is expected to be ILP32, LP64 or LLP64 systems (int = 32bit).
Some internal variables and internal APIs are extended to use 32bit type for 16bit systems.
Using long type is too large on LP64 systems,
and induces the incompatible change of the internal API for 32bit systems,
it should be avoided.
|
|
|
|
| |
note: long constant is too large for LP64 platforms.
|
|
|
|
| |
because it is always false on 16bit systems.
|
|
|
|
|
|
| |
induce an overflow.
Change to make 32bit value by bitshifting and cast to 16bit in later.
|
| |
|
|
|
|
| |
always false on 16bit system.
|
|
|
|
| |
note: long constant is too large for LP64 platforms.
|
|
|
|
| |
note: long type is too large for LP64 platforms.
|
|
|
|
| |
note: long constant is too large for LP64 platforms.
|
| |
|
| |
|
| |
|
|
|
|
| |
16bit system.
|
|
|
|
| |
unix-watcom16.mk: cross build by Watcom C compiler on Linux.
|
|
|
|
| |
enumarator.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Improve the code by 5d3ff05615dda6d1325ed612381a17a0df04c975 ,
issues are found by Behdad Esfahbod and Werner Lemberg.
* src/cache/ftcbasic.c (FTC_ImageCache_Lookup): Replace
a subtraction to check higher bit by a bit operation,
and cpp-conditionalize for appropriate systems. Add better
documentation to the comment.
(FTC_ImageCache_LookupScaler): Ditto.
(FTC_SBitCache_Lookup): Ditto.
(FTC_SBitCache_LookupScaler): Ditto.
|
|
|
|
|
| |
* src/autofit/aflatin.c (af_latin_hints_compute_segments): Set
`segment->delta' everywhere.
|
|
|
|
|
|
|
|
| |
* src/autofit/afshaper.c: Include FT_ADVANCE_H, to use
FT_Get_Advance() in it.
* src/sfnt/ttcmap.c: Include FT_SERVICE_POSTSCRIPT_CMAPS_H
to use PS_Unicodes in it, also include `ttpost.h' to use
tt_face_get_ps_name() in it.
|
|
|
|
|
| |
* builds/windows/vc2010/freetype.vcxproj: Switch platform toolset
according to the Visual Studio version.
|
|
|
|
| |
Reported by Behdad.
|
| |
|
| |
|
|
|
|
|
| |
* src/autofit/afhints.c (af_glyph_hints_get_segment_offset):
Provide values in font units.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
LastResort.dfont has a marginal resource ID 0xFFFF for sfnt
resource. Inside Macintosh: More Macintosh Toolbox, `Resource IDs'
(1-46), tells that some IDs are reserved and should not be used.
FreeType2 just uses resource ID to sort the fragmented resource.
To accept the marginal fonts, the checking is removed.
* src/base/ftrfork.c (FT_Raccess_Get_DataOffsets): Remove res_id
validity check, fix a trace message format.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first 32bit of standard TrueType variants is 0x00010000,
`OTTO', `ttcf', `true' or `typ1'. 2 marginal dfonts on legacy Mac
OS X, Keyboard.dfont and LastResort.dfont, have the sfnt resources
starting 0xA5 followed by `kbd' or `lst'. Considering the following
data could be parsed as conventional TrueType fonts, the header
checking is updated to allow these tags. It seems that recent Mac
OS X has already switched to normal TTF for these fonts.
See the discussion at
http://u88.n24.queensu.ca/exiftool/forum/index.php?topic=3931.0
* include/freetype/tttags.h (TTAG_0xA5kbd, TTAG_0xA5lst): New header
tags for Keyboard.dfont and LastResort.dfont.
* src/sfnt/sfobjs.c (sfnt_open_font): Accept the sfnt resource
starts with TTAG_0xA5kbd or TTAG_0xA5lst.
* src/truetype/ttobjs.c (tt_face_init): Accept the face with the
format tag is TTAG_0xA5kbd or TTAG_0xA5lst.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The documentation of `FT_Bitmap_Convert' says that multiple calls do
proper reallocation of the target FT_Bitmap object. However, this
failed for the sequence
non-empty bitmap
empty bitmap
non-empty bitmap
Reason was that `FT_Bitmap_Convert' only reallocated the bitmap
buffer if it became too small; it didn't make the buffer smaller.
For an empty bitmap following a non-empty one, only the buffer
dimension got set to zero, without deallocation. If the next call
was a non-empty buffer again, an assertion in `ft_mem_qrealloc' was
triggered.
* src/base/ftbitmap.c (FT_Bitmap_Convert): Always reallocate target
buffer to the correct size.
* docs/CHANGES: Document it.
|
|
|
|
|
|
|
|
| |
* src/bdf/bdfdrivr.c (BDF_Face_Init): Use `SIZE' values if
`POINT_SIZE', `RESOLUTION_X', or `RESOLUTION_Y' properties are
missing.
* docs/CHANGES: Document it.
|
|
|
|
|
|
| |
* src/base/ftbitmap.c (ft_bitmap_assure_buffer): Updated.
* src/winfonts/winfnt.c (FNT_Load_Glyph): Updated.
* src/raster/ftrend1.c (ft_raster1_render): Updated.
|
| |
|
|
|
|
|
|
|
| |
* src/sfnt/pngshim.c (premultiply_data): Use vectors instead of
scalars.
(vector_shuffle): New macro to take of a different built-in function
name on clang.
|
|
|
|
|
|
|
| |
Patch applied from bug report.
* src/base/ftutil.c (ft_mem_qrealloc): Use low-level allocation to
avoid unnecessary overhead.
|
|
|
|
|
|
|
|
|
| |
Changes triggered by
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3107
* src/truetype/ttinterp.c (Ins_MDRP, Ins_MIRP, Ins_ALIGNPTS): Use
NEG_LONG.
|
|
|
|
|
|
|
|
| |
Reported as
https://bugs.chromium.org/p/chromium/issues/detail?id=754574
* src/sfnt/sfobjs.c (sfnt_load_face): Check for FT_ENCODING_MS_SYMBOL.
|
| |
|
|
|
|
|
|
|
|
| |
This reduces the overhead of `premultiply_data' by 60%.
* src/sfnt/pngshim.c (premultiply_data): Provide code which uses
gcc's (and clang's) `vector_byte' attribute to process 4 pixels at a
time.
|