Modify

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#10446 closed defect (fixed)

Strange Text all over display

Reported by: tony.wroblewski@… Owned by: team
Priority: normal Milestone: 14.08
Component: Core mappaint Version:
Keywords: template_report Cc: cquest, Stereo

Description (last modified by Don-vip)

What steps will reproduce the problem?

  1. Load an area with many paths or roads, and JOSM leaves text artifacts all over the page

What is the expected result?

  1. There shouldn't be street names randomlly displayed on the screen (See attached screenshot)

What happens instead?

Screenshot showing problem

Build-Date: 2014-08-31 10:27:58
Revision: 7473
Is-Local-Build: true

Identification: JOSM/1.5 (7473 SVN en) Mac OS X 10.9.4
Memory Usage: 890 MB / 7282 MB (564 MB allocated, but free)
Java version: 1.7.0_60, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
VM arguments: [-Djava.library.path=/Applications/JOSM.app/Contents/MacOS, -DLibraryDirectory=/Users/tony/Library, -DDocumentsDirectory=/Users/tony/Documents, -DApplicationSupportDirectory=/Users/tony/Library/Application Support, -DCachesDirectory=/Users/tony/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, -D64]
Dataset consistency test: No problems found

Plugins:
- HouseNumberTaggingTool (30416)
- PicLayer (30436)
- Tracer2 (30416)
- buildings_tools (30485)
- conflation (0.1.7)
- contourmerge (1010)
- geotools (30569)
- jts (30416)
- kendzi3d (1.0.179)
- kendzi3d-jogl (37)
- lakewalker (30416)
- log4j (30416)
- opendata (30607)
- osmarender (30416)
- photo_geotagging (30462)
- reverter (30521)
- terracer (30614)
- utilsplugin2 (30460)

Last errors/warnings:
- W: Detected deprecated 'canvas{background-color}' in 'https://github.com/bastik/mapcss-tools/raw/osm/mapnik2mapcss/osm-results/mapnik.zip' which will be removed shortly. Use 'fill-color' instead.

Attachments (4)

bug.jpg (682.5 KB) - added by tony.wroblewski@… 5 years ago.
Screenshot showing problem
Screen Shot 2014-08-31 at 13.52.41.png (21.4 KB) - added by tony.wroblewski@… 5 years ago.
Test Case with r7473
Screen Shot 2014-08-31 at 13.55.17.png (20.5 KB) - added by tony.wroblewski@… 5 years ago.
Same problem with r7469
r7477.png (18.8 KB) - added by tony.wroblewski@… 5 years ago.
r7477, setting "glyph-bug" to false

Download all attachments as: .zip

Change History (21)

Changed 5 years ago by tony.wroblewski@…

Attachment: bug.jpg added

Screenshot showing problem

comment:1 Changed 5 years ago by Don-vip

Description: modified (diff)

comment:2 Changed 5 years ago by Don-vip

Component: CoreCore mappaint
Milestone: 14.08

comment:3 Changed 5 years ago by bastiK

Thanks for reporting the problem! It looks somewhat similar to #7841.

Did you experience the same before the current latest version (in r7439 - r7470)? You can download an earlier version here: http://josm.openstreetmap.de/download/

comment:4 Changed 5 years ago by anonymous

