summaryrefslogtreecommitdiffstats
path: root/src/platformsupport/fontdatabases/windows/qwindowsfontenginedirectwrite_p.h
Commit message (Collapse)AuthorAgeFilesLines
* Move windows font databases into QtGuiFriedemann Kleint2020-06-111-152/+0
| | | | | | | | | | Requires adapting a few config checks since cmake currently does not detect directwrite. Task-number: QTBUG-83255 Task-number: QTBUG-83931 Change-Id: I521f1924f701260b41dccbcecf87b19f08df5ccc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix font height metrics with embedded bitmapsEskil Abrahamsen Blomfeldt2020-05-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Use consistent vertical metrics on all platformsEskil Abrahamsen Blomfeldt2020-04-221-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-07-121-2/+2
|\ | | | | | | | | | | | | | | | | | | Conflicts: configure.pri Also required s/solid\.color/solidColor/ in a couple of places in: src/gui/painting/qpaintengine_raster.cpp Change-Id: I29937f63e9779deb6dac7ae77e2948d06ebc0319
| * Support pen color with color fontsEskil Abrahamsen Blomfeldt2019-07-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Use Q_DISABLE_COPY_MOVE for private classesFriedemann Kleint2018-12-121-1/+1
|/ | | | | Change-Id: I3cfcfba892ff4a0ab4e31f308620b445162bb17b Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
* Windows code: Fix clang-tidy warnings about (private) class definitionsFriedemann Kleint2018-09-021-1/+2
| | | | | | | | | | | Add override, disable copies where appropriate and use = default for trivial functions. Change-Id: Ia5bc7419b1aa053c5503ea7dfaf11cb6dfafd2e2 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Replace Q_DECL_OVERRIDE with override where possibleKevin Funk2017-09-191-25/+25
| | | | | | | | | | | | | | | | Remaining uses of Q_DECL_OVERRIDE are in: src/corelib/global/qcompilerdetection.h src/corelib/global/qglobal.cpp doc/global/qt-cpp-defines.qdocconf (definition and documentation of Q_DECL_OVERRIDE) tests/manual/qcursor/qcursorhighdpi/main.cpp (a test executable compilable both under Qt4 and Qt5) Change-Id: Ib9b05d829add69e98a86238274b6a1fcb19b49ba Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io> Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
* Implement maxCharWidth() for DirectWrite engineEskil Abrahamsen Blomfeldt2017-04-111-0/+1
| | | | | | | | | | | | | | | | | | This is used to create the bounding box in QFontEngine::properties(), which in turn is used for the FontBBox when generating PDFs. The result was that the bounding width in the output was 0 and Adobe Reader complained that the PDF was malformed. We could implement the proper bounding rect in properties() at some point, instead of assuming an origin at x = 0 for instance. The metrics for that are in the head table. But for silencing the warning in Reader, just implementing the maxCharWidth() function is sufficient. [ChangeLog][Windows][PDF] Fixed a bug in PDF output when using high-dpi scaling which was causing the display of warnings when opening the file in Adobe Reader. Task-number: QTBUG-58954 Change-Id: I2540571863d4dd0f85af533b591f75dad3f0d75b Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Move Windows font DB and engines to QtFontDatabaseSupportGabriel de Dietrich2016-10-281-0/+154
This allows creating or extending QPA plugins to provide access to QFont and related types. It concerns both GDI and DirectWrite engines, as well as the regular and the freetype based font databases. The qt.qpa.fonts logging category has been moved together into the QWindowsFontDatabase related files to avoid depending on the qwindowscontext.h header file. Finally, QwindowsNativeImage is following pending a future refactor with similar code in qpixmap_win.cpp and the Windows XP style. Change-Id: Iddff2f3d715e3ab7695e6c2052b7596a01fd6fa8 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>