If an entity occurs directly in markdown, we parse and insert it
directly; but if it occurs in an HTML block, it has to be added to the
HTML accumulator string for deferred parsing when the HTML block ends.
Pick-to: 6.2
Fixes: QTBUG-91222
Fixes: QTBUG-94245
Change-Id: I0cf586d68d6751892ca035a98f77cd67950d3bc4
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
- Under a list item, we've been indenting code blocks:
```
int main() ...
```
- But it's also ok *not* to indent (and github handles that better):
```
int main() ...
```
- There was a bug that when the code is not indented, the fence would be
indented anyway:
```
int main() ...
```
and that was not OK, neither for md4c nor for github.
Now with this change, either way is rewritable: you can read markdown
into QTextDocument, make small edits and write it back out again, with
the indentation being preserved (the code block is either part of the
list item, thus indented, or else it's outside the list completely).
Pick-to: 6.2
Task-number: QTBUG-92445
Change-Id: I5f51899e28ba9f09b88a71e640d9283416cce171
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
[ChangeLog][QtGui][CSS] The background-color style can now be applied to
<hr/> to set the rule color.
Task-number: QTBUG-74342
Change-Id: Ib960ce4d38caa225f258b6d228fb794cef43e1b7
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
When parsing CSS, a border-color value is parsed as four brushes, as css
allows assigning up to four values, one for each side.
When applying the CSS to the HTML, we accessed it as a color value,
which overwrote the parsed value with a QColor. So while we had a valid
parsed value (and didn't re-parse), the code accessing that value still
expected it to be a list, and thus failed to retrieve the data.
There are several ways to fix that, but the cleanest way without
introducing any performance penalty from repeatedly parsing (and in fact
removing a parse of the string into a color) is to enable colorValue to
interpret an already parsed value that is a list without overwriting the
parsed value again. To avoid similar issues in the future, add assert
that the parsed value has the right type in brushValues.
As a drive-by, speed things up further by making use of qMetaTypeId
being constexpr, which allows for it to be used in a switch statement.
Add a test case.
Fixes: QTBUG-96603
Pick-to: 6.2 5.15
Change-Id: Icdbff874daedc91bff497cd0cd1d99e4c713217c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
When using the Freetype font database, we would ignore the
typographical width of loaded fonts, which could make it
impossible to select certain fonts in a family.
[ChangeLog][Freetype] Fixed a bug where fonts of different
width within the same family would be unselectable if the
Freetype font database (no-fontconfig configuration) was in
use.
Pick-to: 5.15 6.2
Fixes: QTBUG-89640
Change-Id: Ic9c17a7c3cc14eb7e942b05d6b21b7c1602816cf
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
This reverts commit 7fd9ed3201.
While trimming the font name worked for cases with application fonts,
it actually introduced an assert for system fonts that ended with a
space, because enumerating these failed. So the original assumption
that all Windows APIs also trimmed the family name was wrong.
The original bug was that the font with the trailing space could
not be selected, but when using setFamilies(), it can. So there is
a perfectly fine way around the original bug when using a font that
has this problem. Therefore, no additional fix is needed for that.
[ChangeLog][Windows] Fixed an assert that happened when the system
had a font with a trailing or leading space in its name.
Pick-to: 5.15 6.1 6.2
Fixes: QTBUG-93885
Task-number: QTBUG-79140
Change-Id: I6d9df31a4f2c6555d38d51da374f69b6fb0f1ecb
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The `QFont` documentation refers to Roman Czyborra's personal page with
the intent of providing information about encodings.
The page seems to have been down for many years and may contain
information that is now deprecated such that it is now replaced with a
link to the Unicode Technical Report 17 about the Unicode Character
Encoding Model.
The new link was chosen as a substitute as it seems to cover or provide
the intuition for, standing by the last captured version of Roman
Czyborra's personal page on the Wayback Machine, many of the same
concepts.
Task-number: QTBUG-96127
Pick-to: 6.2
Change-Id: Ibf901b5023688c14efb3d6f77a10609f7ba80e72
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
We can only start timers in threads started via QThread, and even then
we cannot assume that the thread runs an event loop. So only start the
timer when we are in the main thread.
Add a test that verifies that we don't get the warning message.
Pick-to: 6.2
Change-Id: I40d7d9ff115720f9ecd3eedaebbade2643daf843
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Using MS Gothic UI as the fallback on Japanese locale has been
outdated for many years. The default font on Japanese is Yu Gothic UI,
and this caused mismatches between Japanese text when using the
fallback and when just relying on the default.
[ChangeLog][Text] Made the primary fallback font on Japanese
locale "Yu Gothic UI" (the default system font).
Fixes: QTBUG-96689
Pick-to: 6.2
Change-Id: I9cf34410619ff4a2ceb9b03d523018c5061c3634
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
When there are characters with different pointsize in QScriptLine,
the value of si.descent is less than sl.descent, which will cause
the y value of the cursor rectangle to be too large.
If si.descent is less than sl.descent, the height of the cursor
rectangle is equal to base plus si.descent.
Amends e99a883bd3
Fixes: QTBUG-96288
Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Pick-to: 6.1 6.2
Change-Id: I4a8566b32cfa75d8ca1a584f5e8e577c5c9caf0d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Get LineHeightType once and reuse the value. There still are 2 calls
to lineHeightType from inside the QTextBlockFormat::lineHeight but
leaving them cause they need a bigger change.
Change-Id: I4016a5e483a0358d43f73d174a74545d4f3be338
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
a332f3fabc disabled resolving all fonts
on the system for every font lookup, which was a significant startup
time improvement. But it also caused a regression: When a font has
an alias which shares the name of a proper font, then this would
not be resolved correctly.
This is fairly typical on Windows/GDI due to backwards-compatibility.
Instead of being collected under a shared typographical family, fonts
are disambiguated by adding the style name to the family name. The
proper typographical name is still available, but this is not
enumerated by the system.
So "Segoe UI" for instance, will be available as "Segoe UI",
"Segoe UI Light", "Segoe UI Bold" etc.
When we populate family aliases, we register that "Segoe UI Light"
is actually "Segoe UI" with Light weight, and prior to
a332f3fabc this would be done implicitly.
But after the optimization, we would only populate family aliases once
we stumbled over a font request for a non-existent font. For "Segoe UI",
we would simply return the regular weight font as the best imperfect
match.
The fix is to populate font family aliases not only when the family is
non-existent, but when the match is imperfect, e.g. if we are asking
for a Light weight font and only finding a regular one. User code can
still avoid this somewhat expensive operation by using the full
family names on Windows.
This also requires a fix to a test. When removeApplicationFont() is
called, we invalidate the font database, so it will be reset to a state
that does not contain the family aliases. Therefore we cannot guarantee
that it is identical to what it was before the test started, since this
depends on what has happened previously in the application.
[ChangeLog][QtGui][Text] Fixed an issue where some font styles and weights
would not be selectable. This was especially noticeable on Windows.
Pick-to: 5.15 6.1 6.2
Fixes: QTBUG-94835
Change-Id: I892855edd1c8e3d3734aace396f6000d897d2ec4
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The QVariant returned by resource() can contain either a QPixmap
or a QImage. The code here is now more similar to the one in
qtextimagehandler.cpp.
Also, the quality is 0 when not set, in which case we want a nice PNG
rather than a very very low quality JPG with just a few large blocks of
same-color pixels.
Pick-to: 5.15 6.2
Change-Id: I49db542e2234c8068f85a636a81a7d8cdb7b5876
Reviewed-by: André Hartmann <aha_1980@gmx.de>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Replace the “size() / devicePixelRatio()” pattern with
a call to deviceIndependentSize().
Change-Id: I9d9359e80b9e6643e7395028cd43e3261d449ae7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The original code checks the existence of an ellipsis character first.If
this does not exist (glyph == 0,which is an invalid glyph index), then
it falls back to looking up '.'. But in the Tibetan environment,the
glyphIndex('.') also returns 0, so that it simply doesn't add any form
of "...", and cuts the text instead.
If both the attempts at getting something from the main font fails,
we can do a third pass on the "multi" font engine.
Fixes: QTBUG-95942
Pick-to: 6.1 6.2
Done-with: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Change-Id: I251de3fe92e19be0462c58c2059ecf7d354bfbb0
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@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>
When using NoFontMerging, no fallbacks should be resolved. If the
font does not support a specific character in the text, we should
display a box instead of merging it with another font.
But in practice, Qt would still apply the fallback mechanism for
one specific case: If the font itself does not support the script
of the text, we would get no match and do a search for a fallback
instead. Since NoFontMerging is set, we would then force this
as preresolved for *all* scripts in the QFont's private data
(logically, the match should only have a single response for
NoFontMerging).
The end result was that if you set the font family before updating
the text, you would get broken rendering. This can happen e.g. in
Qt Quick, where you could update the font family of a text label
while it contains characters which are not supported by the new
font. Qt would then pick a fallback instead. When you subsequently
update the text, the fallback would already be preresolved for
whatever script this is. If it does not support the updated text,
we would then see boxes, even if the requested font actually would
have supported it.
The fix is simply to do an additional pass if NoFontMerging is set
and we were not able to match with the specified script. Since
the same family might be available in different foundries, with
different writing system support, we still want to do a pass first
to see if we can match the exact script of the text.
Note that QRawFont::fromFont() exploited the bug by using
NoFontMerging for getting the fallback font for a specific
writing system. To keep this working without having to rewrite
fromFont() and risk introducing regressions, we add an argument
to make the findFont() function behave as before. It isn't
super-pretty, but since it is private API it is hopefully fine.
[ChangeLog][QtGui][Text] Fixed an issue with NoFontMerging and
changing font families dynamically, where boxes would be seen in
place of the correct text.
Pick-to: 5.15 6.1 6.2
Done-with: Andy Shaw
Fixes: QTBUG-81770
Change-Id: Ide9a36d7528a1040172c5864fa99e7a82eac4e83
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
On high-dpi displays or when you explicitly select an unhinted font,
we pick a DirectWrite font engine. This hit an uncovered code path
on Windows, because we relied on being able to get the HFONT from
the font engine.
To fix this, we introduce an alternative code path which gets the
HFONT based on the DirectWrite font when this font engine is active.
[ChangeLog][Windows] Fixed an issue where the characters in printed
text would look too small.
Pick-to: 6.1 6.2
Fixes: QTBUG-95720
Change-Id: Ifd609e92512e1f25f0ee2aace35cb5ccedf09030
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Apart from a more fitting, minimal, API, QDuplicateTracker also
transparently uses C++17 pmr::monotonic_buffer_resource to avoid, or
at least reduce, memory allocations.
Change-Id: I155f5518190c5f8f6d21fbec3fcecd6bcc7ff852
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Added missing #if-ery and deprecation macros to a QFont constructor
that was only documented as deprecated.
Fixes: QTBUG-94521
Fixes: QTBUG-95310
Pick-to: 6.2 6.1
Change-Id: I3d0418a3f7dca191a9068cc22627fe4deb7c53c5
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The fontFamilies and fontStyleName have an asymmetric getter and setter.
The setter takes QStringList, but the getter returns QVariant (?), for
no reason whatsoever (the underlying QFont APIs take QStringList,
and the docs say that they should return QStringList).
It's not entirely obvious that we can fix this without introducing
badly-named getters (getX) or somesuch, so for the time being, mark
this to be fixed in Qt 7.
Change-Id: I49706af00906a2c5d950ada4be3cbc76dbee432c
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
Fixes static analyzer warning 12b19393e18b2394a398806f633c6eee, and
amends a1a6e3d21b.
In the process, replace the "int& *= double" with correct integer
arithmetic that'll produce the intended result without going via
double.
Done-with: Edward Welbourne <edward.welbourne@qt.io>
Pick-to: 6.2
Task-number: QTBUG-8096
Change-Id: Ib2aa8ae46a1bfd4d121e61cf99141c0311502215
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Declaration::lengthValue only supported 'px' sizes, but one can transform
any 'pt' value into 'px' by multiplying with 1.33.
Notes: this ignores display DPI, and instead follows the W3C definition
of 'pt' and 'px' as absolute lengths [1].
[1] https://www.w3.org/TR/css3-values/#absolute-lengths
1pt = 1/72th of 1 inch
1px = 1/96th of 1 inch
so the conversion is px = pt * (72/96).
Add unit test that verifies this using QPushButton's icon-sizes property,
also with changed font in preparation of adding support for 'em' and 'ex'
units in a follow up commit.
Task-number: QTBUG-8096
Pick-to: 6.2
Done-with: Cristian Maureira-Fredes <Cristian.Maureira-Fredes@qt.io>
Change-Id: I58782e7ad0e2ff9d89ed695f8a23b1e584cfed64
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
This prevents us from first reserve()ing Prealloc elements, and then
possibly reserve()ing a larger number, which leaves the first bucket
list's memory unused.
Consequently, deprecate reserve().
Change-Id: Ifc0a5a021097f4589557e7b5e45d9d0892797ade
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Using the QTextFormat::FullWidthSelection property to select a line
would previously not take into account right-to-left text layouts.
With this patch, the whole line should now be drawn correctly for both
left-to-right, and right-to-left layouts.
Pick-to: 6.2 6.1 5.15
Fixes: QTBUG-91125
Change-Id: Ide7b340cd7b4060e7c00e55e0011a86ffdfb5eb4
Done-with: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Dmitry Shachnev <mitya57@gmail.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This is a partial revert of commit
f385b8827a.
This causes issues because we may overwrite genuine styles with
synthetic ones.
Lets say for instance that we register "Roboto Bold" and then later
we register "Roboto Thin". When we register "Roboto Thin" we also
register an alternative font which is called "Roboto" (because this
is the typographical family name of the font) with bold weight, because
we know Windows can synthesize this.
This would work fine, except that on Windows we also store the original
face name of the font as a user-pointer in the database. This contains
the legacy name of the font: "Roboto Thin". This will override the
font that is already stored. When we look up "Roboto" + bold weight in
the database later, we will find this synthetic font, replace
the requested family name with the legacy one "Roboto Thin" and use
this instead.
The right fix for now is to revert the cause of the regression. If we
want to re-fix the original bug, we might be able to reintroduce
f385b8827a and then make sure we always
prefer the "real" font when there are conflicts (this would mean marking
synthetic fonts in the database).
[ChangeLog][Windows] Fixed a regression where different font styles
and/or weights would not be available.
Fixes: QTBUG-94781
Task-number: QTBUG-91398
Pick-to: 5.15 6.1 6.2
Change-Id: I092022b14ebf1d56685eaa3b8efe55f015659adc
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The FontConfig database had a static leak because we never
dereferenced the current config. To make address sanitizer output
less noisy, we clean this up on shutdown.
From FcConfigDestroy docs: "Note that calling this function with the
return from FcConfigGetCurrent will cause a new configuration to be
created for use as current configuration."
So this should be safe even if application execution continues after
Qt shutdown, but it could trigger creation of a new current config
in that case, if FontConfig calls are made.
Fixes: QTBUG-92477
Pick-to: 5.15 6.1 6.2
Change-Id: I596055a84edc1a1b06157e2adf6c8627c6802db1
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
When QPainterPath was used for RTL text, either directly or because
the target text size exceeds 64 pixels, we would pass true for
"isRightToLeft" to DirectWrite, causing it to do adaptation internally
for this. But the RTL layout had already been handled by Qt, so we
would essentially reverse the layout twice and also move the text
to negative X coordinates.
Passing false instead fixes this, as it will then just use the
positions we pass in blindly.
Fixes: QTBUG-94175
Pick-to: 5.15 6.1 6.2
Change-Id: Ie9a47e56e97fc867ede10ab21ac5e3f003ddcacb
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Move QT_END_NAMESPACE macro out of the #ifdef definition
Pick-to: 6.2 6.1 5.15
Change-Id: I26b4e263b5ae0acebf035dbfe8c7e287cd740190
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Handle the case were a format was applied that does not align with
the fragments.
Pick-to: 6.2 6.1 5.15
Change-Id: I27593a50c587a5ec0290ff9d0a7a9767a3981cac
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Add FindWrapSystemMd4c.cmake so that the old md4c target can be used
as well as the new one and set WrapSystemMd4c_FOUND.
Link to the imported target WrapSystemMd4c::WrapSystemMd4c if the
system library is used.
Add qt_find_package line to find the package in configure.cmake.
Fix the condition for enabling system-textmarkdownreader, it includes
testing for textmarkdownreader because even if the code would compile
correctly without it, it looks strange when the output says
"textmarkdownreader no" and under "using system libmd4c yes" even if
libmd4c is not used.
Use system include when system-markdownreader is enabled.
Add library mapping for libmd4c.
Change-Id: Id5d5b13d6691a8c1cdf627238887977c847c1e67
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This way we can use it from qtdeclarative to parse styled text
Change-Id: Ic888a75a9700558e97b3e743d6d42fda121ddcba
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
This amends e2bdff3555.
The linearAdvance property has some history. First it was
a 16 bit value (allowing for 10.6 fixed point numbers). Then
it was turned into 22 bits to fit the 16 bits of Freetype
integer parts into it (16.6). Then back to 10.6. Then in
b7e4367387 it was turned
back into 16.6 again. But this was accidentally reverted
as part of a bad conflict resolution in
afb326f071.
Since there was no check for it, we would sometimes overflow
the linearAdvance, but only in the rare cases where the
width and height did not also overflow. Specifically this
is the case for whitespace, which always has a width of 0
regardless of the advance.
This change just moves the linearAdvance condition in
together with the other checks to avoid fragmentation, and
also adds this fun story to the commit log.
Pick-to: 6.1 5.15
Change-Id: Iaac09942f4c50d1aced4a160b6eabb11eb8e6373
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
The small caps version of a font is kept as a QFontPrivate*
which is manually reference counted, but we neglected to
actually delete it when the reference count went to 0.
[ChangeLog][Fonts] Fixed a memory leak when initializing
a small caps font.
Fixes: QTBUG-93068
Pick-to: 6.1 5.15
Change-Id: Icc7fb7a59bf523da84d2e6fa026940a7d1230525
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
Since Windows can synthesize certain font traits for us, we
used to register these in the font database so that we could
match against them. But after change
469b139169, this in principle
no longer happens, because we opt out whenever there is a
style name (which there usually is, this could be e.g.
"Regular" for a normal font). The result of this was that
if we looked for a bold variant of a font, we would not find
it.
In cases where a multi-engine was used, the request for bold
would still survive in the multi engine's fontDef, so we would
still pick it up later and apply the synthesis. But when
NoFontMerging was set, then we would override the weight in
the fontDef with the one from the font database.
Since the comment documents that the additional registrations
are there to make sure all the variants that Windows can
synthesize are available for matching, it does not make sense
to skip them just because the font has a style name. So this
is a partial revert of 469b139169.
Note: This exposed an error in QFontDatabase::isSmoothlyScalable().
The style parameter here is not the "styleName" (as in sub-family),
but actually predates that API. Instead it is the "style" as
returned by QFontDatabase::styles(), which may be the style
name, but it can also be the generated description of the style
and weight. In the latter case, we would return false for fonts
that are actually smoothly scalable, which is incorrect. This
caused a failure in tst_QFontMetrics::metrics(). To remedy this,
we add an additional condition, and also match the style if it
matches the generated descripion of the style key.
[ChangeLog][Windows] Fixed an issue where bold/italic would not
be synthesized for fonts if QFont::NoFontMerging was set.
Pick-to: 5.15 6.1
Fixes: QTBUG-91398
Change-Id: Id2166a47ae2d386536cf6e5e27ff09165ae8a23a
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Most nested block elements are merged together, so while we shouldn't
do real inheritance we need to do it when block elements are combined.
Pick-to: 6.1
Fixes: QTBUG-91236
Change-Id: I9e37b15f705db92c79a620d0d772f25d0ee72b8d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>