#10446 closed defect (fixed)
Strange Text all over display
Reported by: | Owned by: | team | |
---|---|---|---|
Priority: | normal | Milestone: | 14.08 |
Component: | Core mappaint | Version: | |
Keywords: | template_report | Cc: | cquest, Stereo |
Description (last modified by )
What steps will reproduce the problem?
- Load an area with many paths or roads, and JOSM leaves text artifacts all over the page
What is the expected result?
- There shouldn't be street names randomlly displayed on the screen (See attached screenshot)
What happens instead?
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)
Change History (21)
by , 10 years ago
comment:1 by , 10 years ago
Description: | modified (diff) |
---|
comment:2 by , 10 years ago
Component: | Core → Core mappaint |
---|---|
Milestone: | → 14.08 |
comment:3 by , 10 years ago
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/
follow-up: 5 comment:4 by , 10 years ago
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).
follow-up: 6 comment:5 by , 10 years ago
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 by , 10 years ago
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.
follow-up: 9 comment:7 by , 10 years ago
follow-up: 10 comment:9 by , 10 years ago
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.
comment:10 by , 10 years ago
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 likeINFO: 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
follow-up: 13 comment:11 by , 10 years ago
@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 by , 10 years ago
@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 by , 10 years ago
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 by , 10 years ago
Cc: | added |
---|
comment:17 by , 10 years ago
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
).
Screenshot showing problem