Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

#271 closed enhancement (fixed)

Consider adding bidi support for text rendering

Reported by: traianstanev Owned by: waltweltonlair
Priority: medium Milestone: 2.1
Component: Rendering Service Version: 2.1.0
Severity: minor Keywords:
Cc: External ID: 1177389


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:

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

Change History (12)

comment:1 Changed 10 years ago by jbirch

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

comment:2 Changed 10 years ago by traianstanev

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

comment:3 Changed 9 years ago by waltweltonlair

Milestone: 2.1
Owner: changed from traianstanev to waltweltonlair
Priority: lowmedium
Version: 2.1.0

comment:4 Changed 9 years ago by waltweltonlair

Status: newassigned

comment:5 Changed 9 years ago by 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.

comment:6 Changed 9 years ago by 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

comment:7 Changed 9 years ago by waltweltonlair

Resolution: fixed
Status: assignedclosed
  • 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

comment:8 Changed 9 years ago by 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.

comment:9 Changed 9 years ago by zspitzer

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

I have filed an enhancement under #1013

comment:10 Changed 9 years ago by waltweltonlair

Keywords: 1177389 added

comment:11 Changed 9 years ago by waltweltonlair

External ID: 1177389
Keywords: 1177389 removed

comment:12 Changed 9 years ago by 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
Note: See TracTickets for help on using tickets.