If the SRGB framebuffer extension in GL is available, we can support
gamma correction of text with a gamma of 2.1. On Mac this is
sufficient for gamma correcting subpixel antialiased text. Gray
antialiasing should not be gamma corrected on Mac.
On Windows, the user can potentially set the gamma value to anything
between 1.0 and 2.2 (or something like that). We support anything
that resembles 1.0 closely enough by pushing the text out without
any correction (like before). We also support anything that resembles
2.1 (the gamma hardcoded in GL's SRGB extension) by turning on the
extension before blending the text. In between the two, we'll use
gray antialiasing to avoid differing too much from the raster engine
(which is our reference in this.)
For gray antialiasing on Windows, we use a constant gamma of 2.3 which
has been determined by experimentation. Since this is close enough to
2.1 we do gamma correction with SRGB extension.
The distance limit of 0.2 is determined by some experimentation.
Reviewed-by: Samuel
(cherry picked from commit 79ba7cceca5e4029876ace2121edd25b08ae14ce)
The pixel size in the font engines is already a floating point value.
For maximum flexibility, we should expose this in the public API.
Task-number: QTBUG-18817
Reviewed-by: Jiang Jiang
(cherry picked from commit ac9e63b58533a3215106ed9da82cff3a3e3dda3a)
* QTextCharFormat::AlignNormal - support text format descent, place text object bottom on (baseline - descent).
* QTextCharFormat::AlignBottom - place text object bottom on baseline.
* QTextCharFormat::AlignTop - Still not supported.
* Any other vertical alignment is mapped QTextCharFormat::AlignBottom.
Add new enum AlignBaseline for custom inline objects to take into account font baseline.
Merge-request: 2578
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
(cherry picked from commit ee9455ed2a83084692d969c398ecb91bcd4fc33a)
When shaping a QScriptItem with a multi font engine, currently we
only take the ascent/descent/leading from the primary (first) font
engine in that multi font engine, however, subsequent engines used
during shaping may have larger ascent/descent/leading, disregarding
them may cause clipping issues in some cases.
It's fixed by checking each font engine used in the shaping process
and take the maximum value instead of the first one. On ATSUI we
merely make it compile.
Task-number: QTBUG-16719
Reviewed-by: Eskil
(cherry picked from commit c501403cb5a0c9ec21b00e0c2f640ae85566e0cf)
If the text is wrapped with LRE/LRO/RLE/RLO override/embed marks,
Core Text in Mac OS X 10.5 doesn't produce an empty glyph at the
beginning of the glyphs (while it does in Mac OS X 10.6), thus
we need to prepend an empty glyph here, otherwise cursor position
calculation will consider the first two characters as a ligature
of the same glyph.
Reviewed-by: Eskil
(cherry picked from commit a36ac6c34bafa801c2c30d76f59e4a3594efc4d5)
Otherwise accessing that through QTextEngine::alignLine may cause crash.
Reviewed-by: Samuel Rødal
(cherry picked from commit dcdb62c3d1a76d951c4b65bc1b1bd930e2ad14ec)
When painting horizontally centered RTL text and selection with
trailing spaces, we need to take that space width into account
because line.textAdvance doesn't include it.
Task-number: QTBUG-18612
Reviewed-by: Eskil
(cherry picked from commit 224226727f07e8940e0d3131fe7587b11cc4a6ca)
Since it already transformed text positions based on transform matrix
on QPainter.
Reviewed-by: Eskil
(cherry picked from commit b86c9120710bf1481df5f6541618169a82fd65b8)
It's possible to enable HarfBuzz text layout on Mac by either:
- Set QT_ENABLE_HARFBUZZ environment variable when running a Qt
app.
- configure with -harfbuzz to build Qt, then HarfBuzz support
will be turned on by default.
HarfBuzz will only be used when the font explicitly requested
is supported by HarfBuzz (aka. TrueType/OpenType font), other
fonts (AAT fonts) will still be handled by Core Text.
Using HarfBuzz for text layout will hopefully solve most tricky
complex text shaping bugs on Mac.
Task-number: QTBUG-17728
Reviewed-by: Eskil
Bidi input can in some contexts be more intuitive if the cursor
works in visual way: pressing left arrow key always make cursor
move one character to the left regardless the language of text,
pressing right arrow key always make cursor move to the right.
It is also the behavior of Mac OS X. Based on the above reason
and requests from Symbian we implemented this support for visual
movement in BIDI text. 3 public properties are added to
QTextDocument, QTextLayout and QLineEdit respectively:
- QTextDocument::defaultCursorMoveStyle can be used to control
the cursor behavior in all widgets based on QTextDocument,
like QTextEdit, QPlainTextEdit, etc. When set to QTextCursor::
Visual, it will enable visual movement for all the cursors in
the corresponding text edit. Default is QTextCursor::Logical.
- QTextLayout::cursorMoveStyle is used for low-level cursor
manipulation. When set to Visual, it will enable visual movement
behavior for all the cursor related methods, including cursorToX,
xToCursor and drawCursor. Default is Logical.
- QLineEdit::cursorMoveStyle is used to control cursor movement
behavior in QLineEdit. Default is Logical.:
Task-number: QTBUG-13859
Reviewed-by: Eskil
(cherry picked from commit c480dd641f5d22d1ee72cb27bf39e24c6df65658)
The QFont consists of a d pointer and a resolve mask, and they should
both be copied in the assignment operator.
Task-number: QTBUG-18921
Done-by: Friedemann Kleint
(cherry picked from commit cb5e526c6023237c36aac3446a0a18288f39f3a9)
We would assume the font engine was a FT engine and do a static cast
here, which would cause a crash if the box engine was in use instead.
Task-number: QTBUG-17443
Reviewed-by: Samuel
(cherry picked from commit c9c54682bcd23598ac7a8db3b10e9f18c978e268)
Just a minor clean-up in the QGlyphs docs. Mainly to try to trigger
CI.
Reviewed-by: TrustMe
(cherry picked from commit 774b5b8c6a627fc90fb7382bc907db5d2e8193bf)
Moved the logic to set pixel size into the font engines to avoid
making the platform plugin interface too complex, and added a function
in QPA to make an isolated font engine based on font data. Currently
none of the QPA back-ends supports it, but it compiles and spits out
a warning if you try to create a QRawFont from data there. This isn't
used in QtQuick2 anyway.
Reviewed-by: Jiang Jiang
When modularized, the benchmark test case might not have access
to the JavaScriptCore source code. So, make sure the test case
still compiles in this case.
Now it points to QtBase's bin directory, in the case of developer
builds. This makes it easier to develop modules together without
having to install them first.
