Consider adding bidi support for text rendering

[traianstanev]

Currently we can only draw left to right text as labels and legend. There have been requests for Hebrew support that we could add without too much effort. Setting severity to minor since I have only seen two requests for this -- I'm sure it's pretty major for the people who need this feature though.

NOTE: There is a nice freeware bidi string rearranging utility by NMSU, available at:

 http://crl.nmsu.edu/~mleisher/ucdata.html

It can be easily plugged into the RS_FontEngine to provide optional string reordering.

[jbirch]

I'm getting a 404 on that page. It's still in Google's cache, but the zipfiles, etc are no longer there.

[traianstanev]

I have the files. It must be down temporarily or something... it was fine a couple of days ago.

[waltweltonlair]

Fix #271 (Consider adding bidi support for text rendering)

This submission r3936 adds BIDI support for text rendering. Labels and symbols containing bi-directional character sequences will now render correctly.

A new BIDIConverter class is added to the Stylization project. It takes a bi-directional unicode string as input and creates a LTR ordering of that string for display purposes. The class was written by Troy, and here are some additional notes he provided regarding it:

It is a complete solution include glyph shaping. I took special care in making sure the code is stable. I’ve run through millions of string conversions without a problem and have just completed a 30 million string test with randomly constructed strings ranging from 1-100 characters. (We’re also free of any memory leaks although I can’t really take credit for that since I use mostly std stuff which does the memory management). In release mode it can process roughly 20,000 reasonably sized (in my test case about 55 characters and 3 language swaps) strings a second.

Integration of the converter primarily happens in the MapGuide renderer implementations of MeasureString and DrawString: before measuring or drawing a string we convert it to LTR format. Labels for point and polygon features are then rendered correctly, as well as symbols containing text elements. However this is not sufficient for path labels - labels which follow the contours of polyline features. Path labels are handled by splitting them into individual characters and positioning each character along the feature (RSFontEngine.LayoutPathText performs this work). To support BIDI strings, the path label therefore needs to be converted before LayoutPathText is called. This is done in the LabelRenderer and LabelRendererLocal classes in Stylization.

I did some performance testing of the updated code, and a couple of factors will affect the results:

• the number of labels in your map
• the type of labels in your map (path labels or point/polygon labels)
• whether the labels actually contain bi-directional character sequences

Test 1: On a tiled map that had not-too-dense path labels containing bi-directional strings, the performance impact was about 5%.

Test 2: The server rendering unit test has a map with very dense labels on a polygon layer. It's more of an extreme case. I temporarily changed the test so that all labels contained bi-directional strings, and also made it render the map 100 times to increase measurement precision. The overall time increased by 17% (from 58 seconds to 68 seconds). I then reran the test with the labels changed back to their default English strings, and the increase was only 9% (63 seconds vs. 58 seconds).

For the majority of maps with labels I expect the performance impact to be 5% or less. Of course if you have no labels then there is no impact.

[zspitzer]

Any chance of making this optional via serverconfig.ini?

5% adds up with a large map base and the majority of users will most likely never use this functionality

[waltweltonlair]

• fixed in the trunk stream with submissions r3936, r3937, r3938, r3939
• fixed in the MGOS 2.1 stream with submission r3940
• fixed in the sandbox stream with submission r3941

[waltweltonlair]

Sorry Zach, I'm already burning the midnight oil to get all this crap done for MapGuide. I have no more time left to spend on this stuff.

[zspitzer]

No worries Walt, thanks for your dedication in getting this done.

I have filed an enhancement under #1013

[waltweltonlair]

Fixed Lam-Alef ligature issue:

• fixed in the trunk stream with submission r3990
• fixed in the MGOS 2.1 stream with submission r3991
• fixed in the sandbox stream with submission r3992