mapnik.org

WKT geometry parsing benchmark

2013-04-19T00:00:00-07:00

In addition to beautiful rendering capabilities Mapnik also offers a fast C++ and Python API for working with raw geo features. You can create them on the fly from a variety of formats including wkt, wkb, and geojson. This feature allows creative programers to use Mapnik like you would OGR to read or create data and output it to other formats.

Geometry parsing for datasources and tests

The WKT and GeoJSON geometry parsing support in Mapnik core makes it easy to support for these formats in datasource plugins like the Mapnik CSV plugin. And because the CSV plugin supports inline WKT strings you can write simple, standalone test cases for Mapnik bugs as easily as ticket #1484 demonstrates.

Geometry parsing performance

As more people find the Mapnik CSV plugin they start throwing more and more data at it. We need to ensure that our parsing is as fast as possible. So today I started on some benchmarks to figure out baselines for performance. The questions I’m interested in are:

If parsing WKT across many threads does performance decline or improve? (We’ve found in the past that std::locale locking can kill threaded performance when parsing XML strings)
Does performance differ depending on the C++ library used? (the emergence of clang++ and libc++ on OS X make this an easy and relevant test)
How does Mapnik WKT parsing compare to other common libraries that people use for parsing WKT geometries?

First look at benchmarking results

Today I created a first pass at a C++ benchmark. The code is on github. Please see the README for details on how to set it up and run the tests.

There are two tests of Mapnik and GEOS that parse a set of very simple WKT geometries 100 thousand times, one serially and the other broken into 10 threads of work that each parse 10 thousand times.

The results on my system (OS X 10.8 / clang++) were:

mapnik compiled against libc++, using -std=c++11

$ ./run
1) threaded -> mapnik: 640 milliseconds
2) threaded -> geos: 2470 milliseconds
3) mapnik: 2800 milliseconds
4) geos: 9150 milliseconds

CAVEAT: Geos is not linked against libc++ in this test

mapnik compiled against libstdc++, using -ansi

$ ./run
1) threaded -> mapnik: 880 milliseconds
2) threaded -> geos: 2520 milliseconds
3) mapnik: 3440 milliseconds
4) geos: 9200 milliseconds

NOTE: smaller numbers are better and indicate that the tests finished faster.

The results seem to indicate:

High concurrency, as you would hope and expect, does not hurt performance but rather helps. This is great, but not always the case in C++ when parsing strings. If your parsing code triggers mutex locks then concurrency like this can hurt.
Mapnik is more than 2x faster than GEOS for these simple test cases. So, the next step here is to 1) figure out if Mapnik continues to perform well on larger WKT strings and 2) make sure we are using the GEOS API correctly.
Mapnik is slightly faster when compiled against libc++ and built in C++11 mode (than if compiled against libstdc++ in -ansi mode. This is great – will be interesting to learn why. My guess is that boost::spirit, which mapnik uses internally to parse WKT is benefiting from c++11 features. Or libc++ is providing faster implementations of key functionality than the standard gnu libstdc++. Or both :)

Please feel free to check out the benchmarks, run them yourself, and suggest other caveats or improvements. File issues here to provide comments.

Summer of Code 2012 - Summary

2012-10-06T00:00:00-07:00

Google Summer of Code 2012 is over now. All the previous posts where rather technical so I would like to talk about applications and show some beautiful images in this post.

First of all: If you live in a region where names are spelled using only characters from the ASCII set you will not notice this work very much. It was one design goal not to change the behavior for texts that are already correctly rendered. There are some minor differences but nothing big. However it is still worth to read on as I added many more cool features.

Rendering complex scripts

Mapnik can render any script supported by HarfBuzz now. If something is rendered incorrectly check if the font supports the characters you want to use, as this is the most likely cause of any problems. Especially do not use Unifont! It doesn’t support any of the features required for correct rendering of most complex scripts.

