| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Addresses bug found in #624
|
|
|
|
|
|
|
|
| |
Set a size on the font description returned by
pango_font_describe(). Otherwise, scaling it
doesn't work.
Fixes: #610
|
| |
|
| |
|
|
|
|
|
|
|
| |
Originally suggested by Philipp Withnall in
https://bugzilla.gnome.org/show_bug.cgi?id=778655
Fixes: #268
|
|
|
|
|
| |
The g_memdup() function is replaced by a safer version in newer versions
of GLib.
|
|
|
|
|
|
|
| |
This was returning NULL for coretext fonts.
Good that we have tests for this.
Fixes: #524
|
|
|
|
|
| |
Since we've run out of slots in PangoFontClass,
this is implemented with a vfunc in PangoFontMapClass.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Setting font gravity to anything other than PANGO_GRAVITY_SOUTH causes
no fonts to be matched on Core Text backend because the code for finding
best match checks for equal gravity between the requested font and the
fonts in the font set, and the later always have PANGO_GRAVITY_SOUTH.
Hack around this by copying the gravity from the requested font.
Can be tested with:
$ pango-view --gravity=east --rotate=-90 utils/test-chinese.txt
Currently without this change it gives:
(pango-view:2824): Pango-WARNING **: 10:59:18.683: couldn't load font "serif Rotated-Left 12", modified variant/weight/stretch as fallback, expect ugly output.
(pango-view:2824): Pango-ERROR **: 10:59:18.683: Could not load fallback font, bailing out.
Trace/BPT trap: 5
|
|
|
|
|
|
|
|
|
| |
Alias names need to be inserted into the font map or otherwise will be
ignored and mapped to Sans (in pango_core_text_font_map_load_fontset()).
Furthermore, there is no font named ”San Francisco” on macOS, the actual
UI font is a hidden font called ”.SF NS Text” or something like that,
and there an “.AppleSystemUIFont” alias that should be used instead.
|
| |
|
|
|
|
|
|
| |
Patch by Alan Wang.
Closes: https://gitlab.gnome.org/GNOME/pango/issues/281
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug introduced from 633fd80.
With that changeset, if multiple fonts from the provided font family
are found, they are added to the start of fontset->fonts. Space for
the cascade list (based on the 'best'/first font) then follows.
However, pango_core_text_fontset_get_font_at was not updated to
match this change. So it still assumes that there is at most only
one 'real' font in fonset->fonts. With this assumption, the
indexing into fontset->cascade_list became incorrect, leading to
an out-of-bounds access on that list, resulting in an exception
being thrown.
Track the number of fonts found in pango_core_text_fontset_new
in real_fount_count, and use this as the offset into cascade_list.
This also fixes a memory leak; when a PangoCoreTextFontSet is
initialised, fonts and coverages are pre-initialised, but this
was being discarded and re-set in pango_core_text_fontset_new
without freeing the previous initialisation.
|
| |
|
|
|
|
|
|
|
| |
Fixes build error with default compilers on Mac OS X 10.6 and earlier:
pangocoretext-fontmap.c: In function ‘pango_core_text_fontset_new’:
pangocoretext-fontmap.c:1563: error: ‘for’ loop initial declaration used outside C99 mode
|
| |
|
|
|
|
| |
Fixes bug 787867.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cairo's CGFont backend already handles scaling fonts to the display
resolution, so scaling to the screen screen resolution in Pango's
CoreText backend generates double-sized text on a Retina display.
The layout test depended on providing a (bogus) resolution of 96DPI and
scaling the font to it in order to obtain the "expected" layout
results. This is replaced by adjusting the font size in test-layout.c
if Pango is compiled for CoreText.
https://bugzilla.gnome.org/show_bug.cgi?id=782393
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=770729
|
| |
|
|
|
|
| |
Fixes bug #750017
|
| |
|
|
|
|
|
|
|
| |
We use a compile-time check: if compiling for platforms 10.8 or higher,
use the public function, otherwise use the undocumented function.
Fixes bug 737813.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now shaper is discovered via (previously unused!) font->find_shaper().
I'm keeping that just to allow clients override shaping. Though,
even that I'm not sure we want to keep.
Wraps shaper in PangoEngineShape structs to keep PangoAnalysis API
intact.
Deprecated pango-modules.h and some pango-engine.h. Language modules
are not moved yet.
Wired up PangoFc, PangoWin32, and PangoCoretext shapers.
|
|
|
|
| |
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=734372
|
|
|
|
|
|
|
| |
Ensure that CFDictionaryGetValue() didn't return NULL before we
call CFNumberGetValue().
https://bugzilla.gnome.org/show_bug.cgi?id=736697
|
|
|
|
|
|
|
| |
We should interpolate. Added TODO. Don't have a coretext build so
don't want to break it.
Bug 733764 - Support more / free font weights
|
|
|
|
|
|
|
| |
This is needed as a base class sometimes needs to invalidate
the fontmap.
https://bugzilla.gnome.org/show_bug.cgi?id=694626
|
|
|
|
|
|
|
|
| |
This adds the pango_font_map_get_serial method that lets you see
if a fontmap has changes since the last check. It adds implementations
to all current fontmaps.
https://bugzilla.gnome.org/show_bug.cgi?id=340066
|
| |
|
| |
|
|
|
|
|
| |
Oversight in my fallback fix, this resulted in things being wrongly
destroyed due to unrefs. Oops.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The fallback failed when a "small caps" font was requested. This commit
improves the fallback support. When the first fallback, trying Sans with
the same style fails, we reset the variant, weight and stretch to
default values and try again. With Sans we should always be able to
adhere to the requested style.
Last but not least, output a sensible error message if all fallbacks
fail instead of simply crashing on a NULL pointer somewhere.
|
|
|
|
|
| |
Same fallback as already used in CoreText font descriptor to Pango
font descriptor conversion.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch written in collaboration with Michael Natterer.
Some CTFontDescriptors apparently do not have a style name or font
family name set. This patch makes the code take such corner cases into
account. The font family problem only appears to occur on Snow Leopard
systems, we try to fall back on the font name (postscript name), if that
fails, we fall back on a default fallback.
In some cases a coverage is also not set. (This seems to happen when we
cannot map a broken font back to a correct font descriptor). In such
cases we simply return an empty PangoCoverage, which will likely cause
the engine to fallback on a different font.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We implement font fallbacks by making use of
CTFontCopyDefaultCascadeList, a public, non-exposed, symbol in the
CoreText library. We might want to handle this differently.
The code now also uses a PangoCoreTextFontsetKey and
PangoCoreTextFontKey, similar to the font config backend. This has also
helped to clean up the code in general.
This patch contains two fixes by Michael Natterer:
1. Fix a bug in pango_core_text_font_key_equal() where the return value
of memcmp() was wrongly interpreted.
2. Cache PangoCoverage in PangoCoreTextFont.
|
|
|
|
|
|
|
|
|
|
| |
It turns out that getting this value as "Int" is incorrect and resulted
in font traits not being returned in some cases. Without traits, an
italic trait is not set, which caused synthetic oblique fonts to be
created when not necessary.
Also use CTFontSymbolicTraits type in the PangoCoreTextFace structure
and do a stricter bit mask check for certainty.
|
|
|
|
| |
Fix CoreText backend to not use the casefold string as family name.
|
|
|
|
|
| |
the conversion from the CFNumber with a mapping table in pango_core_test_face_from_ct_font_descriptor()
This assigns PangoWeights which better align with the CoreText weights and better ensures that unique values are used for hash keys used for determining which faces need synthetic italic faces created.
|
|
|
|
| |
and PangoCoreTextFaceClass so that it actually compiles.
|
| |
|
| |
|
|
|
|
|
|
| |
Deduce from the given style name whether a font is oblique. If a font
family does not have an italic or oblique variant, then add synthetic
italic variants that are handled by Pango.
|
| |
|
|
On Mac OS X systems where CoreText is available (that is, 10.5 or
higher), we will build the CoreText backend instead of the ATSUI
backend. In this case, the ATSUI backend will not be built and
installed. This change is necessary because since Mac OS 10.5
ATSUI has been marked as deprecated.
For older systems, we will have to continue to use the
ATSUI backend.
|