Buggy rendering the Persian names with numbers.

[Mesgary]

What steps will reproduce the problem?

1. Find a road with Persian name, having both alphabetic and numbers in the road name. For example "Golestan Dead End" in "Marzdaran Boulevard" of "IRAN, Tehran" can be a choice.
2. Download the area to JOSM.
3. Be sure that you config "nameOrder" to show 'name' tag value instead of 'name:en'. (in case of Persian name in 'name' tag)
4. Zoom the the road, until you see the road name.

What is the expected result?

You should see the name of "Golestan 2 Dead End" as 'گلستان ۲'

What happens instead?

You see the name of "Golestan 2 Dead End" as something like '۲ ن‌اتسلگ' (in the reverse order of original)

Please provide any additional information below. Attach a screenshot if possible.

I checked the 8800 revision and the bug was there too.
For comparing the right name and buggy rendered name you can check the string on the road with the data seen on "Tags/Membership" box by selecting the road.

Revision: 8964
Repository Root: http://josm.openstreetmap.de/svn
Relative URL: ^/trunk
Last Changed Author: simon04
Last Changed Date: 2015-10-27 23:40:20 +0100 (Tue, 27 Oct 2015)
Build-Date: 2015-10-28 02:32:10
URL: http://josm.openstreetmap.de/svn/trunk
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last Changed Rev: 8964

Identification: JOSM/1.5 (8964 en) Mac OS X 10.11
Memory Usage: 397 MB / 910 MB (226 MB allocated, but free)
Java version: 1.8.0_60, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
VM arguments: [-Djava.library.path=/Applications/JOSM.app/Contents/MacOS, -DLibraryDirectory=/Users/mesgary/Library, -DDocumentsDirectory=/Users/mesgary/Documents, -DApplicationSupportDirectory=/Users/mesgary/Library/Application Support, -DCachesDirectory=/Users/mesgary/Library/Caches, -DSandboxEnabled=false, -Dapple.laf.useScreenMenuBar=true, -Dcom.apple.macos.use-file-dialog-packages=true, -Dcom.apple.macos.useScreenMenuBar=true, -Dcom.apple.mrj.application.apple.menu.about.name=JOSM, -Dcom.apple.smallTabs=true]

Plugins:
- measurement (31694)

[Mesgary]

nameOrder

[Mesgary]

"Golestan 2 Dead End" with Persian label in the map (buggy one) and correct value in 'Tags/Memebership' area

[Don-vip]

Replying to mesgary@…:

You should see the name of "Golestan 2 Dead End" as 'گلستان ۲'

Thanks for reporting the issue. As we are all left-to-right language-speaking, this is quite hard for us to notice such problems.

Just a confirmation to be sure I understand well: '۲' is the character for the number '2', it should be on the left of the word 'گلستان', which is iself written in reversed order: the wording displayed in the tags/membership is OK, right?

[Mesgary]

Yes you are right. '۲' is Persian character for '2' and it should be seen on the left side of the name as you can see in the "Tags/Memberships" area.

[Don-vip]

Paul, I'd like your opinion on the best way to allow dynamic changes of mappaint.nameOrder.
I came up with two solutions. I personnaly prefer first one, but that goes against what you specified in r3987. What was the reason behind denying the strategy to listen to preference changes? It's a constant singleton.

First solution:

src/org/openstreetmap/josm/gui/mappaint/LabelCompositionStrategy.java

@@ -7 +7 @@
 import java.util.List;
 
 import org.openstreetmap.josm.Main;
+import org.openstreetmap.josm.data.Preferences.PreferenceChangeEvent;
+import org.openstreetmap.josm.data.Preferences.PreferenceChangedListener;
 import org.openstreetmap.josm.data.osm.OsmPrimitive;
 import org.openstreetmap.josm.tools.LanguageInfo;
 
@@ -147 +149 @@
         }
     }
 