I don’t publish example images here because I can’t judge which images would show the most improvement. If a native speaker wants to add samples where text that was broken before is really good now please open an issue on Github.com and I will publish it here.

There are some new features and bug fixes not related to complex scripts as well:

Improved line placements

Line breaks

Since a long time Mapnik is able to handle line breaks in the text (either automatically created or supplied in the input data) but this feature never worked for line placements. You could render a long town name very well, but long street names were a problem so far. This situation is improved by enabling this for line placements as well.

However there is one important limitation: You have to set wrap-width to a certain value or provide input text with line break characters (‘\n’). There is no function to automatically select the right wrap-width value depending on the line length yet. Automatic hyphenation of long text is also not available yet. This will be implemented at some later time.

Example image

Syntax

<TextSymbolizer wrap-width="100" ...>[name]</TextSymbolizer>

Correct offsets

Mapnik already supported offsetting text on lines, but the algorithm was very simple and only worked well for almost straight lines. The new code uses the offset converter class to produce real offsets which works for every line shape.

This feature can be used to produce labels for e.g. borders.

Example image

Syntax

<TextSymbolizer dy="10" ...>[name]</TextSymbolizer>

Upright

For certain applications it is desirable to have a fixed orientation of the text with respect to the line direction. In the “offsets” example above you might have noticed that “Country 2” changes the text direction at one point in order to keep it upright.

This is useful behavior in most cases, but there are applications (like contour lines) where you don’t want to switch the direction. Therefore a new parameter “upright” was added to TextSymbolizer to choose the desired function.

Example image

Syntax

<TextSymbolizer upright="auto" ...>[name]</TextSymbolizer> <TextSymbolizer upright="left" ...>[name]</TextSymbolizer> <TextSymbolizer upright="right" ...>[name]</TextSymbolizer>

Rotate displacement

Mapnik supports rotating text via the orientation parameter to TextSymbolizer. As long as the text is centered on the point being labeled the question which center to use for rotation is trivial. But once the text is moved from this position there are different possible points.

Up to now Mapnik always rotated around the label’s center but now one can also select to include the displacement when rotating text. This feature is best described by the following two images:

Example images

Rotate displacement: Off (default)

Rotate displacement: On

Syntax

<TextSymbolizer dx="5" rotate-displacement="true" ...>[name]</TextSymbolizer>

Kerning & Ligatures

Kerning and ligatures are two features you probably won’t notice if you don’t know about them. But they improve the text rending in subtle ways:

Kerning reduces the spacing between characters when one of them is top-heavy and the other one is bottom-heavy.

A ligature is the combination of two or more characters into a single glyph for improved visual appearance.

Example images

Kerning:

With ligatures:

Without ligatures:

Syntax

This feature is always enabled.

Shield Symbolizer

New syntax

ShieldSymbolizer syntax was documented and updated to reflect actual behavior. However it was noticed that the current syntax is rather counter-intuitive so a new, better one was defined. Previously “shield-dx” moved shield and text and “dx” moved text only. This was reversed so that “shield-dx” moves the shield only.

For “dx” (and “dy”) the behavior depends on the value of “unlock-image” (which had an undefined function before).

unlock-image=“false”: dx moves text and image
unlock-image=“true”: dx moves text only

This parameter is especially useful with the alternate positions functions described below.

Label position tolerance

Mapnik moves labels a bit when there is a collision at the designated place, however this feature only worked for TextSymbolizer but not for ShieldSymbolizer. This is fixed now.

This feature can be used for better labeling of highways with multiple names.

Example image

Syntax

<ShieldSymbolizer label-position-tolerance="100">[ref]</ShieldSymbolizer>

or automatically enabled for Symbolizers with non-zero spacing:

<ShieldSymbolizer spacing="200">[ref]</ShieldSymbolizer>

Alternate positions