I updated to SVN and built myself this morning. Before that I was running the latest stable release and the problem still occurred (and had for quite a while) there as well (But it now seems worse, i.e. It seemed limited to streams and footpaths, but now it's occurring for roads as well).

comment:5 in reply to:  4 ; Changed 5 years ago by bastiK

We are right before a release, but if you are already having SVN set up, I'm confident, this can be resolved quickly...

Replying to anonymous:

I updated to SVN and built myself this morning. Before that I was running the latest stable release and the problem still occurred (and had for quite a while) there as well (But it now seems worse, i.e. It seemed limited to streams and footpaths, but now it's occurring for roads as well).

I'm not aware of any problems for streams and footpaths in the tested version (7347), could you add a screenshot to illustrate this?

Before we can make any attempt at solving this, we need to know at what stage the problem is first introduced.

Could you please also add a screenshot for the testcase in #7841: 7841testcase.osm
(Most importantly for the current latest version, but also for version 7469.)

comment:6 in reply to:  5 Changed 5 years ago by Don-vip

Replying to bastiK:

Before we can make any attempt at solving this, we need to know at what stage the problem is first introduced.

It might be unrelated to recent style changes but only to the switch of Java 6 to 7. It looks like the Oracle Java 7 implementation has a different behaviour for the glyph bug, and the recent display of highway names makes the problem more visible.

Changed 5 years ago by tony.wroblewski@…

Test Case with r7473

Changed 5 years ago by tony.wroblewski@…

Same problem with r7469

comment:7 Changed 5 years ago by tony

Added both attachments, problem is the same in trunk and also r7469

Also, I downloaded the latest stable r7347 (Didn't build myself), same problem.

comment:8 Changed 5 years ago by bastiK

In 7477/josm:

see #10446 - add switch to override glyph bug test and add debug output in trace debug level

comment:9 in reply to:  7 ; Changed 5 years ago by bastiK

Replying to tony:

Added both attachments, problem is the same in trunk and also r7469

Also, I downloaded the latest stable r7347 (Didn't build myself), same problem.

Thanks! As Vincent said, the problem seems to be unrelated to any JOSM changes that were made since last tested.

We have a special test that detects whether the glyph bug #7841 is present or not, and if it is present, we adapt the formula that calculates the glyph position. If I force my JOSM to think that the bug is present (override the test result), then I get a rendering that is very similar to your screenshots. This probably means that the test gives a false positive in your case.

You can try this by setting the advanced property glyph-bug=false in r7477. It should now look okay. This isn't really meant as a solution however, just to verify my claim. You need to restart after you change this property, it is read only once per session. You will get a message like INFO: Override glyph vector bug: set to value false on the command line, if the override is working.

Changed 5 years ago by tony.wroblewski@…

Attachment: r7477.png added

r7477, setting "glyph-bug" to false

comment:10 in reply to:  9 Changed 5 years ago by tony

Replying to bastiK:

Replying to tony:

Added both attachments, problem is the same in trunk and also r7469

Also, I downloaded the latest stable r7347 (Didn't build myself), same problem.

Thanks! As Vincent said, the problem seems to be unrelated to any JOSM changes that were made since last tested.

We have a special test that detects whether the glyph bug #7841 is present or not, and if it is present, we adapt the formula that calculates the glyph position. If I force my JOSM to think that the bug is present (override the test result), then I get a rendering that is very similar to your screenshots. This probably means that the test gives a false positive in your case.

You can try this by setting the advanced property glyph-bug=false in r7477. It should now look okay. This isn't really meant as a solution however, just to verify my claim. You need to restart after you change this property, it is read only once per session. You will get a message like INFO: Override glyph vector bug: set to value false on the command line, if the override is working.

Thanks, this seems to fix the issue, I've attached a screenshot.

Regards

Tony

comment:11 Changed 5 years ago by bastiK

@Don-vip, @tony: Do you think it is save to assume, that this is consistent for all Mac OS with Java7+? If yes, #7841 would be obsolete and we could remove this workaround entirely. (It is somewhat unsettling, that the test isGlyphVectorDoubleTranslationBug() returns true, but as long as the real code works, we don't need to worry...)

comment:12 Changed 5 years ago by anonymous

@bastiK

I tried this on a second Mac which hasn't been updated in a while, also running Java 7. Same problem on there also. However, I also had this problem in the days back when JOSM would still run on 1.6.

comment:13 in reply to:  11 Changed 5 years ago by Don-vip

Replying to bastiK:

@Don-vip, @tony: Do you think it is save to assume, that this is consistent for all Mac OS with Java7+?

I have asked to cquest and Stereo they confirm the problem on their machine so I'd say we should remove the workaround, yes, and let's see feedback... Very few OSX people use josm latest so we'll know for sure after release of tested anyway.

comment:14 Changed 5 years ago by Don-vip

Cc: cquest Stereo added

comment:15 Changed 5 years ago by Don-vip

And they confirm it's working with glyph-bug=false :)

comment:16 Changed 5 years ago by bastiK

Resolution: fixed
Status: newclosed

In 7478/josm:

fixed #10446 - Strange Text all over display on Mac

comment:17 Changed 5 years ago by bastiK

Okay, great! I've left the broken auto detection code in for now, but it is not executed unless the users sets the pref glyph-bug=auto (default value is false).

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.