| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the same change that was made for pangocairo earlier.
Without this, the pc file contains the following requires line:
```
Requires: pango,
```
Which is incorrect, and also invalid.
|
|
|
|
| |
Fixes https://gitlab.gnome.org/GNOME/pango/-/issues/719
|
|
|
|
|
| |
A gunichar is a scalar value, and it doesn't get allocated when used as
an out argument.
|
|
|
|
|
|
|
|
|
|
|
|
| |
When dealing with multi-paragraph layouts,
the char offsets of the items are expected
to be relative to the beginning of the text,
not relative to the beginning of the current
paragraph.
This error was introduced in a03bf5bc6b07ba6e.
Fixes: #716
|
|\
| |
| |
| |
| | |
Fix some g-i annotations related to arrays
See merge request GNOME/pango!655
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Document the format, and improve the parser a bit,
so we can use this format in GtkBuilder.
Update affected tests.
|
|/ |
|
|\
| |
| |
| |
| |
| |
| | |
Windows: Fix builds using HarfBuzz as subproject
Closes #707
See merge request GNOME/pango!649
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It turned out that there were issues in regards to building HarfBuzz as
a fallback dependency, so we retain using only the former method to
create the hb_face_t using only raw data, which does not depend on
platform API usage in HarfBuzz.
Hence, reduce the clutter in the build files a bit, which was a
necessary evil back in time.
This reverts commit 6b0aa77d23ac969c12eab00b178957a63befe5bd.
|
|\ \
| |/
|/|
| |
| | |
Fix GIR annotations
See merge request GNOME/pango!651
|
| | |
|
| |
| |
| |
| |
| |
| | |
In practice, only Windows doesn't have these,
so simplify our meson.build file by dropping
the check for flockfile.
|
|/
|
|
| |
Annotations are picky about :
|
|\
| |
| |
| |
| | |
Pango-1.x: Add some DirectWrite support as a supplement
See merge request GNOME/pango!635
|
| |
| |
| |
| |
| |
| | |
The recent additions to this file must be updated so that this header can be
successfully consumed when building in C++ mode, i.e. with DirectWrite. Cast
items as needed.
|
| |
| |
| |
| |
| |
| |
| | |
Use the DirectWrite and/or GDI APIs in HarfBuzz to create the hb_font_t's that
we need, if they are available in HarfBuzz. Use the former raw-data method
if neither are available, or if using DirectWrite failed and GDI support is
not available.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
...if Cairo is built with DirectWrite support. With this, we can
support colored Emoji, a long-standing issue, on Windows without needing
to use FontConfig, on Windows 8.1 or later, since DirectWrite added support
for colored Emoji starting with Windows 8.1.
This will really fix issue !302 completely, regarding the Emoji not
shown in color!
|
| |
| |
| |
| |
| |
| | |
...which is needed for PangoCairo for Windows, when DirectWrite is used to
create the cairo_font_face_t, so that that object does get cleaned up when the
cairo_font_face_t is destroyed.
|
| |
| |
| |
| |
| |
| |
| | |
This moves some items under PangoWin32 in the DirectWrite support to
simplify acquiring the DirectWrite font face that is needed for various
operations, as we will need to do this in PangoCairo in the Windows
support.
|
| |
| |
| |
| |
| | |
This will be carried out by various functions, so we want to reuse
things.
|
| |
| |
| |
| |
| |
| |
| |
| | |
... by querying the font table 'gasp' and see whether the bits needed
for hinting are there. Codewise, it is simpler with GDI+, but it would
then require more overhead since GDI(+) operations are needed (this means
"slower") and we need to put boilerplates for using GDI+ from our
plain-C code.
|
| |
| |
| |
| |
| |
| |
| | |
Extend the support to use DirectWrite to query the font descriptions from
LOGFONTA's, by using a temporary LOGFONTW which uses the UTF-16'fied
facename converted directly using g_locale_to_utf8 (), since DirectWrite
expects us to use LOGFONTW's for its GDI interop operations.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We now use DirectWrite to query the font weight, stretch, description
and so on by using first DirectWrite's GdiInterop to convert the
logfontw into an IDirectWriteFont, since the support in there for
querying font attributes are more complete in there. Take out the
warned fonts items, as DirectWrite would support the font attributes
that we need much better (i.e. stretch and so on), and the warned fonts
items will get into the way.
Portions based on Luca Bacci's work for querying the font description
for Windows using DirectWrite for the upcoming Pango2.
|
| |
| |
| |
| |
| |
| |
| | |
...if we have Windows 7 with the platform update (which is normally the
case), otherwise we fallback to former GDI approach, since we need to
use the IDWriteFont1 interface that is only available with updated
Windows 7.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
...instead of using EnumFontFamiliesEx(), and retrieve the LOGFONTW's that we
need via DirectWrite's GDI interop. Also cache up our IDWriteFont's that we
obtained, so that we can use DirectWrite to query font properties better
than what GDI/Uniscribe can do for us, such as obtaining stretch info from
the font. Also update synthesize_foreach() accordingly, since we should
also record the IDWriteFonts as well for synthesized LOGFONTWs.
Portions based on Luca Bacci's implementation of the DirectWrite fontmap
support in the upcoming Pango2.
|
| |
| |
| |
| |
| | |
We set up the boilerplate that is necessary for using DirectWrite in our code.
Also add code to tear it down after we are done with it.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
...in Cairo, as well as their presence in the Windows SDKs (which should
always be there in the Windows SDKs). We want to use items in DirectWrite
to help us improve support on Windows regarding looking up for features
(description) of a font.
Since upstream Cairo gained DirectWrite support very recently, check for
it only via pkg-config, since Cairo had Meson build support quite a bit before
that happened.
|
|\ \
| | |
| | |
| | |
| | | |
Fix GIR annotations in multiple files
See merge request GNOME/pango!648
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Fix GIR annotations for fonts.c
See merge request GNOME/pango!647
|
| |/ / |
|
|/ / |
|
| | |
|
| | |
|
| |
| |
| |
| | |
See #705 and also https://gitlab.gnome.org/GNOME/gtk/-/issues/5226.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We accept NULL for log_attrs, so we should not
crash when we are given NULL. While fixing this,
clarify the documentation of the various shaping
APIs for what they can and cannot do.
Related: !641
|
| |
| |
| |
| |
| |
| | |
Make the serializer only serialize the
font of a layout if it is not NULL. This
lets us survive no-fonts situations better.
|
|/
|
|
|
|
|
|
| |
Make pango_font_get_scale_factors return 1
if the font is NULL. This avoids crashes
in situations where we cannot find any fonts.
Fixes: #701
|
|
|
|
|
|
|
|
| |
We were using the font metrics height, which is
scaled by the ctm, so we need to take the font
scale factors into account here.
Fixes: #691
|
|
|
|
|
| |
This avoids the unnecessary copy of the fonts
font description, just to extract the variant.
|
|
|
|
|
|
| |
Add a private pango_font_get_variant, and implement
it for PangoFcFont. This will let us avoid many
pointless font description copies.
|
|
|
|
|
|
|
|
| |
When we create a PangoFcFont from an FcPattern,
we know that the pattern will live as long as
the font and the font description we create
at the same time. So there is no need to copy
the strings we get out of the pattern.
|
| |
|
|
|
|
|
| |
It seems odd to document PANGO_WEIGHT_MEDIUM as the 'normal'
weight, when we also have PANGO_WEIGHT_NORMAL.
|
|
|
|
|
|
|
| |
We only want line separators at the line end
to be visible when the show flags say so. This
was not working before, because the shaping always
marks LS as unknown glyph.
|
|\
| |
| |
| |
| | |
Fix typo in declaration of PangoEngineShape
See merge request GNOME/pango!629
|
| | |
|
| |
| |
| |
| |
| | |
This is necessary to make GListModel show up
as implemented interface in the docs.
|