icons are displayed different

[Klumbumbus]

The display of all office icons and the icon for highway=pedestrian (maybe more) changed their appearance (blue and grey bodies turned into black bodies)
This seems to be a regression of #9995.
r10504 is ok while r10505 is not ok for me (while always having set gui.scale to 1)

With current latest r10533 the body is always black (with gui.scale 1, 1.0 or 0).

screen is 1680*1050 22" (standard resolution)

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2016-07-15 19:08:39 +0200 (Fri, 15 Jul 2016)
Build-Date:2016-07-16 01:32:16
Revision:10533
Relative:URL: ^/trunk

Identification: JOSM/1.5 (10533 de) Windows 7 32-Bit
Memory Usage: 247 MB / 742 MB (106 MB allocated, but free)
Java version: 1.8.0_91-b14, Oracle Corporation, Java HotSpot(TM) Client VM
VM arguments: [-Djava.security.manager, -Djava.security.policy=file:<java.home>\lib\security\javaws.policy, -DtrustProxy=true, -Djnlpx.home=<java.home>\bin, -Djnlpx.origFilenameArg=C:\Program Files\josm-latest-bla.jnlp, -Djnlpx.remove=false, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlpx.heapsize=256m,768m, -Djnlpx.splashport=54281, -Djnlpx.jvm=<java.home>\bin\javaw.exe, -Djnlpx.vmargs=LURqYXZhLnV0aWwuQXJyYXlzLnVzZUxlZ2FjeU1lcmdlU29ydD10cnVlAA==]
Dataset consistency test: No problems found

Plugins:
- AddrInterpolation (32584)
- DirectDownload (32442)
- DirectUpload (32329)
- HouseNumberTaggingTool (32584)
- Mapillary (32639)
- OpeningHoursEditor (32583)
- Tracer2 (32474)
- apache-commons (32584)
- apache-http (32584)
- buildings_tools (32639)
- editgpx (32485)
- imagery_offset_db (32528)
- log4j (32309)
- measurement (32454)
- photo_geotagging (32392)
- photoadjust (32584)
- pt_assistant (32656)
- reverter (32584)
- tag2link (32326)
- tagging-preset-tester (32584)
- terracer (32426)
- todo (29154)
- turnlanes-tagging (1468266519)
- turnrestrictions (32629)
- undelete (32584)
- utilsplugin2 (32584)
- wikipedia (32654)

Tagging presets:
- D:\<user.name>\OSM\JOSMSVN\data\defaultpresets.xml
- D:\<user.name>\OSM\TestNew\newpresets.xml
- http://zibi.openstreetmap.org.pl/kendzi/k/Simple3dPreset/s3db-preset.zip
- https://josm.openstreetmap.de/josmfile?page=Presets/AdvertisingPreset&zip=1
- https://josm.openstreetmap.de/josmfile?page=Presets/NewTags&zip=1
- https://josm.openstreetmap.de/josmfile?page=Presets/OneClick&zip=1
- https://josm.openstreetmap.de/josmfile?page=Presets/StolpersteineLight&zip=1

Map paint styles:
- D:\<user.name>\OSM\JOSMSVN\styles\standard\elemstyles.mapcss
- D:\<user.name>\OSM\TestNew\newicons.mapcss
- D:\<user.name>\OSM\eigene styles\PriorityRoad\PriorityRoad_1.0.mapcss
- D:\<user.name>\OSM\eigene styles\SpecificBuildingValues\SpecificBuildingValues.mapcss
- D:\<user.name>\OSM\eigene styles\Tourenplanung.mapcss
- D:\<user.name>\OSM\eigene styles\area-symbol.zip
- D:\<user.name>\OSM\patches\old MPs\dataquality.mapcss
- http://www.freietonne.de/ft_icons/josm/FreieTonne_rules_presets_zip.php
- http://www.openrailwaymap.org/styles/standard.mapcss
- https://github.com/bastik/mapcss-tools/raw/osm/mapnik2mapcss/osm-results/mapnik.zip
- https://josm.openstreetmap.de/josmfile?page=Styles/AdvertisingStyle&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Coloured_Streets&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Coloured_buildings&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Cycleways&style&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/DestinationSignRelation&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/HiDPISupport&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Incline&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Lane_and_Road_Attributes&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/LayerChecker&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Lit&style&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/LitObjects&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Maxspeed&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/MaxspeedIcons&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Modified&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/NewHighwayColors&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Osmc&style&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/PTStops&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/ParkingLanes&style&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/ParkingLanes&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/ShowID&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Sidewalks&style&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Surface&style&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/sac_scale&zip=1
- https://raw.githubusercontent.com/species/josm-preset-wheelchair/master/sidewalks_kerbs.mapcss

