The Osaka font on macOS has all zeroes in the OS/2 table, probably
because it is not intended to be cross-platform. In Qt 6 (since
f761ad3cd9) we are trying using the
same vertical metrics on all platforms, but this only works if
they are valid.
To work around this issue, we detect the case when ascent/descent
values are both 0, since this is very unlikely to be intentional,
so we fall back to the system-provided ascent and descent in these
cases.
Adding the test also revealed that we had missed the check for
a macOS-specific bitmap font format when skipping the check for
bitmap fonts in 7a18b7e2c2.
[ChangeLog][macOS][Text] Fixed a problem where using the Osaka
font would lead to overlapping text.
Pick-to: 6.2
Fixes: QTBUG-96880
Change-Id: Ifea7918641a68829e8f5ef20a4fb61c0a7e5b757
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Unify the logic in QTextEngine
Ensure tightBoundingRect, and the FreeType boundingRect, calculates from
the shaped x offset when calculating the max x coordinate for a glyph.
Fixes: QTBUG-7768
Task-number: QTBUG-70184
Task-number: QTBUG-85936
Task-number: QTBUG-94023
Change-Id: I6daafb25c79158dc7e777529abb5e8d3a284dac0
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
When we are unable to get the line thickness from a font, we
fall back to calculating this based on pixel size and weight.
But the font weight scale has changed in Qt 6, causing the
calculated font weight to be 10x as thick as it should.
This happened e.g. for Titillium Web, but only when using 100%
UI scaling, because the GDI engine was unable to get the correct
line thickness from the font, whereas the DirectWrite engine
succeeded.
[ChangeLog][Windows] Fixes an issue where underlines and other
decorations would be too thick for some fonts.
Pick-to: 6.1 6.2
Fixes: QTBUG-94529
Change-Id: Id2c88f0a145776151be0399ee646f28b3bdf9072
Reviewed-by: Thomas Hartmann <thomas.hartmann@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
For some use cases, vertical subpixel positioning may be
useful, as it allows you to vertically align text with
other painting primitives. This does impose an overhead,
so we make it opt-int with a render hint on the painter.
Note that this is only supported on Freetype currently.
It might be possible to support on older macOS versions,
prior to Mojave (which has disabled subpixel positioning
entirely), but since it would have limited usefulness
and Freetype is cross-platform anyway, I skipped that.
Note: This drive-by-fixes an issue with subpixel
positioning where glyphs would always be offset by 1/64,
because we added the aliasing offset *after* we had
determined the closest subpixel position. The idea of
this, as far as I can understand, is rather to snap to
nearest subpixel position upwards, not to add an offset
to all glyphs, so it should be added before finding the
correct position. It had a subtle visual effect when
animating the position. It might be that we could get
rid of it entirely, as I haven't been able to reproduce
any issues with that, but I have moved it instead, to
match what I believe the intention was.
[ChangeLog][QtGui][Text] Added render hint flag
QPainter::VerticalSubpixelPositioning which will position
text at subpixel positions vertically whenever supported.
In absence of this, text position will be rounded
vertically as before.
Fixes: QTBUG-35682
Change-Id: I8ce7a72a64e5a0924dac7c244e3e07c2938bfd09
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
By depending on setFamilies() then we can be sure that font names with
spaces, commas, quotes and so on are correctly handled without being
misinterpreted. For now it will split on the comma when a string
containing one is passed to setFamily. But from Qt 6.2 this will be
removed to preserve the family string as a convenience function.
[ChangeLog][QtGui][QFont] Indicated that setFamilies/families is
preferred over setFamily/family to ensure that font family names are
preserved when spaces, commas and so on are used in the name.
Change-Id: Id3c1a4e827756a4c928fed461a4aafa5a0f06633
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Since 066daf750f, we would mistakenly populate the
fallback list for all ensureAt(index) calls, even when index == 0. This index
indicates the main font, is always valid and does not require knowledge of any
fallbacks.
On Windows (and other platforms where QPlatformDatabase::fallbacksForFamily() is used)
this would cause all fonts on the system to be loaded and should only be done when
we actually need one of the fallbacks.
With the GDI font database, in which font loading is slow because we have to manually
read font data, this is especially bad. If we can later move to using DirectWrite
for this, we should be able to improve on it, but in any case there is no need to
pay the cost of the fallbacks when the application is just using the fonts it has
selected (memory-wise this is also a bad idea). On my machine a simple text layout
went from 370 ms to 37 ms.
[ChangeLog][Text] Fixed an issue where on some platforms, there would be a delay the
first time any font was used, sometimes causing a visible delay in the UI.
Fixes: QTBUG-71737
Pick-to: 5.15
Change-Id: Ie8ce9b73f02a0e5cf39a2b280968b89f4caaf39e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
The box font engine was passing in alpha values in the blue
channel instead of alpha channel to QImage::setPixel(), probably
assuming that setPixel() accepts the input in the format of the
QImage. But the whole point of setPixel() is that it converts
the input. If we just want to set the alpha value, we can do
it directly on the QImage::bits().
[ChangeLog][Text] Fixed showing boxes for glyphs when there are
no fonts available in the font database.
Pick-to: 5.15
Change-Id: I7ae067c26b9ecba6aaa046e7e4b9ae520c4b3d23
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Glyph index 0 is reserved for "glyph not found", which can
confuse Harfbuzz. For QFontEngineBox we always return a valid
glyph since it is the fallback font when no other fonts are
available.
Symptom of issue was that we could get to Q_UNREACHABLE for
certain strings when Harfbuzz returned a glyph count of 0.
[ChangeLog][QtGui] Fixed a potential crash when rendering text
with an empty font database.
Fixes: QTBUG-85016
Pick-to: 5.15
Change-Id: Iaf1d003cdff57320bf4327aa8e63dffd9d1da82c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
On FreeType font engine this results in a call to FT_Load_Sfnt_Table
with a pointer to an uninitialized value passed in as FT_ULong* length,
crashing. Instead initialize value to 0.
Change-Id: I50d6df3b2296a05640d939e862bc50adb0fec921
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
(cherry picked from commit e041f5459660eaa7108fa5888e77e64f7d1b3d1d)
This is in accordance to the examples from harfbuzz docs:
https://harfbuzz.github.io/ch03s03.html
The fix is because `pkg-config --cflags harfbuzz` returns
the subdirectory as include path, for example:
-I /usr/local/include/harfbuzz
and this caused the system-harfbuzz not to be found when
/usr/local/include was not included by default (recent change on
macOS) and the code was doing #include <harfbuzz/hb.h>.
Fixes: QTBUG-85568
Change-Id: I12a34638e8ad5e3085768828457f0bfa1a2c68ad
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
This is required to remove the ; from the macro with Qt 6.
Task-number: QTBUG-82978
Change-Id: I3f0b6717956ca8fa486bed9817b89dfa19f5e0e1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Conversions from non-char-types to QChar are going to be deprecated.
Use QChar::fromUcs2(), fromUcs4(), QLatin1Char(), or convert the
constructor argument to char16_t.
Change-Id: Ib45ebd5560aa3a2bc460037ab09773607485c6e2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
For fonts with embedded bitmaps, we cannot trust the HHEA and
OS/2 tables, since there are a different set of font metrics
in the EBLC/CBLC tables for each of the predefined bitmap
sizes.
In this case, we can safely fall back to the metrics returned
by the system, as the inconsistency we were originally fixing
was only between OS/2 and HHEA and will not matter for the
bitmap fonts.
This patch also simplifies the code path through the font
engines a bit. Instead of setting the system metrics in the
processHheaTable() function when the table cannot be found,
we instead always fetch the system metrics at the very start
of initializeHeightMetrics() and then override if there are
no embedded bitmaps, and if the HHEA and OS/2 tables are
available. This also reduces the number of virtual functions
needed to sort out the height metrics.
Fixes: QTBUG-83754
Change-Id: Ib9dc6fc6cf972e48209a4a272469d2b4bd1ebffe
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
They were masked by all QChar ctors being made explicit, except the
char16_t one, which was left as the only viable choice.
Change-Id: I343269b61d555c259b5780011e99f85f5375ef78
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Qt assumes that ascent+descent is the bounding height of the
text, but for historical reasons, the ascent for some fonts
will not contain the diacritics. On Windows, the preference
is to use data from the OS/2 table which were explicitly
invented to work around this, but on other platforms we
are not respecting this table. This causes a text layout
that looks fine on Windows to have overlapping characters
on e.g. macOS.
To make vertical metrics (ascent, descent, leading) consistent
across all platforms, we don't blindly trust the values we get
from the underlying font system, but apply in the following order:
1. If OS/2 table exists and USE_TYPO_METRICS flag is set, we
use the typo metrics from OS/2 table
2. If OS/2 table exists and USE_TYPO_METRICS flag is not set,
we use winAscent/winDescent from OS/2 and the line gap from
HHEA table.
3. If no OS/2 table exists, we try to get ascent, descent and
line gap from the HHEA table.
4. If the HHEA table does not exist (not an SFNT), we fall back
to the system-provided metrics. (on macOS, we know the
system-provided metrics will match the data in HHEA, so we
skip parsing that table and use the data from CoreText if
there is no OS/2 table).
Task-number: QTBUG-80554
Change-Id: I41e6561a99513698c8e42451b4ec98bd5eb6892f
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Fix some warnings that are flagged as errors on clang10.
Change-Id: I906634c8b2bd94db42d74a7f3d10efb086e373cc
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Conflicts:
examples/opengl/doc/src/cube.qdoc
src/corelib/global/qlibraryinfo.cpp
src/corelib/text/qbytearray_p.h
src/corelib/text/qlocale_data_p.h
src/corelib/time/qhijricalendar_data_p.h
src/corelib/time/qjalalicalendar_data_p.h
src/corelib/time/qromancalendar_data_p.h
src/network/ssl/qsslcertificate.h
src/widgets/doc/src/graphicsview.qdoc
src/widgets/widgets/qcombobox.cpp
src/widgets/widgets/qcombobox.h
tests/auto/corelib/tools/qscopeguard/tst_qscopeguard.cpp
tests/auto/widgets/widgets/qcombobox/tst_qcombobox.cpp
tests/benchmarks/corelib/io/qdiriterator/qdiriterator.pro
tests/manual/diaglib/debugproxystyle.cpp
tests/manual/diaglib/qwidgetdump.cpp
tests/manual/diaglib/qwindowdump.cpp
tests/manual/diaglib/textdump.cpp
util/locale_database/cldr2qlocalexml.py
util/locale_database/qlocalexml.py
util/locale_database/qlocalexml2cpp.py
Resolution of util/locale_database/ are based on:
https://codereview.qt-project.org/c/qt/qtbase/+/294250
and src/corelib/{text,time}/*_data_p.h were then regenerated by
running those scripts.
Updated CMakeLists.txt in each of
tests/auto/corelib/serialization/qcborstreamreader/
tests/auto/corelib/serialization/qcborvalue/
tests/auto/gui/kernel/
and generated new ones in each of
tests/auto/gui/kernel/qaddpostroutine/
tests/auto/gui/kernel/qhighdpiscaling/
tests/libfuzzer/corelib/text/qregularexpression/optimize/
tests/libfuzzer/gui/painting/qcolorspace/fromiccprofile/
tests/libfuzzer/gui/text/qtextdocument/sethtml/
tests/libfuzzer/gui/text/qtextdocument/setmarkdown/
tests/libfuzzer/gui/text/qtextlayout/beginlayout/
by running util/cmake/pro2cmake.py on their changed .pro files.
Changed target name in
tests/auto/gui/kernel/qaction/qaction.pro
tests/auto/gui/kernel/qaction/qactiongroup.pro
tests/auto/gui/kernel/qshortcut/qshortcut.pro
to ensure unique target names for CMake
Changed tst_QComboBox::currentIndex to not test the
currentIndexChanged(QString), as that one does not exist in Qt 6
anymore.
Change-Id: I9a85705484855ae1dc874a81f49d27a50b0dcff7
as we raised the minimum requirement for harfbuzz to version 2.6.0:
* use new HB_SCRIPT values instead of tags
* get rid of deprecated (and no-more-used) callbacks
* replace deprecated hb_ot_tags_from_script() usage with a more
flexible and up-to-date hb_ot_tags_from_script_and_language()
Change-Id: I0eafdd2d2028c353fa3a93f5868efceccd364a70
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Harfbuzz supports this in a cross platform way, so there's no
reason not to accept a font with AAT tables on other platforms.
Change-Id: I00c38a11dfd4a32e846254c1da9e8841090f5fd9
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Freetype can give us non empty bounds for zero-width characters,
this change just makes us skip metrics of characters already found to
not contribute to text advance. The coretext and windows
font-engines already uses the already calculated advance.
Change-Id: I82b3521a4fb92614be509be5982cd5ab9c1eb7de
Fixes: QTBUG-58854
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Goes through the Qt code and make sure bytes-per-line calculations are
safe when they are too big for 32bit integers.
Change-Id: I88b2d74b3da82e91407d316aa932a4a37587c0cf
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Move away from using 0 as pointer literal.
Done using clang-tidy. This is not complete as
run-clang-tidy can't handle all of qtbase in one go.
Change-Id: I1076a21f32aac0dab078af6f175f7508145eece0
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Amends qtbase/af2daafde72db02454d24b7d691aa6861525ab99.
Where applicable, port over to member initialization, thus also
fixing nullptr warnings.
Change-Id: Iaaf2dbbbcf2952253390b8839fd15a1b17be32c0
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
This was used to support QFlags f = 0 initialization, but with 0 used
as a pointer literal now considered bad form, it had been changed many
places to QFlags f = nullptr, which is meaningless and confusing.
Change-Id: I4bc592151c255dc5cab1a232615caecc520f02e8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Simply return a Glyph pointer and not a QImage to avoid allocating and
deleting lots of d pointers for QImage when drawing text. Saves one
new/delete pair per glyph drawn and speeds up text drawing by 10% for
relatively large glyphs (probably more for smaller ones).
The qtext::paintLayoutToPixmap() benchmark shows a 16% improvement
in performance with this change.
Renamed the method to glyphData().
Change-Id: I7a353de521e4f4321c770fb1ac6043d33f6f332c
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Conflicts:
configure.pri
Also required s/solid\.color/solidColor/ in a couple of places in:
src/gui/painting/qpaintengine_raster.cpp
Change-Id: I29937f63e9779deb6dac7ae77e2948d06ebc0319
Color fonts may also contain regular alphabet characters that
should be rendered with the current pen. In Qt, however, these
characters were drawn into the cache with a default pen color
of black.
Since all characters in a font is currently backed by the same cache,
and it would require a lot of plumbing to get around this, a step
in the right direction is to include the current pen color in the
cache as long as it is an RGB cache. This means that drawing
text with the color font with different pen colors will create
different caches.
There is no API to select font color on Freetype currently, but
this problem has also not been observed there, as the fonts
in question, with both regular and color glyphs, are not being
detected as color fonts (so the text color will be correct).
So Freetype will be left out for now.
[ChangeLog][QtGui][Text] Fixed bug where regular text rendered
with a color font would always display in black.
Task-number: QTBUG-55096
Task-number: QTBUG-74761
Change-Id: Icc7dbf73241db1e7cc6a0de18c2de927aeecf713
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Replace null and '\c nullptr' with \nullptr in the documentation.
Change-Id: I58934eea06943309ba895833f1991629870ab45b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
In 3ccdeb4b58, we removed the
specialized multi font engine on Windows, causing us to go
through the same code path when loading fallbacks as on
other platforms.
When combined with 97f73e9577,
this caused an error, because the code in
QFontEngineMulti::loadEngine() only overrode the families
list, but not the singular family in the request. In the
QRawFont test, this would cause the requested fallback font
to correctly have "MS Shell Dlg2" as the only font in the
families list, but the request.family would still be
"QtBidiTestFont", the name of the main font. The singular family
in the request was preferred by the windows font database when
creating the LOGFONT. We would therefore load the latter for
the fallback as well and since it still does not support the
characters in question, we would continue searching.
Fixes: QTBUG-72836
Change-Id: I1787b57febcf6030d5c5b09bc2ef2c9558f05beb
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
It's a leftover from when the Cocoa plugin used QFontEngineMulti
exclusively. Nowadays QFontEngineMulti will strip out the highByte
before calling into the real engine. Left an assert just in case..
Change-Id: I6cb26d20a908d7c3aaf096297fca160805fdb85b
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Since the comma character was originally used as a separator, we
need to extend QFont to have setFamilies() so that we can avoid
joining the family strings together. This enables us to see the
family name as a single string and for multiple family names,
we have families().
Subsequently, this has added functions to QTextCharFormat to
account for multiple font families too. So it is now possible to
set a single one directly with setFontFamily() and multiple ones
with setFontFamilies().
This also bumps up the datastream version to 19 as QFont now
streams the families list as well.
[ChangeLog][QtGui][QFont] Add setFamilies()/families() to aid using of font families with commas and quotes in their name.
[ChangeLog][Important Behavior Changes] QDataStream version bumped up to 19 to account for changes in the serialization of QFont.
Fixes: QTBUG-46322
Change-Id: Iee9f715e47544a7a705c7f36401aba216a7d42b0
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The script taken here is a QChar::Script, not a
QFontDatabase::WritingSystem. This means it was passing QChar::Unknown.
Change-Id: I919ae7187ba277346a7719116a94776dce24dd84
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
When building with warnings are errors for Android with gcc 4.9,
it wrongfully fails on use of uninitialized variable.
Change-Id: I39c5e8413c30567fba60cbba6a8b26d537c5836e
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Eskil Abrahamsen Blomfeldt
Allan Sandfeld Jensen
Andy Shaw
Zhang Sheng
Volker Hilsheimer
Christoph Schleifenbaum
Dimitrios Apostolou
Lars Schmertmann
Marc Mutz
Lars Knoll
Qt Forward Merge Bot
Tor Arne Vestbø
Konstantin Ritt
Friedemann Kleint
Liang Qi
Christian Ehrlicher
Tor Arne Vestbø
Anton Kudryavtsev