When reading a document like
# heading
- list item
and then re-writing it, it turned into
# heading
- # list item
because QTextCursor::insertList() simply calls QTextCursor::insertBlock(), thus
inheriting block format from the previous block, without an opportunity to
explicitly define the block format. So be more consistent: use
QTextMarkdownImporter::insertBlock() for blocks inside list items too. Now it
fully defines blockFormat first, then inserts the block, and then adds it to
the current list only when the "paragraph" is actually the list item's text
(but not when it's a continuation paragraph). Also, be prepared for applying
and removing block markers to arbitrary blocks, just in case (they might be
useful for block quotes, for example).
Change-Id: I391820af9b65e75abce12abab45d2477c49c86ac
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
Conflicts:
src/corelib/tools/qlocale_data_p.h
(Regenerated by running the scripts in util/local_database/)
src/gui/opengl/qopengltextureuploader.cpp
Done-With: Edward Welbourne <edward.welbourne@qt.io>
Done-With: Allan Sandfeld Jensen <allan.jensen@qt.io>
Change-Id: I12df7f066ed0a25eb109f61c4b8d8dea63b683e2
Also de-duplicate the "monospace" string in qgenericunixthemes.cpp,
and add tst_QFontDatabase::systemFixedFont() to verify that
QFontDatabase::systemFont(QFontDatabase::FixedFont) really returns
a monospace font across platforms. Replace commented-out qDebug()s
with qt.text.font.match and qt.text.font.db logging categories to
troubleshoot when the test fails (among other uses). Add qt.qpa.fonts
logging category to unix themes to show default system and fixed fonts
(font engines on other platforms are already using this category).
Fixes: QTBUG-54623
Change-Id: I2aa62b8c783d9ddb591a5e06e8df85c4af5bcb0c
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Don't go into an infinite loop breaking pages, when an image is about
as large as the page. Correctly take top and bottom margins into account
when calculating whether the image could fit on one page.
Amends change 416b4cf685.
Fixes: QTBUG-73730
Change-Id: Id311ddf05510be3b1d131702f4e17025a9861e58
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Can now detect nested quotes and code blocks inside quotes, and can
rewrite the markdown too.
QTextHtmlParser sets hard-coded left and right margins, so we need to do
the same to be able to read HTML and write markdown, or vice-versa,
and to ensure that all views (QTextEdit, QTextBrowser, QML Text etc.)
will render it with margins. But now we add a semantic memory too:
BlockQuoteLevel is similar to HeadingLevel, which was added in
310daae539 to preserve H1..H6 heading
levels, because detecting it via font size didn't make sense in
QTextMarkdownWriter. Likewise detecting quote level by its margins
didn't make sense; markdown supports nesting quotes; and indenting
nested quotes via 40 pixels may be a bit too much, so we should consider
it subject to change (and perhaps be able to change it via CSS later on).
Since we're adding BlockQuoteLevel and depending on it in QTextMarkdownWriter,
it's necessary to set it in QTextHtmlParser to enable HTML->markdown
conversion. (But so far, nested blockquotes in HTML are not supported.)
Quotes (and nested quotes) can contain indented code blocks, but it seems
the reverse is not true (according to https://spec.commonmark.org/0.29/#example-201 )
Quotes can contain fenced code blocks.
Quotes can contain lists. Nested lists can be interrupted with
nested code blocks and nested quotes.
So far the writer assumes all code blocks are the indented type.
It will be necessary to add another attribute to remember whether the
code block is indented or fenced (assuming that's necessary).
Fenced code blocks would work better for writing inside block quotes
and list items because the fence is less ambiguous than the indent.
Postponing cursor->insertBlock() as long as possible helps with nesting.
cursor->insertBlock() needs to be done "just in time" before inserting
text that will go in the block. The block and char formats aren't
necessarily known until that time. When a nested block (such as a
nested quote) ends, the context reverts to the previous block format,
which then needs to be re-determined and set before we insert text
into the outer block; but if no text will be inserted, no new block
is necessary. But we can't use QTextBlockFormat itself as storage,
because for some reason bullets become very "sticky" and it becomes
impossible to have plain continuation paragraphs inside list items:
they all get bullets. Somehow QTextBlockFormat remembers, if we copy it.
But we can create a new one each time and it's OK.
Change-Id: Icd0529eb90d2b6a3cb57f0104bf78a7be81ede52
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
- QObjects are always passed by pointer not by reference, by convention
- writeTable() takes QAIM rather than QATM to make testing via
QStandardItemModel possible in the future
Change-Id: I5bc6b8cd9709da4fb5d57d98fa22e0cb34360944
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
Importer fixes:
- the first list item after a heading doesn't keep the heading font
- the first text fragment after a bullet is the bullet text, not a
separate paragraph
- detect continuation lines and append to the list item text
- detect continuation paragraphs and indent them properly
- indent nested list items properly
- add a test for QTextMarkdownImporter
Writer fixes:
- after bullet items, continuation lines and paragraphs are indented
- indentation of continuations isn't affected by checkboxes
- add extra newlines between list items in "loose" lists
- avoid writing triple newlines
- enhance the test for QTextMarkdownWriter
Change-Id: Ib1dda514832f6dc0cdad177aa9a423a7038ac8c6
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
A QTextDocument can now be written out in Markdown format.
- Add the QTextMarkdownWriter as a private class for now
- Add QTextDocument::toMarkdown()
- QTextDocumentWriter uses QTextMarkdownWriter if setFormat("markdown")
is called or if the file suffix is .md or .mkd
- Add QTextEdit::toMarkdown() and the markdown property
[ChangeLog][QtGui][Text] Markdown (CommonMark or GitHub dialect) is now
a supported format for reading into and writing from QTextDocument.
Change-Id: I663a77017fac7ae1b3f9a400f5cd357bb40750af
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
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>