ShieldSymbolizer was extended to support the alternate placements mechanism already implemented in TextSymbolizer. This feature is similar to the one above, but has different uses. It doesn’t simply move the shield along the way, but allows to set completely different parameters. You can change the font, offset, position, etc. (Selecting a different shield image or shield-offset is not supported, yet but will be in the future. You can use dx and dy in combination with unlock-image to get the desired effect in most cases.)

Example image

Labeling multiple bus routes at the same bus stop:

Syntax

<ShieldSymbolizer [...] placement-type="list" horizontal-alignment="middle" vertical-alignment="middle">[ref]
<Placement dx="50"/>
<Placement dx="100"/>
<Placement dx="0" dy="35"/>
<Placement dx="50" />
<Placement dx="100"/>
</ShieldSymbolizer>

This syntax is not optimal but an placement algorithm supporting grid placements will be added some time.

Installation

Download and install harfbuzz:

wget http://www.freedesktop.org/software/harfbuzz/release/harfbuzz-0.9.4.tar.bz2
tar -xjf harfbuzz-0.9.4.tar.bz2
cd harfbuzz-0.9.4/
./configure "ICU_CFLAGS=`icu-config --cflags`" "ICU_LIBS=`icu-config --ldflags`"
make

and as root

make install

Download and install mapnik

git clone -b harfbuzz --depth 1 git://github.com/mapnik/mapnik.git mapnik-harfbuzz
cd mapnik-harfbuzz
./configure
make

and as root

make install # Warning this overwrites previous mapnik installations!

Stamen, Compositing, and Mapnik 2.1

2012-08-27T00:00:00-07:00

What if software existed that combined the power of Photoshop-like image effects with Illustrator-like vector transformations that was fully open source, spatially capable, and could handle big data like OpenStreetMap? Well, hopefully this future will feel near as you start using Mapnik 2.1.

A compositing framework in core

In time, Mapnik 0.7.x added support for blending modes in rasters thanks to the work of Marcin Rudowski. And as of last week, with the release of Mapnik 2.1 and a ton of work from Artem, we now support the comp-op property on all symbolizers (and Styles) making compositing possible for both vectors and rasters, together. This new support is a solid framework to build on, and more modes can now easily be added with few code changes.

Thanks Stamen

Our friends at Stamen Design have been advocating for the value of Photoshop-like alpha blending in mapping for many years. As far back as 2008 Mike was already beautifully working around limitations in Mapnik for terrain hillshading and proactively advocating for better support by writing new software like TileStache. Shawn was instrumental in helping me see the viability of compositing in Mapnik by helping sketching out ideas on the Mapnik wiki. Last week I saw Shawn advocating for the full suite of advanced photoshop blend modes in the upcoming CSS Spec, which is awesome and something we can also do in Mapnik.

Revisting innovations

After reflecting on how far we’ve come in Mapnik and thinking of Shawn’s work I was reminded of his sweet little project called Trees, Cabs & Crime where he experimented with rendering three themes of point data and compositing them together using subtractive blending to bring out patterns of correlation.

Now that Mapnik 2.1 is out I figured it should be doable to render Shawn’s exact map with just a single Mapnik stylesheet.

Trees, Cabs & Crime re-rendered in Mapnik 2.1

After finding Shawn’s makefiles I saw the process should be as simple as reading data from three csv files and using a darkening blend mode as the canvas of each layer is rendered. Mapnik 2.1 newly supports reading direct from CSV files and one of the supported comp-op modes is darken, so matching Shawn’s exact output was pretty straightforward. You can find the full Mapnik XML below:

Folloups

And soon after this post Shawn got things working in TileMill 0.10.0 (which uses Mapnik 2.1).

Release 2.1.0

2012-08-24T00:00:00-07:00

The Mapnik team is pleased to announce the Mapnik 2.1 release! It was almost a year in the making and we have tons of new features including:

