QFreeTypeFontDatabase allows registering fonts either by filename,
ending up with FT_New_Face, or via raw data, resulting in a
FT_New_Memory_Face. We then register the font with QFontDatabase
using a custom FontFile handle, where store the filename.
When then getting a callback to QFreeTypeFontDatabase::fontEngine
we would pull out the filename from the handle and call
QFontEngineFT::create with this filename.
This meant that if a font was registered with raw data, the font
engine creation would only work if there was a corresponding valid
file name/path. The only reason this works for addApplicationFont
is that QFreetypeFace::getFace() has a hard-coded workaround for
:qmemoryfonts where it uses qt_fontdata_from_index to get at the
original data.
Luckily for us QFontEngineFT::create already takes a QByteArray
data argument, which is plumbed to QFreetypeFace::getFace as well,
so all we need to do is fix the first part of the plumbing by
adding the original data to the FontFile handle and passing it
on in QFreeTypeFontDatabase::fontEngine.
This would potentially allow us to remove the hard-coded logic
for qmemoryfonts, but this has not been further investigated.
QPlatformFontDatabase also has another fontEngine overload that
takes a QByteArray directly, but this code path is only used by
QRawFont for now. A future improvement would be to unify some
of this logic.
Finally, it's unclear why the FT font database uses a custom
FontFile as a handle, instead of the original FT_Face that was
already created in addTTFile(). As a result of the current
approach we end up creating the face both when registering it,
and when creating a font engine for it. Investigating this is
left for later.
Change-Id: I7e01820a82d2664e8f34c3553bdcebe6a7afa078
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
a8b49216d0