Modify

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#12025 closed defect (fixed)

Buggy rendering the Persian names with numbers.

Reported by: Mesgary Owned by: team
Priority: normal Milestone: 15.11
Component: Core mappaint Version:
Keywords: template_report i18n right-to-left javabug bidi Cc: bastiK

Description (last modified by Don-vip)

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)

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

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)

Attachments (2)

Screen Shot 1394-08-07 at 19.26.36.png (34.7 KB) - added by Mesgary 4 years ago.
nameOrder
Screen Shot 1394-08-07 at 19.26.05.png (140.8 KB) - added by Mesgary 4 years ago.
"Golestan 2 Dead End" with Persian label in the map (buggy one) and correct value in 'Tags/Memebership' area

Download all attachments as: .zip

Change History (30)

Changed 4 years ago by Mesgary

nameOrder

Changed 4 years ago by Mesgary

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

comment:1 Changed 4 years ago by Don-vip

Component: CoreCore mappaint
Description: modified (diff)
Keywords: i18n right-to-left added

comment:2 in reply to:  description Changed 4 years ago by 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?

comment:3 Changed 4 years ago by 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.

comment:4 Changed 4 years ago by Don-vip

Cc: bastiK added

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

     
    77import java.util.List;
    88
    99import org.openstreetmap.josm.Main;
     10import org.openstreetmap.josm.data.Preferences.PreferenceChangeEvent;
     11import org.openstreetmap.josm.data.Preferences.PreferenceChangedListener;
    1012import org.openstreetmap.josm.data.osm.OsmPrimitive;
    1113import org.openstreetmap.josm.tools.LanguageInfo;
    1214
     
    147149        }
    148150    }
    149151
    150     public static class DeriveLabelFromNameTagsCompositionStrategy extends LabelCompositionStrategy {
     152    public static class DeriveLabelFromNameTagsCompositionStrategy
     153        extends LabelCompositionStrategy implements PreferenceChangedListener {
    151154
    152155        /**
    153156         * The list of default name tags from which a label candidate is derived.
     
    175178
    176179        /**
    177180         * <p>Creates the strategy and initializes its name tags from the preferences.</p>
    178          *
    179          * <p><strong>Note:</strong> If the list of name tags in the preferences changes, strategy instances
    180          * are not notified. It's up to the client to listen to preference changes and
    181          * invoke {@link #initNameTagsFromPreferences()} accordingly.</p>
    182          *
    183181         */
    184182        public DeriveLabelFromNameTagsCompositionStrategy() {
    185183            initNameTagsFromPreferences();
     
    295293        public String toString() {
    296294            return "{" + getClass().getSimpleName() +'}';
    297295        }
     296
     297        @Override
     298        public void preferenceChanged(PreferenceChangeEvent e) {
     299            if (e.getKey() != null && e.getKey().startsWith("mappaint.name")) {
     300                initNameTagsFromPreferences();
     301            }
     302        }
    298303    }
    299304}

Second solution:

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

     
    66import org.openstreetmap.josm.Main;
    77import org.openstreetmap.josm.data.Preferences.PreferenceChangeEvent;
    88import org.openstreetmap.josm.data.Preferences.PreferenceChangedListener;
     9import org.openstreetmap.josm.gui.mappaint.LabelCompositionStrategy.DeriveLabelFromNameTagsCompositionStrategy;
     10import org.openstreetmap.josm.gui.mappaint.TextElement;
    911
    1012/**
    1113 * Global mappaint settings.
     
    110112    @Override
    111113    public void preferenceChanged(PreferenceChangeEvent e) {
    112114        load();
     115        if (TextElement.AUTO_LABEL_COMPOSITION_STRATEGY instanceof DeriveLabelFromNameTagsCompositionStrategy
     116                && e.getKey() != null && e.getKey().startsWith("mappaint.name")) {
     117            ((DeriveLabelFromNameTagsCompositionStrategy) TextElement.AUTO_LABEL_COMPOSITION_STRATEGY)
     118                .initNameTagsFromPreferences();
     119        }
    113120    }
    114121
    115122    /**

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

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

comment:7 Changed 4 years ago by Don-vip

Keywords: javabug added

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."

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

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

comment:10 in reply to:  4 Changed 4 years ago by 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. :)

comment:11 Changed 4 years ago by Don-vip

OK first one then :) thanks!

comment:12 Changed 4 years ago by Don-vip

In 8973/josm:

see #12025 - allow dynamic changes of mappaint.nameOrder

comment:13 Changed 4 years ago by 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)

comment:14 Changed 4 years ago by bastiK

Resolution: fixed
Status: newclosed

In 8994/josm:

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

comment:15 Changed 4 years ago by bastiK

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

comment:16 Changed 4 years ago by Don-vip

Keywords: bidi added
Milestone: 15.11

comment:17 Changed 4 years ago by Don-vip

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

comment:18 in reply to:  17 ; Changed 4 years ago by 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.

comment:19 Changed 4 years ago by Don-vip

Ok so we could create a new bug :)

comment:20 in reply to:  18 Changed 4 years ago by 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.

comment:21 in reply to:  14 Changed 4 years ago by 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

comment:22 Changed 4 years ago by 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.

comment:23 in reply to:  19 ; Changed 4 years ago by 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.

comment:24 in reply to:  23 Changed 4 years ago by 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.

comment:25 in reply to:  22 Changed 4 years ago by 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.

comment:27 in reply to:  26 ; Changed 4 years ago by 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

comment:28 in reply to:  27 Changed 4 years ago by 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!

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.