Validator rules:
- D:\<user.name>\OSM\TestNew\new.validator.mapcss
- https://raw.githubusercontent.com/stefan-a-bauer/josm-validators/master/mtb.validator.mapcss

Last errors/warnings:
- W: Datei <josm.cache>\tiles\TMS_BLOCK.key kann nicht gelöscht werden
- W: Datei <josm.cache>\tiles\TMS_BLOCK.data kann nicht gelöscht werden
- W: Datei <josm.cache>\tiles\TMS_INDEX.key kann nicht gelöscht werden
- W: Datei <josm.cache>\tiles\TMS_INDEX.data kann nicht gelöscht werden
- W: Datei <josm.cache>\tiles\TMS_INDEX_v2.key kann nicht gelöscht werden
- W: Datei <josm.cache>\tiles\TMS_INDEX_v2.data kann nicht gelöscht werden
- W: Old style SideButton usage for action org.openstreetmap.josm.plugins.todo.TodoDialog$SelectAction@19d1bf3
- W: Old style SideButton usage for action org.openstreetmap.josm.plugins.todo.TodoDialog$AddAction@1bd2843
- W: Old style SideButton usage for action org.openstreetmap.josm.plugins.todo.TodoDialog$PassAction@26faa1
- W: Old style SideButton usage for action org.openstreetmap.josm.plugins.todo.TodoDialog$MarkAction@e7e794

[stoecker]

That must have another reason. Tested here with most recent and they are blue. Also I can't think of a single change that could produce such an effect.

Can you check again if there is a setting or something else which does really produce this effect?

[Klumbumbus]

I just deleted preferences.xml so it created a new one. Same problem.

[stoecker]

Someone else who can reproduce?

[Don-vip]

this looks like caused by the server upgrade and the ​need to rebuild svgcleaner from sources. Only official jars are concerned, not SVN ones.

[Don-vip]

As ​svgcleaner seems unmaintained, I'll try to switch to ​https://github.com/svg/svgo

[Klumbumbus]

Replying to Don-vip:

this looks like caused by the server upgrade and the ​need to rebuild svgcleaner from sources. Only official jars are concerned, not SVN ones.

That sounds more likely.

• josm-custom.jar from jenkins are ok
• josm-testet.jar (10526) from josm download is not ok
• josm-latest.jar (10547) from josm download is not ok
• josm-latest.jnlp (10547) from josm download is not ok

[stoecker]

I tried svgo before. That's not really usable.

[stoecker]

svgcleaner in 10504 (added line breaks)

[stoecker]

svgcleaner in 10505 (added line breaks)

[stoecker]

svgcleaner in 10504 (added line breaks) - error fixed

[stoecker]

The error is a missing fill in a path:

.svg

@@ -11 +11 @@
 <path d="m7 1042.36h1v1h-1z"/>
 <path d="m2 1044.36h1v1h-1z"/>
 </g>
-<path d="m11.03 1039.36c-.571 0-1.031.536-1.031 1.203v.685c0 .013 0 .026 0 .039v4.073c-.009.751.963.751.954 0v-3.958h.491v10.235c-.012.966 1.238.966 1.226 0v-6.278h.607v6.278c-.012.966 1.238.966 1.226 0v-10.235h.541v3.958c-.009.751.963.751.954 0v-4.797c0-.666-.461-1.202-1.032-1.202z"/>
+<path d="m11.03 1039.36c-.571 0-1.031.536-1.031 1.203v.685c0 .013 0 .026 0 .039v4.073c-.009.751.963.751.954 0v-3.958h.491v10.235c-.012.966 1.238.966 1.226 0v-6.278h.607v6.278c-.012.966 1.238.966 1.226 0v-10.235h.541v3.958c-.009.751.963.751.954 0v-4.797c0-.666-.461-1.202-1.032-1.202z" fill="#3771c8"/>
 </g>
 <ellipse fill="#3771c8" cx="13" cy="1037.57" rx="1.204" ry="1.204"/>
 <g color-rendering="auto" color-interpolation-filters="linearRGB" shape-rendering="auto" image-rendering="auto" text-rendering="auto" color-interpolation="sRGB" color="#000">

