The font system in Lighthouse was more or less a straight copy from QWS. From time to time I use the browser example test Lighthouse, but I was pretty annoyed that Lighthouse didn't pick up the fonts on my system, but used the fonts that was shipped with Qt. Also one thing that has been in the back of my head when thinking about fonts and Lighthouse is that QtGui was linking against (or including) FreeType. This is something we don't want if we are going to port Lighthouse to some other platform with some other glyph rasterizer.
So last week I put something together:
QPlatformIntegration has a new accessor:
QPlatformFontDatabase *QPlatformIntegration::fontDatabase() const;
QPlatformFontDatabase has relatively small interface:
virtual void populateFontDatabase();
virtual QFontEngine *fontEngine(const QFontDef &fontDef, QUnicodeTables::Script script, void *handle);
virtual QStringList fallbacksForFamily(const QString family, const QFont::Style &style, const QUnicodeTables::Script &script) const;
virtual void addApplicationFont(const QByteArray &fontData, const QString &fileName);
virtual void releaseHandle(void *handle);
QPlatformIntegration is suppose to return one
QPlatformFontDatabase, and its this class which is responsible to populate an internal db with font families.
I ended up pushing the creation of fontengines to the plugin as well. This way the fontengines don't need to be part of QtGui, but can be pushed to the plugins.
Its a bit much to expect everyone who wants to write a Lighthouse plugin to write a
QPlatformFontDatabase from scratch, so todays functionality++ is implemented and put inside the platforms plugins src directory:
When I made the patch Paul had one big objection: There is no default implementation. Do we need to have some include magic in the pro file, and have non cross platform code in the minimal plugin?
ARGH.... I thought. There is no way to have completely cross platform way of doing this...
However, there is. A few years ago Simon and Paul made a pre-rendered font format they ended up calling qpf2 (wild guess is that it stands for QtPre-renderedFont2). That font-engine was tightly coupled with Linux, but that was because of some ultra-fancy cross process glyph caching which QWS used. By just using the cross platform code the default implementation of QPlatformFontDatabase will pick up all qpf2 files in the prefix/lib/fonts dir and use them when rendering text. Sizes will be completely wrong, but hey a letter in the wrong size is much much better than an empty box?
I have no interest in xlfd so I have ignored these fonts. However using fontconfig to pickup fonts which I can rasterize with freetype is interesting. There are no X dependencies so it will work with the LinuxFb plugin or the DirectFb plugin. I ended up making 2 fontdatabases. QBasicUnixFontDatabase which is simmilar to what QWS did, and QFontconfigDatabase. However, choosing is a bit crap I think. So I made a QGenericUnixFontDatabase as well. It takes checks the Qt configuration and does the right thing based on that.
I decided that using these implementations needed to be as easy as possible, so all that is needed is to include the pri file and instansiate the fontdatabase in the platform integration. I have changed all the plugins in the repository to use QGenericUnixFontDatabase, so have a look in ie. directfb to see how to do this for your plugin.
Stay up to date with the latest marketing, sales and service tips and news.
Download the latest release here: www.qt.io/download.
Qt 5.12 was developed with a strong focus on quality and is a long-term-supported (LTS) release that will be supported for 3 years.
Näytä tämä julkaisu Instagramissa.
Want to build something for tomorrow, join #QtPeople today! We have loads of cool jobs you don’t want to miss! http://qt.io/careers #builtwithQt #software #developers #coding #framework #tool #tooling #C++ #QML #engineers #sales #tech #technology #UI #UX #CX #Qt #Qtdev #global #openpositions #careers #job
Henkilön Qt (@theqtcompany) jakama julkaisu