QGIS’ handling of color ramps has just gotten much better with a series of improvements we committed to the open source project’s upcoming version 3.0.
This slide goes through brief summary of changes:
Color ramp handling, made fun!
On the developer front, one nice improvement is the addition of an invert() function directly attached to color ramp classes (QgsColorRamp and its children). This removed the need for symbol layers and renderers to implement individual invert-related functions; those are now served with a customized source color ramp, with edited steps and/or reversed order already taken into account.
Over the last few weeks, we’ve been busy improving the user interface as well as adding features to QGIS’ style management system. The end result is a streamlined experience with better exposure to saved symbols’ management tools such as tagging and a newly-implemented favorites system.
This slide offers an brief overview of the changes, part of upcoming QGIS 3.0:
We also took the time to update the default set of saved symbols shipped with QGIS:
The new set better serves users looking for usable predefined set of symbols. It also does a good job at reflecting the cartographic capabilities of the software.
For adventurous Linux-based OS users able to compile QGIS, these improvements are now available on the master branch. For Windows users, work is under way to make QGIS 3.0’s underlying libraries available.
When producing localized cartographic products, we often have to render numbers - integer and float values - in languages that do not make use of Arabic numerals. For instance, in the map above, area values (in red) are rendered in Thai, based on a numerical field.
In QGIS, until now, users could create an expression-based label that would use a series of replace() function embedded into one another against an numerical field to dynamically localize the numbers:
To say it didn’t look very good is a gross understatement.
In upcoming version 3.0, the expression engine’s replace() function got upgraded to support arrays (and map) replacement parameters, making for a much cleaner syntax.
For e.g., this is how an expression to convert Arabic numerals into Thai numerals look like:
With a simple replace call, QGIS now allows for on-the-fly localization of number fields. Couple that with the virtual fields feature, users can also have the localized values show up in the attribute table:
TL;DR if all goes according to plan, the next major version of QGIS will feature an updated set of core libraries; among the many benefits this will bring is support for proper rendering for a whole new range of complex languages
QGIS has long been recognized for its excellent Unicode encoding support which enables handling of data and the rendering of maps in a wide range of languages, including but not limited to complex Indic-based writing sytems such as Khmer or Lao.
This is possible in large part due to QGIS’ underlying foundation: Qt. As part of the forthcoming 3.0 release, QGIS is planning to leave Qt4 behind – which has for years now gone into maintenance-only mode - and upgrade to actively developed Qt5, the framework's latest version. This is a significant change and it is cause for celebration as it will come with a wide range of ameliorations all around, across all platforms.
Over here, we are particularly excited about one specific improvement: the revamped text shaping engine.
Text shaping is the process through which text is converted into glyphs and positioned to form characters. In Qt, that process is handled by a library called harfbuzz. Under Qt4, the library relies on its first generation codebase. Under Qt5 however, a rebooted library codebase (referred to as harfbuzz-ng) is used.
The difference between those two libraries? Over four years worth of improvements! The source tree of the original harfbuzz library saw its last commit on July 30, 2012. The harfbuzz-ng tree however is actively developed, with its latest release, 1.3.0, dating July 21, 2016.
Based in Southeast Asia, we routinely produce maps featuring complex languages from the region. One such language is Burmese, which Qt4 simply does not support due to its use of harfbuzz’s first generation codebase.
When rendering Burmese language with QGIS compiled against Qt4, things looked like this:
The glyphs’ shapes and positioning are all wrong, resulting in illegible text. For those who are not familiar with Indic-based languages such as Burmese, the above would be like taking the following text “I love QGIS!” and rendering it “LvQg e! SIo”.
When compiled against Qt5, powered by harfbuzz-ng, QGIS properly shapes Burmese text:
For those interested in building QGIS against Qt5, follow the instructions on this post by OpenGIS.
Note: Windows users have not – contrary to Linux users - been virtually stuck in 2012 when it comes to text rendering as Qt4 defers to the system’s uniscribe library to do shaping; uniscribe is actively developed by Microsoft with new versions shipped alongside Windows updates.