Original:
10504:
10505:
10505 fixed:

What source did you use to compile the tool? Is it really unmaintained? It improved a lot compared to the version we had before!

Very likely we can simply turn of the option which causes this problem or we fix the issue.

[stoecker]

5 months ago does not look unmaintained for me: ​https://github.com/RazrFalcon/SVGCleaner

[stoecker]

ATM you should use release 0.6.2 instead of latest and we should report this issue.

[stoecker]

Uncleaned

[stoecker]

See ​https://github.com/RazrFalcon/SVGCleaner/issues/31

[Don-vip]

Replying to stoecker:

ATM you should use release 0.6.2

I can't, see ​https://github.com/RazrFalcon/SVGCleaner/issues/29 ==> I had to rebuild a fork who upgraded to QT5.

[Don-vip]

Replying to stoecker:

What source did you use to compile the tool? Is it really unmaintained? It improved a lot compared to the version we had before!

The QT5 fork: ​https://github.com/RazrFalcon/SVGCleaner/pull/30

Last release was 2,5 years ago and maintainer does not seem to want to merge this PR despite the new Ubuntu release that prevents to install it. It fits my personal definition of unmaintained. But if we can workaround the issue, that's great.

[stoecker]

Replying to Don-vip:

Replying to stoecker:

What source did you use to compile the tool? Is it really unmaintained? It improved a lot compared to the version we had before!

The QT5 fork: ​https://github.com/RazrFalcon/SVGCleaner/pull/30

Last release was 2,5 years ago and maintainer does not seem to want to merge this PR despite the new Ubuntu release that prevents to install it. It fits my personal definition of unmaintained. But if we can workaround the issue, that's great.

Half an hour reaction time is far from unmaintained for me. Not everybody feels the release-fast-release-often method of JOSM is best. I also don't use that for all my projects. It depends largely on the application. I have tools with last release in last century and they aren't unmaintained. Today everybody expects permanent activity only to see something... Tsss. :-)

[Don-vip]

Replying to stoecker:

Half an hour reaction time is far from unmaintained for me.

Right :) Now we have the solution, remove all "-inkscape*" properties from source files.

[Don-vip]

In 10554/josm:

fix #13158 - remove -inkscape* properties from SVG files - see ​https://github.com/RazrFalcon/SVGCleaner/issues/31

[bastiK]

We should be careful not to strip properties that are useful for further editing when the svg file is opened in Inkscape.

[Klumbumbus]

see also [o32669]

[Klumbumbus]

So before adding new svg icons we always need to manually check whether the viewbox is correct ([o31865]) and whether no -inkscape* is included. Could that be an automatic task included in the build process, like our own little "pre-svgcleaner" or would that be to much work?
(This would also avoid to strip properties that are useful for further editing.)

[stoecker]

In 10561/josm:

see #13158 - add some sanity checks to geticons script

[stoecker]

The checks results ATM:

File logo exists twice as .svg and .png.
ViewBox has float values for presets/present.svg: 0 0 668.13 692.11
ViewBox has float values for statusline/easting.svg: 0 0 57.207973 57.207977
ViewBox has float values for statusline/northing.svg: 0 0 57.207973 57.207977
File styles/standard/food/restaurant exists twice as .svg and .png.
ViewBox has float values for styles/standard/leisure/billboard.svg: 0 0 976.15625 729.85008
ViewBox has float values for styles/standard/leisure/bird_hide.svg: 0 0 15.999999 15.999999
ViewBox has float values for styles/standard/leisure/casino.svg: 0 0 272.83196 373.82317
ViewBox has float values for styles/standard/leisure/fitness_station.svg: 0 0 495.00113 402.08099
ViewBox has float values for styles/standard/misc/rock.svg: 0 0 16 12.676259
ViewBox has float values for styles/standard/misc/stone.svg: 0 0 12 10.419232
ViewBox has float values for styles/standard/shop/body.svg: 0 0 485.2 493.06
ViewBox has float values for styles/standard/shop/medical_supply.svg: 0 0 152.92334 167.08995
ViewBox has float values for styles/standard/shop/music.svg: 0 0 432.28 432.28
ViewBox has float values for styles/standard/shop/pet.svg: 244.5 110 489 219.9
ViewBox has float values for styles/standard/shop/tattoo.svg: 0 0 581.8125 380.1875
ViewBox has float values for styles/standard/shop/wine.svg: 0 0 115.301 213.549
ViewBox has float values for styles/standard/sport/billiards.svg: 0 0 598.14 598.14
ViewBox has float values for styles/standard/sport/canoe.svg: 0 0 471.17099 413.276
ViewBox has float values for styles/standard/sport/golf.svg: 0 0 479.32132 510.47299
ViewBox has float values for styles/standard/sport/miniature_golf.svg: 0 0 518.44158 510.47299
ViewBox has float values for styles/standard/sport/running.svg: 0 0 289.64 289.64
ViewBox has float values for styles/standard/sport/scuba_diving.svg: 0 0 100 83.101
File styles/standard/transport/bus exists twice as .svg and .png.
ViewBox has float values for styles/standard/misc/landmark/forest.svg: 0 0 1118.8397 1227.8107
ViewBox has float values for styles/standard/misc/landmark/tree_row.svg: 0 0 970.83973 972.18771
ViewBox has float values for styles/standard/misc/landuse/meadow.svg: 0 0 253.87779 244.00716
ViewBox has float values for styles/standard/misc/landuse/orchard.svg: 0 0 670.93 802.78