A new framework for Style level image manipulation called Image filters.
A new pipeline for chained coordinate transformations like clipping or smoothing called Vertex Converters
Compositing modes at Symbolizer and (experimental) Style level. Infinite possibilities from this, see a few examples from AJ.
Support for Style level opacity
WKT, WKB, GeoJSON, SVG parsers and generators that can be used outside of rendering
Data-driven SVG style transforms on svg markers and images thanks to @lightmare
Data-driven orientation for Text, height for Buildings, and width/height for Markers.
A new CSV input plugin
A new GeoJSON input plugin
A new Python input plugin
Better text labeling through support for placement-type="list". See the docs at the bottom of this page.
Improved Map loading speeds as well as warnings and errors

Summary and Changelog

For more details on 2.1 features and fixes see the Summary and the Changelog.

Everyone is recommended to upgrade!

Installing

With this release installing Mapnik has never been easier. For Mac users the popular Homebrew package system already includes Mapnik 2.1. Or, if you don’t want to wait for the compile just grab the one-click 64bit Framework Installer for OS X 10.6 –> 10.8.

For Ubuntu users, we have a PPA ready for you. Simply install Mapnik 2.1 like:

sudo apt-get install -y python-software-properties
echo 'yes' | sudo add-apt-repository ppa:mapnik/v2.1.0
sudo apt-get update
# install core mapnik
sudo apt-get install -y libmapnik mapnik-utils python-mapnik
# install the python binding
sudo apt-get install -y python-mapnik
# confirm mapnik-config returns 2.1.0
mapnik-config -v

And everyone can get the source from the downloads page.

Coming soon

We plan Windows binaries in the next month. We will work to provide two flavors:

Mapnik built with Visual Studio 2008 that will provide python bindings for python.org provided Python 2.6 and 2.7
Mapnik built with Visual Studio 2009 that will provide node.js bindings for nodejs.org provided Node v0.8.x

We also plan an OS X SDK installer (sometime in the next 3-4 months) that will include all headers and dependencies Mapnik uses in order to provide a drop-in development ease for XCode. Note: this SDK may instead target Mapnik 2.2.x development, we’ll see.

Try Tilemill

If you are a TileMill user, or interested in trying it out, the upcoming TileMill 0.10.0 release will use and expose Mapnik 2.1 features. Intrepid OS X and Windows are encouraged to try out the latest TileMill 0.10.x development builds available at the TileMill development snapshots download page.

Thanks!

Thanks to all the contributors and the many companies that have supported and encouraged Mapnik 2.1 development over the past year, notably: kosmosnimki, mapy.cz, mapquest, stamen, cartodb, MapBox, and many more.

Summer of Code 2012 - Collision detection, offsetting, and performance

2012-08-13T00:00:00-07:00

Building on my work from last week I completed several smaller tasks this week. While each task on its own was not very big, together they have lead to a state where almost all tests pass!

Collision detection

The most important part was implementing collision detection for line placements.

First a short description of the old code:

Calculate position of glyph
Store position
Repeat until all characters are processed
Calculate bounding box (requires a lot of the same calculations already done for the position again)
Check for collision
Store bounding box
Repeat for all characters
Updated detector with stored bounding boxes

As one can see this is not very efficient because processing time is wasted when there is a collision on one of the first characters.

The new code therefore does this:

Calculate position of glyph
Store position
Calculate bounding box (using the already computed values)
Check for collision
Store bounding box
Repeat for all characters
Updated detector with stored bounding boxes

This has two advantages:

Position calculations don’t have to be done a second time
If there a collision occurs processing is aborted immediately instead of wasting time processing all following characters

The new detector therefore should be a bit faster in the average case and much faster when there are lots of collisions.

Label position tolerance

This property was very easy to implement, but I think the current approach is not very efficient. When a placement can’t be made at the intended place up to 200(!) slightly different places are tried. This usually means moving the text one pixel and trying again. I think the displacement should grow exponentially. So instead of trying +-1, +-2, +-3, +-4, +-5,… try +-1, +-2, +-4, +-8, +-16, … This would bring a huge increase in performance. I implemented the old behavior because I don’t know if there are any applications which require it.