-    public static class DeriveLabelFromNameTagsCompositionStrategy extends LabelCompositionStrategy {
+    public static class DeriveLabelFromNameTagsCompositionStrategy
+        extends LabelCompositionStrategy implements PreferenceChangedListener {
 
         /**
          * The list of default name tags from which a label candidate is derived.
@@ -175 +178 @@
 
         /**
          * <p>Creates the strategy and initializes its name tags from the preferences.</p>
-         *
-         * <p><strong>Note:</strong> If the list of name tags in the preferences changes, strategy instances
-         * are not notified. It's up to the client to listen to preference changes and
-         * invoke {@link #initNameTagsFromPreferences()} accordingly.</p>
-         *
          */
         public DeriveLabelFromNameTagsCompositionStrategy() {
             initNameTagsFromPreferences();
@@ -295 +293 @@
         public String toString() {
             return "{" + getClass().getSimpleName() +'}';
         }
+
+        @Override
+        public void preferenceChanged(PreferenceChangeEvent e) {
+            if (e.getKey() != null && e.getKey().startsWith("mappaint.name")) {
+                initNameTagsFromPreferences();
+            }
+        }
     }
 }

Second solution:

src/org/openstreetmap/josm/data/osm/visitor/paint/MapPaintSettings.java

@@ -6 +6 @@
 import org.openstreetmap.josm.Main;
 import org.openstreetmap.josm.data.Preferences.PreferenceChangeEvent;
 import org.openstreetmap.josm.data.Preferences.PreferenceChangedListener;
+import org.openstreetmap.josm.gui.mappaint.LabelCompositionStrategy.DeriveLabelFromNameTagsCompositionStrategy;
+import org.openstreetmap.josm.gui.mappaint.TextElement;
 
 /**
  * Global mappaint settings.
@@ -110 +112 @@
     @Override
     public void preferenceChanged(PreferenceChangeEvent e) {
         load();
+        if (TextElement.AUTO_LABEL_COMPOSITION_STRATEGY instanceof DeriveLabelFromNameTagsCompositionStrategy
+                && e.getKey() != null && e.getKey().startsWith("mappaint.name")) {
+            ((DeriveLabelFromNameTagsCompositionStrategy) TextElement.AUTO_LABEL_COMPOSITION_STRATEGY)
+                .initNameTagsFromPreferences();
+        }
     }
 
     /**

[Mesgary]

I have no idea about what you talked in source with Paul, but I should tell you that this isn't about bug of nameOrder. As the road has both Persian label and English label, I had to manually change the order to force the JOSM shows Persian label. I think it will happen also if there is a road with only Persian label with any nameOrder value.
Again I should emphasize that this buggy rendering is only for Persian names with number in it. Other Persian names are rendered correctly. You can see it in that screen shot too. The vertical road named 'گلستان' is OK.

[Don-vip]

Yes, I only noticed that we were forced to restart JOSM to take into account new settings, it should'nt be necessary. I still have no clue about what causes the rendering problem but I understand it :)

[Don-vip]

It's a Java bug I think: ​javabug:6548422

"English text, quotes, and numbers do not render in correct location within Arabic text. Including such characters will also cause the Arabic text to render words in incorrect order."

I also noticed this one if you move the cursor in edit tag dialog: ​javabug:4985267

"For JTextfields that contain numerals and Arabic currency symbols, the cursor loops infinitely between the currency symbol characters and never moves through the digits in the JTextField. This behavior is seen in JTextFields with default Text alignment."

[Don-vip]

Off-topic: I notice ​Persian is poorly translated right now, with only 340 translated strings. New languages are added when they reach at least 2000 translated strings, maybe you could see in Persian-speaking OSM communities if some people are willing to help to the translation effort? ​Arabic is in the same situation.

[Mesgary]

Off-Topic: I checked the translations and I confess that you can not count on it! At least half of those 340 translations should be revised!

Replying to Don-vip:

Off-topic: I notice ​Persian is poorly translated right now, with only 340 translated strings. New languages are added when they reach at least 2000 translated strings, maybe you could see in Persian-speaking OSM communities if some people are willing to help to the translation effort? ​Arabic is in the same situation.

[bastiK]

Replying to Don-vip:

Paul, I'd like your opinion on the best way to allow dynamic changes of mappaint.nameOrder.
I came up with two solutions. I personnaly prefer first one, but that goes against what you specified in r3987.

I prefer the first solution as well.

What was the reason behind denying the strategy to listen to preference changes? It's a constant singleton.

Don't know, as I was applying a patch from someone else. :)

[Don-vip]

OK first one then :) thanks!

[Don-vip]

In 8973/josm:

see #12025 - allow dynamic changes of mappaint.nameOrder

[bastiK]

The problem is the change in writing order. It is a known limitation. At the moment we cannot display text along a way that is both left-to-right and right-to-left (see comment:13:ticket:11194).

Take for example "گلستان۲۳۴". The order of characters can be seen in this ​tool. It first lists the letters of "گلستان" from right to left, then the numbers "۲۳۴" from left to right. I would suggest to keep #11194 closed and this one open to find a fix for the problem. (Link to source code​)

[bastiK]

In 8994/josm:

fixed #12025 - text along line rendering for bi-directional text

[bastiK]

I feel like this is a feature that should be provided by the Java runtime. Anyway, let's hope this works. :)

[Don-vip]

We could use your code to submit to Oracle a small Java example demonstrating the problem for ​javabug:6548422

[bastiK]

Replying to Don-vip:

We could use your code to submit to Oracle a small Java example demonstrating the problem for ​javabug:6548422

I cannot find the sample text in the Java bug report, which makes it impossible to reproduce. If I understand Mesgary correctly, the display of the text elements on the right hand side is okay, just the rendering in the main map area was broken. In ​javabug:6548422, problems with the Java text elements (JTextPane) are reported, so this seems unrelated in any case.

[Don-vip]

Ok so we could create a new bug :)

[Mesgary]

Yes you are right. Only the rendering over the lines of the way in the left side (map area) is buggy (when the name is in Persian and there is numbers in it)

Replying to bastiK:

Replying to Don-vip:

We could use your code to submit to Oracle a small Java example demonstrating the problem for ​javabug:6548422

I cannot find the sample text in the Java bug report, which makes it impossible to reproduce. If I understand Mesgary correctly, the display of the text elements on the right hand side is okay, just the rendering in the main map area was broken. In ​javabug:6548422, problems with the Java text elements (JTextPane) are reported, so this seems unrelated in any case.

[Mesgary]

I didn't understand why did you closed this bug and set to fixed? Do you mean that this is a bug from Java? So you only should close it and you should set it to fixed!

Replying to bastiK:

In 8994/josm:

fixed #12025 - text along line rendering for bi-directional text

[bastiK]

It is fixed in version 8994 which will be available for download tomorrow as latest development version. The fix will also be included in the next regular release (expected in about a month). I'd appreciate testing and feedback.

[bastiK]

Replying to Don-vip:

Ok so we could create a new bug :)

There isn't really a bug, it would be a feature request.

[Don-vip]

Replying to bastiK:

There isn't really a bug, it would be a feature request.

OK we have more important bug requests then. I'll remove ​javabug:6548422 from JavaBugs but keep ​javabug:4985267 as it is very disturbing.

[Mesgary]

I am on Mac and the "Mac OS X package" is now at version 8969. I will inform you as soon as it is updated to a newer version.

Replying to bastiK:

It is fixed in version 8994 which will be available for download tomorrow as latest development version. The fix will also be included in the next regular release (expected in about a month). I'd appreciate testing and feedback.

[Don-vip]

You can use this pacckage: jenkins/job/JOSM/jdk=JDK8/lastStableBuild/artifact/dist/josm-custom-macosx.zip

[Mesgary]

It works fine for me now with this version. Do you need an screenshot?

Revision: 9003
Is-Local-Build: true
Build-Date: 2015-11-12 01:00:42

Identification: JOSM/1.5 (9003 SVN en) Mac OS X 10.11
Memory Usage: 383 MB / 910 MB (112 MB allocated, but free)
Java version: 1.8.0_60, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
VM arguments: [-Djava.library.path=/Applications/JOSM.app/Contents/MacOS, -DLibraryDirectory=/Users/mesgary/Library, -DDocumentsDirectory=/Users/mesgary/Documents, -DApplicationSupportDirectory=/Users/mesgary/Library/Application Support, -DCachesDirectory=/Users/mesgary/Library/Caches, -DSandboxEnabled=false, -Dapple.laf.useScreenMenuBar=true, -Dcom.apple.macos.use-file-dialog-packages=true, -Dcom.apple.macos.useScreenMenuBar=true, -Dcom.apple.mrj.application.apple.menu.about.name=JOSM, -Dcom.apple.smallTabs=true]
Dataset consistency test: No problems found

Plugins:
- measurement (31694)

Replying to Don-vip:

You can use this pacckage: jenkins/job/JOSM/jdk=JDK8/lastStableBuild/artifact/dist/josm-custom-macosx.zip

[bastiK]

Replying to mesgary@…:

It works fine for me now with this version. Do you need an screenshot?

No, it's fine. Thanks for reporting and testing!