In Korean text, they typically can use both the "Western" style of
word wrapping, i.e. breaking on spaces, as well as the East-Asian
style of potentially breaking between all syllables. However,
the Unicode Line Breaking Algorithm, TR14 defaults to breaks on
syllables and specifies a possible tailoring where Hangul is
mapped to the AL class instead:
"When Korean uses SPACE for line breaking, the classes in rule
LB26, as well as characters of class ID, are often tailored to AL"
When using Qt, the user would expect the WordWrap wrap mode to
break between words in Korean. If you want the syllable-based
text layout, you would use WrapAnywhere, probably accompanied
by line justification.
To avoid breaking QTextBoundaryFinder and other potential clients
of QUnicodeTools which depend on getting the precise Unicode
data from the algorithm, we do this by passing a flag from
QTextEngine when initializing the attributes. This way, it
can also be made optional later on, if we decide there is
a reason to add an additional wrap mode specifically to
handle cases like this.
[ChangeLog][Important Behavioral Change] WrapWord now
correctly prefers line breaks between words in Korean text.
WrapAnywhere can still be used to get breaks between syllables
instead.
Done-with: Alexey Turitsyn <alexey.turitsyn@lge.com>
Task-number: QTBUG-47644
Change-Id: I37b45cea2995db7fc2b61e3a0cc681bbdc334678
Reviewed-by: Lars Knoll <lars.knoll@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>
Prevent automatic insertion of line-breaks in blocks formatted with 'white-space:nowrap'.
This follows the example of white-space:pre.
Fixes: QTBUG-54787
Change-Id: If26f6a54106a02fe0e388947f6368ae4e86acf63
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Mark some long obsolete functions as deprecated so the can be removed
with Qt6:
- QTextFormat::setAnchorName()/anchorName()
- QTextList::isEmpty()
Change-Id: Ic1f5317980d116c846def3645d2a6cd61ba8679d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
The bool is assigned on the previous line: QTRY_VERIFY will not do
anything because the statement is already true.
Change-Id: I067290e19ffd100819b2b631af431c6013623a00
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
It was an implicit effect before which stopped working after
dec7961709. Reintroduce it as some
projects used this side-effect as a way to abort the initial
highlighting.
Change-Id: I5340ee9882a242bc8b5f7f843f1cfe793a65d357
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
Also blacklist tst_QRawFont::unsupportedWritingSystem() and
tst_QGlyphRun::mixedScripts() on windows for now.
Conflicts:
qmake/generators/makefile.cpp
src/corelib/itemmodels/qstringlistmodel.cpp
src/platformsupport/fontdatabases/windows/qwindowsfontengine_p.h
tests/auto/corelib/itemmodels/qstringlistmodel/tst_qstringlistmodel.cpp
tests/auto/gui/text/qglyphrun/BLACKLIST
tests/auto/gui/text/qrawfont/BLACKLIST
Task-number: QTBUG-72836
Change-Id: I10fea1493f0ae1a5708e1e48d0a4d7d6b76258b9
When eliding text we would check for the existence of the ellipsis
character and fall back to using the dot if it was not available.
However, when font merging was in use, we would also use ellipsis
from a fallback font if available. This could cause the metrics
of the text to increase if the fallback font had larger metrics,
and the result was that text could shift when elided.
It is better to prefer the dot from the current font than to use
the ellipsis from a fallback, so we only use the ellipsis if
it is in the main font.
[ChangeLog][QtGui][Text] Fixed a bug where eliding text could
change the height of its bounding rectangle for certain fonts.
Fixes: QTBUG-72553
Change-Id: Ib27fc65302465ddce661801bcc5ae32e55f1aeb9
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Certain fonts with multiple styles have the same family name. When
loading these as application fonts we were not specific enough when
querying for the text metrics. This meant that e.g. the bold version in
a font family would get the metrics of the regular one.
Fixes: QTBUG-67273
Change-Id: Ic988d62cddde0a1f77ddcaf2891cadc21c9b31e6
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
When calling setDocument (directly or through the constructor) a delayed
rehighlight is initiated. Previously, if any text was changed before
this rehighlight could run it would cancel the rehighlight, even if the
changed text only caused a new block of text to be highlighted.
Fixes: QTBUG-71307
Change-Id: Ib09b664d90906f5b4427105f0e45469806f3a779
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@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 hue parameter in hsl/hsv was treated the same way as a the other
parameters although it's range is from 0-359 and not from 0-255.
Fix it by extending the maximum range for the first parameter when
parsing a color value given in hsv or hsl.
[ChangeLog][QtGui][CSS] Fix the range of the hue parameter when parsing
a color given in hsl or hsv
Fixes: QTBUG-70897
Change-Id: I9ffa65a89c0abcca62bae35777ca1cbde3375180
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The Qt stylesheets color property did not support hsl or hsla although
CSS 2.1 does support it. Since QColor natively supports this color model
only the color parsing needed to be adjusted.
This also adds some stricter checks for a valid css color definition and
prints a warning about the issue.
[ChangeLog][QtGui][CSS] Added support for hsl/hsla colors
Fixes: QTBUG-58804
Change-Id: Ief65a36a7e0ed0d705dc1fe5a8658e8d07fe9a13
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
When there were additional spaces between the function definition and
the first parameter, the parser failed to parse it when it contained
another function (e.g. 'qlineargradient(... rgb() ...)').
The reason for this was that ::until() needs the function at index-1 so
it can correctly count the opening parenthesis.
Fixes: QTBUG-61795
Change-Id: I992f556e7f8cd45550f83bc90aa8de2b4e905574
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The flakiness was reported for macOS 10.8 a long time ago and I
am not able to reproduce it, so lets remove the workaround for
it.
Task-number: QTBUG-32690
Change-Id: I92e64065c7480b8f4c5d1d1e6cb5fdd218a70313
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
When a QTextCursor survives its QTextDocument, the internal
QTextDocumentPrivate pointer is set to null. There are checks for
this in all the QTextCursor functions to skip out early if such
a QTextCursor is used.
However, when executing the "if (d->priv)" condition in setters,
this will access the non-const operator->() of QSharedDataPointer
and detach the QTextCursorPrivate, and in the copy constructor of
this class, there was an unprotected call into priv->addCursor().
In theory, we could cast all the checks for d->priv to avoid
detaching, but in practice this doesn't matter, since the setters
will typically detach anyway later on.
[ChangeLog][QtGui][Text] Fixed a crash that can happen when calling
a setter on a QTextCursor after its QTextDocument has been deleted.
Task-number: QTBUG-70293
Change-Id: I8f6dc5bb344d1d824f673c0c220b68b7fee237a8
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
When showing line and paragraph separators at an offset from the start
of the string, the end of string pointer would be incorrectly set, and
we would read past the end of the string. If any part of this memory
happened to match the line or paragraph separator, then we would
overwrite it and have a crash.
I couldn't find any reliable way to test this, since the crash depends on
the contents of the memory after the string allocated by the algorithm.
But with an overflow of 100 000 characters, I found that it crashed every
time I ran the test.
[ChangeLog][QtGui][Text] Fixed potential crash when using
QTextOption::ShowLineAndParagraphSeparators.
Task-number: QTBUG-69661
Change-Id: I17d1996b883560bacdc7ce114c8aeb2b0108faea
Reviewed-by: JiDe Zhang <zccrs@live.com>
Reviewed-by: Michal Lazo <xlazom00@gmail.com>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
winrt still has some issues with some character sets. These
tests are skipped/blacklisted for now and will be investigated.
Task-number: QTBUG-68297
Change-Id: I898e3383a4673b6dc87815a75e705f3302a4cbba
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This autotest fails on Ubuntu 18.04 and QEMU builds.
Task-number: QTBUG-68860
Change-Id: I1907e713e8c743cf5cf8e284df516600a0c03dba
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
Adjust line positions to deal with negative leading which isn't included
in height of QTextLine.
Change-Id: Id7918968c0f9d7e65700b9e7a08fc5d761883f22
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
The bounding rect was not including positive leading of the last line. This
patch solves it by changing using QTextLine's setLeadingIncluded, and adds
handling of negative leading to keep rendering unchanged in that case.
Change-Id: I4d18b81892184bb85cd7949a5dc3fb9cfa270a26
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
When showing a condensed font with AnyStretch, we should
not apply any stretch to the font (and if a stretch is
requested, we should calculate the actual stretch based
on how much the font is already stretched or condensed).
This usually works as expected, however, when using
QFont::NoFontMerging as the style strategy, we would
scale the glyph advances by the stretch of the font
since the calculated stretch of the font engine would
be overwritten by the actual stretch. In the case where
we use font merging, this would be done for the multi
engine, so we would not get the same issue, since the
text engine gets the stretch from the actual font engine
and this still has the original, calculated stretch
set.
Note on the test: We can't use testString() for this,
since it contains a space, and the test font does not
have a glyph for this, so we will end up merging a
different font for the space, giving us a slightly
different advance.
[ChangeLog][QtGui][macOS] Fixed display of condensed fonts
when NoFontMerging is in use.
Task-number: QTBUG-63800
Change-Id: I5b05e0dbfc8ae4b5d10c621ecb0975f53fda9483
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
QTextDocumentWriter only supports a small subset of table formatting
when exporting to ODF-format. This patch adds more formatting
capabilities to the ODF exporter:
- table border support
- table alignment
- table width
- respect column constraints (column widths)
- add a tab before soft line breaks. This will avoid causing the last
line to stretch all over the cell in justified paragraphs.
With this patch, line height settings are now exported, too.
[ChangeLog][QtGui][QDocumentWriter] QDocumentWriter now supports table
borders, table alignment, table width, column widths, line height and
image resolution when exporting QTextDocuments to ODF files.
Task-number: QTBUG-63581
Change-Id: I2d269ef0f842e73af64d48bfef531d5fa3078088
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Remove BLACKLIST files which are no longer valid because the mentioned
CI systems are no longer active:
- opensuse-13.1
- opensuse-42.1
- rhel-7.1
- rhel-7.2
- rhel-7.3
- ubuntu-14.04
or the testcases are no longer available:
- QTBUG_14292_filesystem in qactiongroup
Change-Id: I80a4397059fafba169096440fdc07d45c76a1ed8
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
QFontEngine::cloneWithSize() is used by QRawFont internally when switching
a raw-font from one size to another using setPixelSize. For CoreText, we
use a subclass of QCoreTextFontEngine to keep track of the QByteArray data
of a raw-font, but failed to overload cloneWithSize, so we would lose the
data whenever setPixelSize was called, resulting in missing text rendering
in QtWebKit. We now retain the data as we should.
Task-number: QTBUG-65923
Change-Id: I7d4186a3c32a61d48d1e9388e43f2792e8e46081
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
The size of the QStaticText was always adjusted, even if setTextWidth()
was used. Now size of the QStaticText is calculated according to
the set width of the text, and if no width was set, then the
automatically adjusted size is used.
[ChangeLog][QtGui][QStaticText] Fixed explicitly set width not being
respected.
Task-number: QTBUG-65836
Change-Id: If2f9f6952fb168f4bcb6d8fabfdc7360f8a36485
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
After we stopped sanitizing the fallback font list (with change
6ca48a847a), we now need to make
sure it is ordered so that the fonts that support the writing
system in question are always tested first, otherwise we can end up
loading a lot of fonts that will never be used.
Task-number: QTBUG-65605
Change-Id: Id2a65bbff3e64e6d6e6b4f72500778ee3e811e84
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
When we request fallback fonts, we cannot discriminate the fonts
based on the writing system support. This is especially important
since common script is now merged with other scripts, meaning that
a common script character will always go through the fallback
mechanism when not supported by the main font. When drawing
for instance a string of Devanagari characters on macOS, we would
get a list of 33 fallback fonts, but almost all of them would be
the default Devanagari font, since none of the other fallbacks
would support that script. Meaning that we would just check the
same font over and over, which makes no sense. The fallback list
has been retrieved specifically for the given script, so we do
not need to consider that when fetching the fonts.
For most of the common set, we will not have noticed the bug,
because at least one of the writing system-specific fallbacks will
have had support for latin characters as well. But when trying to
mix emojis and some non-common script, we would get a box in
place of the emoji, which had been adopted to the main script and
would only be looked for in the fonts supporting this.
Note that this exposed an issue with the QRawFont test on some
systems. When the sample text contained a space, it would
be possible to get a fallback font for this character, since
we now effectively support fallbacks. This is not the correct
behavior, but it is unrelated to this fix, and it was not what
the QRawFont::unsupportedWritingSystem() test was written to
check. I have therefore removed the space from the sample text
to make the test pass, and will make a separate task of fixing
the issue of merging fonts for whitespace characters.
[ChangeLog][QtGui][Text] Fixed a bug where mixing different
writing systems with emojis could lead to missing glyphs.
Task-number: QTBUG-61882
Change-Id: I00f6043bb01af1f2277723ccf643034aebf3e18f
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
The QTextFormat::FontLetterSpacingType property was added outside
the span of the FirstFontProperty and LastFontProperty, so
the fontDirty flag would not be set when it was changed. There is
no binary compatible way to fix this before Qt 6, so for now, we
add a special case for it.
[ChangeLog][QtGui][Text] Fixed an issue where changing the letter
spacing type of a QTextCharFormat would not cause its font to
update.
Task-number: QTBUG-65345
Change-Id: I5ab53d7f82d529b57edceacfc3fa688c6741cd17
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: C. Boemann <cbo@boemann.dk>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
QFontMetrics(F)::width() has been deprecated and is replaced by
horizontalAdvance(). This updates all usage of it in tests and
documentation.
It is worth noting that many or most of the usages of
QFontMetrics::width() probably intended to use boundingRect().width(),
but since it currently works, I have not looked into that, just
replaced the function name mechanically.
Change-Id: Iec382e5bad0b50f37a6cfff841bfb46ed4d4555f
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