[stoecker]

Replying to bastiK:

We should be careful not to strip properties that are useful for further editing when the svg file is opened in Inkscape.

Actually inkscape should be more space-saving. What sense has saving a lot of style information about texts to a path elements which has no texts at all. During the bug search my feeling was that the majority of the stored style information actually is useless.

[bastiK]

Replying to stoecker:

Replying to bastiK:

We should be careful not to strip properties that are useful for further editing when the svg file is opened in Inkscape.

Actually inkscape should be more space-saving. What sense has saving a lot of style information about texts to a path elements which has no texts at all. During the bug search my feeling was that the majority of the stored style information actually is useless.

That's true, but "Inkscape SVG" is a bit like .xcf for gimp, i.e. it isn't usually shared, but only stored on the local hard disk.
It may be a good idea to export to plain svg first, before running svg-cleaner:

inkscape -z doctors.svg --export-plain-svg=doctors-plain.svg

[stoecker]

Replying to bastiK:

Replying to stoecker:

Replying to bastiK:

We should be careful not to strip properties that are useful for further editing when the svg file is opened in Inkscape.

Actually inkscape should be more space-saving. What sense has saving a lot of style information about texts to a path elements which has no texts at all. During the bug search my feeling was that the majority of the stored style information actually is useless.

That's true, but "Inkscape SVG" is a bit like .xcf for gimp, i.e. it isn't usually shared, but only stored on the local hard disk.
It may be a good idea to export to plain svg first, before running svg-cleaner:

inkscape -z doctors.svg --export-plain-svg=doctors-plain.svg

As SVG-Cleaner cares for all that stuff (bugs aside) there is no need to do so. The idea is, that SVN stuff is better editable and the JAR is size optimised.

Stripping some of the useless information to workaround the bug seems only a small nuisance to me :-)

[Klumbumbus]

In 10575/josm:

see #13084 - fix preset icon path
see #13158 - fix viewbox of bird_hide icon and rename food court icon

[Klumbumbus]

It seems

        while($f =~ /style\s*=\s*["']([^"']+)["']/g)
        {
          for my $x (split(/\s*;\s*/, $1))
          {
            print STDERR "$ifile: Style starts with minus: $x\n" if $x =~ /^-/;
          }
        }

in geticons.pl doesn't work correctly as there is no warning while we have the grave icon with -inkscape-font-specification in our repo which is invisible within JOSM after cleaning.

[Klumbumbus]

BTW do we use the latest version of svg cleaner? The ​issue for the svg cleaner bug was already closed in august 2016.

[stoecker]

Replying to Klumbumbus:

BTW do we use the latest version of svg cleaner? The ​issue for the svg cleaner bug was already closed in august 2016.

No. We don't. We use the last version in written in C. The author rewrote everything in Rust and compiling with rust is a nightmare ATM.

[stoecker]

In 13384/josm:

see #13158 - fix geticons.pl to no skip some checks

[Klumbumbus]

OK: Thanks.

[Don-vip]

Replying to stoecker:

The author rewrote everything in Rust and compiling with rust is a nightmare ATM.

Do we need to compile it? Maybe we can use ​https://github.com/RazrFalcon/svgcleaner-gui/releases/download/v0.9.3/svgcleaner_linux_x86_64_0.9.3.tar.gz directly.