Offset lines

First I implemented support for dis-placement along the line. This allows you to render text offset from the center of the line. Then I also implemented displacement perpendicular to the line. However I did not use the algorithm from the old code (which estimated the direction an then shifted all characters in the same direction) but instead I produce true offsets using the new parallel line support in master.

The difference can be seen in this picture:

Code for this image: <TextSymbolizer spacing="1" placement="line" dy="-10" vertical-alignment="middle" ...>'Some Text'</TextSymbolizer>

With the old code text touches the line but it keeps the distance perfectly with the new code. Stylesheets using offsets probably need a modification to produce the same results: Up to now Mapnik ignored vertical-alignment for line placements, but the new code uses it. To get the old behavior one has to include vertical-alignment="middle".

Here is an example showing that it also works well with complex scripts:

Code for this image: <TextSymbolizer placement="line" spacing="20" max-char-angle-delta="0" dy="6" ...>"ផ្លូវ១២៣"</TextSymbolizer>

Multi line labels

The offset functionality allowed me to implement multi line labels very efficiently. One can use the same functions for point and line placements now (jalign, wrap-width, wrap-before, embedded newline characters).

Example: Code for this image: <TextSymbolizer placement="line" spacing="20" max-char-angle-delta="0" dy="6" ...>"Hello
World!"</TextSymbolizer>

As one can see sometimes the placement is not perfect, but this only happens for very rare cases (zig-zag-pattern). More common cases (straight lines, circles) are handled correctly. The problem is that there is currently no function to map a point on the original line to the offset line in offset_converter.

Performance tweaks

Profiler output for old versions of Mapnik has shown that during text rendering a lot of time spent is spent in trigonometric functions like sin, cos, and atan2. So instead of calculating theses values several times (IIRC the old code calculated them at least 5 times per character), I store them after the first time. I think even this one calculation could be removed but it would complicate some other things (determining which characters are upside down) so I’m waiting for data saying it is really necessary before doing it.

Grid renderer

As the API is stable now I also reenabled support for grid renderer.

Next steps

Only one big thing is left:

Add support for ShieldSymbolizer

Summer of Code 2012 - Line placements and font sets

2012-08-04T00:00:00-07:00

Last week I implemented point placements for the new HarfBuzz text shaping/rendering code. This week my goal was to implement line placements, but I started with something different:

Font sets

I implemented fonts sets as this was on my TODO list for a long time. Also it was not very hard, but the implementation is different from what the old code did.

Currently Mapnik tries to look up a glyph for each character and if it finds one in the active font is uses this glyph. Otherwise it tries the next font. With HarfBuzz one can’t use this method, as there is no 1:1 character to glyph mapping. One character can produce multiple glyphs and several characters together can result in a single glyph. So the new code instead processes each text run as one unit. (For font selection a run usually is text with a certain script, but there are other parameters, too.)

If no font containing all glyphs for a certain run is found the whole run is suppressed. It could be discussed if it would be better to suppress rendering the whole text, but this behavior is similar to the old one.

Vertex cache

As a next step I looked at the old placement finder code and I was horrified. The main function for line placements was about 200 lines long and you have to spend a very long time to understand what exactly is happening there. One of the biggest problems is that it does all the path processing in the same function as finding the actual placement.

Some background on paths in Mapnik

In Mapnik a path is an object that implements two functions:

void rewind(): Go back to the first point in this path.
unsigned vertex(double &x, double &y): Returns a path command (move to, line to, end) and the coordinates of the associated point.

As one can clearly see it is a nightmare to use this for placement finding. For example you can’t go back a step if you need to. You only can start from the beginning again. While placing glyphs one needs to go forward a certain amount but with these functions one can only go forward one point at a time. One point might be enough but sometimes it is not. So you have to check each time you move forward how many points you have to skip. At the same time you have to make sure not to fall of the end of the path (which might crash the program) and not to process a “move to” command (as no text should be placed across discontinuities in the path).

