| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Bug 605870 - Incorrect shaping for Syriac
|
|
|
|
| |
Bug 457990 - font metrics are not converted to user space in cairo backend
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
ValueRecords
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
In case they are write protected for some reason. Might help Behdad's
problem with make dist.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
pango_atsui_font_map_load_font() has been corrected to take into account
whether the size retrieved from the given font description is absolute
when setting this size again on best_description.
_pango_cairo_atsui_font_new() has been cleaned up with regard to size
conversion and usage. The code now properly takes the absolute property
into account and is more clear.
|
|
|
|
| |
It has to be possible to run "make dist" also in an unpacked tarball.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A couple bugs joined forces to exhibit the mystery behavior of
crashes / infinite loops on OS X / wrong kerning / invalid memory
access. Pooh!
The bugs were involved:
- Wrong pointer math with ValueRecord in PairPosFormat1
- Fallout from avoiding flex arrays, code not correctly updated
to remove sizeof() usage.
We strictly never use sizeof() directly now. And the PairPos code
is cleaned up. Should fix them all. Bugs are:
Bug 605655 - Pango 1.26.2 introduces kerning bug
Bug 611229 - Pango reads from uninitialized memory
Bug 593240 - (pangoosx) Crash / infinite loop with Mac OS X
We were also doing wrong math converting Device adjustments to
hb_position_t. Fallout from FreeType days. Should shift 16, not
6. Fixed that too.
There's still another bug: we don't sanitize Device records
referenced from value records. Fixing that also.
|
| |
|
|
|
|
|
| |
Put the PANGO_MODULE_PREFIX defines in the project files instead of
having them behind an ifdef in the source files.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The VS files are kept in build/win32/vs9, the same relative location
as in GLib, mostly for historical reasons.
Update README.win32 to reflect the VS possibility.
Include the VS solution and project files in the tarball when doing a
release.
To avoid having to list source files in several locations, generate
files listing source files at "make dist" time in the corresponding
source directories. Use the C preprocessor to preprocess .vcprojin
files that include said list files into the actual .vcproj project
files.
Provide a rc file for the pangocairo DLL, too.
Construct and provide in the tarball a pregenerated config.h.win32
which can be used as config.h when building with Visual C without
running any configure script. Provide pregenerarated
module-defs.h.win32, module-defs-lang.c.win32 files too.
Define PANGO_MODULE_PREFIX appropriately in the relevant module source
files if not available from the compilation command line.
Update module-defs-fc.c.win32 and module-defs-win32.c.win32 to match
what the configure script provides.
|
| |
|
|
|
|
| |
Random character class changes... It's all Chinese to me.
|
| |
|
|
|
|
| |
Check for face->stream->read == NULL instead of face->stream->base != NULL.
|
|
|
|
| |
Bug 604128 - Applications crash when displaying Hebrew characters
|
|
|
|
|
|
| |
I am not sure whether the root cause is a bug in FreeType, or the way
Pango uses FreeType, or some more exotic mechanism. Anyway, add a
simple workaround.
|
|
|
|
|
|
| |
Fix the basic ATSUI to probably work on 64-bit Snow Leopard. The main
culprit was most probably in the usage of CGFontRef, where ATSUFontID
was expected.
|
|
|
|
| |
Hookup new symbol.
|
| |
|
|
|
|
| |
Bug 593240 - (pangoosx) Crash / infinite loop with Mac OS X
|
| |
|
|
|
|
| |
Disable some __attribute__s with gcc 3.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Since it breaks when using a system install of gobject-introspection
|
| |
|
|
|
|
|
| |
Before we only did this if justifying. However, computing the width is
essentially free these days, so do it always.
|
|
|
|
|
|
|
|
|
| |
Previously we were not zeroing the final space in the line when breaking
lines and were doing that only after lines were broken. This was broken
since setting layout width to its own logical width (under width=-1) could
result in differently broken lines. That's fixed now.
Problem originally reported on gtk-list on 2009-12-22 by Ben Pfaff.
|
| |
|
| |
|