In order not to get insane while writing the placement finder code I decided to write a class vertex_cache first. This class caches the vertices and adds functions to advance or go back an exactly defined length.

Placement finder

After having created this class writing the placement finder code wasn’t hard anymore. The code for line placements is very similar to the code for point placements. There are some small differences which make it a little bit more difficult:

Rotation angle is dependent on the width of the character at corners (begin and end have to match the line)
Multi-glyph sequences where only the first glyph can be placed normally all other glyphs expect to be placed on a straight line (see this discussion for details)

While working on line placements I decided to add the function requested in bug #614 (Optional disabling auto-upright and selecting which direction is upright). This change shows the advantage of the new clean design: Only a single line in placement finder had to be changed! (Some more lines where needed for loading and saving this attribute from/to XML.)

The current placement finder code doesn’t handle offsets, yet. I don’t want to use fake offsets as in Mapnik master as this can lead to ugly renderings: Instead I will try to render on a line parallel to the path.

Next steps

Add collision detection to line placements
Add support for ShieldSymbolizer

Release 2.0.2

2012-08-03T00:00:00-07:00

The Mapnik team is pleased to announce Mapnik 2.0.2, the second stable bugfix release in the 2.0.x series, and also the last as development is now focused exclusively on the upcoming 2.1.x series (the one that supports compositing).

For details on 2.0.2 fixes see the Changelog.

Get the source from the downloads page.

Note for TileMill users: TileMill currently requires Mapnik >= 2.1.x and will not work with 2.0.2. So, if you are looking for a release for TileMill stay tuned and watch for 2.1 to be released very soon.

Summer of Code 2012 - Point placements

2012-07-31T00:00:00-07:00

This week my code finally has reached a state where everybody interested can try it. After having implemented line breaking and fixing a few bugs last week I implemented the placement finder algorithm for point placements this week.

Placement finder

The placement finder is the component in Mapnik’s rendering stack which takes a list of glyphs and their relative positions and calculates the positions these glyphs should go to. For point placements this isn’t terribly hard. You just place them next to each other and make sure you get character spacing and rotation right. However the old code to do this job was more than 150 lines long. The new code is only about 60 lines of code and it should be much faster.

Collision detection

The old code calculated the bounding box for each char and checked for collision with other text. Now only the bounding box of all text together is used. For point placements the difference between the sum of all individual bounding boxes and the complete bounding box is usually very small.

Let’s have a look at some numbers: Assuming that there are already 20 text placements with an average of 10 characters each and we are trying to place another one we get this:

Old code

Number of items in collision detector: 200
Time (in arbitrary units) for a collision detector check: ln2(200) = 7.6
Number of checks per placement: 10
Total time: 76

New code

Number of items in collision detector: 20
Time (in arbitrary units) for a collision detector check: ln2(20) = 4.3
Number of checks per placement: 1
Total time: 4.3

So the checking takes only 5% of the time it previously did.

Mixed directions

One other advantage of the new code is that it doesn’t explicitly handle RTL text. This is done in earlier stages of the processing. The old code assumed text was either completely LTR or RTL. Rendering text with both directions could work, but didn’t always work.

Line breaking

I also worked on line breaking again, fixing a few bugs – some of which were interesting. For example, I noticed that when the first glyph of a string is longer than the line length my code crashed. The problem here is that it asked ICU’s break iterator for a break position before the first char and it returned if there is none. As it turns out, the return value for a non-existent break is INT_MAX-1 leading to an out-of-memory error.

I also implemented forced line breaks (via “\n” chars).

Test results

Most visual tests return similar results to the reference images, however automatic testing fails because the images aren’t identical. HarfBuzz chooses different (better) character positions than our simple approach in the old code did. The rendering quality for small font sizes has drastically improved (see also bug #1290):

If you look closely you will also notice that the character spacing is distributed much better now.

I also discovered a bug in Mapnik master: RTL text is placed a the wrong position:

Distance should be at least 16 pixels

Left: old (wrong), right: new (correct)

Next steps

Debug symbolizer

Currently I’m working on adding a new symbolizer type which simply draws all the collision detection bounding boxes. This should help verifying that the calculations are actually correct and no annoying bugs turn up later.

Line placement

After that I will work on adding line placements to placement finder. This is not trivial but I will try to split the job into smaller parts so the code is easy to understand and bugs are less likely.

Summer of Code 2012 - Line breaking

2012-07-22T00:00:00-07:00

Yet an other week has passed and a lot of things have happened since my Summer of Code half-time post:

Itemizer

I noticed that the rendering I got from the text in bug #519 was totally wrong. I tracked it down to ICU’s bidi algorithm which returns text runs in visual order but I assumed they would be in logical order. Therefore all my offsets were wrong. Returning the runs in visual order makes much more sense as no further reordering is necessary. While working on the itemizer I also updated it to operate on parts of the input text for processing lines after line breaking.

This brings me to the next topic:

Line breaking

I finally got line breaking done. It was easier than I originally thought because I had the idea that I don’t need a 1:1 character to glyph width mapping. It is enough when I know how wide the sum of all characters forming a glyph cluster is. Now I build a map which assigns the sum of the width of all glyphs forming a cluster to the first character of this cluster. All other characters get a width of zero.

After this map is built line breaking is pretty straight forward. Sum all widths till the length is longer than the maximum length, then find the last or next break position and break the line.

Afterwards reshape each line to get a correct rendering.

Kerning

I noticed small differences in glyph spacing between texts rendered with Mapnik trunk and this branch. I found the cause of this behavior:

HarfBuzz uses the kerning tables in the fonts and produces better spacing.

Before and after example:

Infrastructure work

I removed almost all code from the old text rendering system. It had grown from a simple solution to a complex, hard to maintain one. The new system should be much easier to understand.

HarfBuzz

HarfBuzz also has made large steps last week. There was a hackfest in Toronto and problems with Indic languages were addressed. After the hackfest was over the failure rates for the following languages were down to less than 0.19%. Before they were as high as 87.7% (Khmer).

Amil
Telugu
Gujarati
Oriya
Devanagari
Gurmukhi
Bengali
Kannada
Malayalam
Khmer
Sinhala

Next steps

Next week I will reimplement as much as possible of the placement finder functionality.

Summer of Code 2012 - Half time

2012-07-13T00:00:00-07:00

After half of this year’s Summer of Code is over I have the first real results to present you:

Text rendering works now and serveral bugs seem to be gone. First of all here are some sample images:

Name	Branch
	master	harfbuzz
Bug 1146
Bug 1154
Bug 1208
Ligatures

As you can see the first two bugs are solved and we got ligatures for free. However Khmer rendering (third bug) is still broken, but this is not a problem in Mapnik. HarfBuzz simply doesn’t support Khmer well enough yet. But this should change next week. The nice thing about using HarfBuzz is that we don’t have to care about each script but instead can rely on it to do the job and simply take the glyphs.

The next major bug (#519) isn’t solved yet and is actually worse than what we have in master now because text runs with mixed directions are processed in the wrong order by current code. This will be fixed together with line breaking as the problem is in the same area (wrong ordering of text runs).

Next steps

I will try to solve line breaking this week. Probably this will be all I do as line breaking is hard (see last post for details).

Other things that need to be done

Automatic font selection (aka fontsets)
Reimplement placement finder to work with new code (currently it’s only a stub)

Update

All Khmer tests provided by Github user nirvn render correctly with current HarfBuzz and a small fix in Mapnik. I don’t upload example images here because the rendering looks exactly like the reference renderings.