Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#9729 closed defect (fixed)

Attribute display involving CJK crashes JOSM

Reported by: jengelh@… Owned by: jengelh@…
Priority: normal Milestone: 15.02
Component: Core Version: tested
Keywords: javabug font Cc:


What steps will reproduce the problem?

  1. Download object 35578845 for example.
  2. Select it.

What is the expected result?
That the key-value pairs are shown in the "Tags / Memberships" window.

What happens instead?
JOSM throws an exception if the "Tags / Memberships" window is enabled.

Please provide any additional information below. Attach a screenshot if

Repository Root:
Build-Date: 2014-01-29 15:23:51
Last Changed Author: Don-vip
Revision: 6767
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last Changed Date: 2014-01-29 16:18:16 +0100 (Wed, 29 Jan 2014)
Last Changed Rev: 6767

Identification: JOSM/1.5 (6767 en) Linux openSUSE 13.1 (Bottle) (x86_64)
Memory Usage: 173 MB / 910 MB (94 MB allocated, but free)
Java version: 1.7.0_51, Oracle Corporation, OpenJDK 64-Bit Server VM
VM arguments: [-Xms64M, -Xmx1024M, -XX:+UseParallelGC, -XX:+UseAdaptiveSizePolicy]
Dataset consistency test: No problems found

java.lang.ArrayIndexOutOfBoundsException: -38795802
	at sun.font.FileFontStrike.getCachedGlyphPtr(
	at sun.font.FileFontStrike.getSlot0GlyphImagePtrs(
	at sun.font.CompositeStrike.getGlyphImagePtrs(
	at sun.font.GlyphList.mapChars(
	at sun.font.GlyphList.setFromString(
	at sun.java2d.pipe.GlyphListPipe.drawString(
	at sun.java2d.pipe.ValidatePipe.drawString(
	at sun.java2d.SunGraphics2D.drawString(
	at sun.swing.SwingUtilities2.drawString(
	at sun.swing.SwingUtilities2.drawStringUnderlineCharAt(
	at javax.swing.plaf.synth.SynthGraphicsUtils.paintText(
	at javax.swing.plaf.synth.SynthGraphicsUtils.paintText(
	at javax.swing.plaf.synth.SynthGraphicsUtils.paintText(
	at javax.swing.plaf.synth.SynthLabelUI.paint(
	at javax.swing.plaf.synth.SynthLabelUI.update(
	at javax.swing.JComponent.paintComponent(
	at javax.swing.JComponent.paint(
	at javax.swing.CellRendererPane.paintComponent(
	at javax.swing.plaf.synth.SynthTableUI.paintCell(
	at javax.swing.plaf.synth.SynthTableUI.paintCells(
	at javax.swing.plaf.synth.SynthTableUI.paint(
	at javax.swing.plaf.synth.SynthTableUI.update(
	at javax.swing.JComponent.paintComponent(
	at javax.swing.JComponent.paint(
	at javax.swing.JComponent.paintChildren(
	at javax.swing.JComponent.paint(
	at javax.swing.JComponent.paintToOffscreen(
	at javax.swing.BufferStrategyPaintManager.paint(
	at javax.swing.RepaintManager.paint(
	at javax.swing.JComponent._paintImmediately(
	at javax.swing.JComponent.paintImmediately(
	at javax.swing.RepaintManager$
	at javax.swing.RepaintManager$
	at Method)
	at javax.swing.RepaintManager.paintDirtyRegions(
	at javax.swing.RepaintManager.paintDirtyRegions(
	at javax.swing.RepaintManager.prePaintDirtyRegions(
	at javax.swing.RepaintManager.access$1100(
	at javax.swing.RepaintManager$
	at java.awt.event.InvocationEvent.dispatch(
	at java.awt.EventQueue.dispatchEventImpl(
	at java.awt.EventQueue.access$200(
	at java.awt.EventQueue$
	at java.awt.EventQueue$
	at Method)
	at java.awt.EventQueue.dispatchEvent(
	at java.awt.EventDispatchThread.pumpOneEventForFilters(
	at java.awt.EventDispatchThread.pumpEventsForFilter(
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(
	at java.awt.EventDispatchThread.pumpEvents(
	at java.awt.EventDispatchThread.pumpEvents(

This is OpenJDK 1.7. I think this may have something to do with rendering Korean text strings, as JOSM seems to work most of the time with Chinese and Japanese (such as with the nearby "place" node.)

Locale, maybe it's relevant

$ locale

Attachments (1)

josm.png (151.5 KB) - added by jengelh@… 6 years ago.

Download all attachments as: .zip

Change History (37)

Changed 6 years ago by jengelh@…

Attachment: josm.png added


comment:1 Changed 6 years ago by bastiK

Same Java version, but no exception here:

Build-Date: 2014-02-16 12:32:50
Revision: 6818
Is-Local-Build: true

Identification: JOSM/1.5 (6818 SVN en) Linux Ubuntu 12.10
Memory Usage: 543 MB / 1763 MB (103 MB allocated, but free)
Java version: 1.7.0_51, Oracle Corporation, OpenJDK 64-Bit Server VM
Java package: openjdk-7-jre:amd64-7u51-2.4.4-0ubuntu0.12.10.2
VM arguments: [-Djosm.home=pref2]
Dataset consistency test: No problems found

Plugin: mirrored_download (30197)

You have key name:ja in the screenshot, but there is no version of the way with this tag, why?

comment:2 Changed 6 years ago by jengelh@…

I had first selected the Panmunjom place object (the house icon), which works. I then selected the building object, which led to the exception being raised and thus the screen update not being drawn correctly.

comment:3 Changed 6 years ago by Don-vip

Looks like specific to OpenSUSE:

Can you try the solution from this thread?

try installing the mstt fonts (install the "fetchmsttfonts" package)

comment:4 Changed 6 years ago by Don-vip

Owner: changed from team to jengelh@…
Status: newneedinfo

comment:5 Changed 6 years ago by jengelh@…

To the best of my knowledge, I already have the MS fonts. Not through fetchmstt, but through properly managed RPM packages I keep for myself.

I know that Arial 3.00 (and also 6.85 from Win8.1) does not contain Korean glyphs; you need to switch to e.g. Arial Unicode MS or Batang. Such theory can be tested for arbitrary fonts using

xterm -fa "Arial" -fd "Arial"

and then attempting to type something, either showing the desired glyph (when using Arial Unicode) or a substitution box (using Arial).

The following recipe thus cures the JOSM/Swing exception, by forcing ArialUni onto every possible program. Doesn't look as good, but I'll figure that one out another day.

mkdir -p ~/.config/fontconfig/fonts.conf
cat >~/.config/fontconfig/fonts.conf <<EOF
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
        <alias binding="same">
                        <family>Arial Unicode MS</family>

Swing could have solved this much nicer :/
I mean, GTK/Qt programs for example can correctly use freetype such that it automatically switches to another font until the glyph is found.

comment:6 Changed 6 years ago by Don-vip

You know much more on this subject than me, could you please create a new bug on and post here the review ID you will then get by mail? WIth a good description there are good chances to see a better fix in a future Java update.


comment:7 Changed 6 years ago by Don-vip

Resolution: othersoftware
Status: needinfoclosed

comment:8 Changed 6 years ago by Don-vip

Ticket #9894 has been marked as a duplicate of this ticket.

comment:9 Changed 6 years ago by Don-vip

Keywords: javabug added; template_report removed

comment:10 Changed 6 years ago by Don-vip

Ticket #10476 has been marked as a duplicate of this ticket.

comment:11 Changed 6 years ago by bastiK

Ticket #10785 has been marked as a duplicate of this ticket.

comment:12 Changed 6 years ago by bastiK

This should be reported, is it a bug in OpenSUSE or in Java?

comment:13 Changed 6 years ago by jengelh@…

Some toolkit combinations, like GTK/QT with freetype automatically switch to different fonts with CJK glyphs as needed. xterm on the other hand does not (which is why it has two options, -fa and -fd, for example).

This definitely is a Java issue. The runtime ought to handle fonts with absent glyph positions - possibly by (a) throwing a NoGlyphHere, (b) ignoring such glyphs and not rendering it, (c) properly switching fonts. Throwing an "outofbounds" seems totally wrong.

comment:14 Changed 6 years ago by bastiK

There is a file /etc/java-7-openjdk/ (maybe at different location) where the Java fonts are set.

For me it contains e.g.

dialog.plain.latin-1=DejaVu Sans
dialog.plain.japanese-sazanami=Sazanami Gothic
dialog.plain.japanese-vlgothic=VL PGothic

If the fonts on the right hand side were not installed as a dependency of the openjdk package, then this would be issue with the package configuration and not with java. Could you check?

Last edited 6 years ago by bastiK (previous) (diff)

comment:15 Changed 6 years ago by jengelh@…

I recently switched to openSUSE 13.2 (with openjdk, where the outOfBounds exception is no longer raised. It would seem that this issue has been fixed in Java.

For interest, the contains

dialog.0=-b&h-Lucida Sans-medium-r-normal--*-%d-*-*-p-*-iso10646-1
dialog.1=-Bitstream-Bitstream Vera Sans-medium-r-normal--*-%d-*-*-p-*-iso10646-1
dialog.4=-b&h-Luxi Sans-medium-r-normal--*-%d-*-*-p-*-iso10646-1
dialog.5=-URW-Nimbus Sans L-medium-r-normal--*-%d-*-*-p-*-iso8859-1

dialog.italic.0=-b&h-Lucida Sans-medium-i-normal--*-%d-*-*-p-*-iso10646-1
dialog.italic.1=-Bitstream-Bitstream Vera Sans-medium-i-normal--*-%d-*-*-p-*-iso

which fits the description at . With XLFD though, I can imagine that no fonts other than the listed ones ever get used.
Now I feel intrigued to reinstall the earlier JDK in a VM for the heck of it.

comment:16 Changed 6 years ago by bastiK

#10785 reports this with openSUSE 13.2 (and Japanese text), so it doesn't seem to be fixed entirely. Maybe the problem only occurs for minimal installations and you already have the required fonts installed as dependency of another package.

comment:17 Changed 6 years ago by jengelh@…

I was able to re-reproduce it all.

It turns out that Java creates a ~/.java/fonts/1.7.0_71/ file where fontnames get cached, in the order of Fontconfig's preference.

This fcinfo….properties file contains seemingly every font there is on the system. Excerpt:

#JDK Font Configuration Generated File: *Do Not Edit*
#Wed Nov 26 16:28:35 CET 2014
fcversion=21101 Unicode MS
(…) Serif
sansserif.0.35.file=/usr/share/fonts/truetype/DejaVuSerif-Bold.ttf Unicode MS
(…repeat for bold…)
(…repeat for monospace, serif)

So even if I switch back the system to Arial (standard), Java would continue to use Arial (Unicode MS), causing the surprise in comment #15. Conversely, it would also be responsible for continuing outOfBounds exceptions even if additional fonts are installed later on, as this Java cache file apparently won't regenerate once it exists.

comment:18 Changed 5 years ago by stoecker

Ticket #11068 has been marked as a duplicate of this ticket.

comment:19 Changed 5 years ago by stoecker

Resolution: othersoftware
Status: closedreopened


zypper in fetchmsttfonts did not solve this issue on my system. Also removing the cache file.

Did not test 13.2 Java 8 yet, but that has a the major issue of JPEG display, which is much worse. Reopening the bug until we either have a solution or openSUSE is really fixed.

comment:20 Changed 5 years ago by jengelh@…

Installing fetchmsttfonts is not meant to fix this. It is a bug in the Java runtime that can only be worked around by changing fontconfig such that a font with all glyphs that you will eventually need has precedence.

comment:21 Changed 5 years ago by stoecker

Hmm, I got rid of the error with following font installation. Still some glyphs undisplayed, but no more exceptions.

It seems the minimum to be fulfilled is to fix the errors of "fonts-config" tool. In /usr/sbin/fonts-config there is a function "generate_java_font_setup" which contains a list of fonts needed to be installed for Java.


comment:22 in reply to:  19 ; Changed 5 years ago by Don-vip

Replying to stoecker:

Reopening the bug until we either have a solution or openSUSE is really fixed.

Do you think we can do something in JOSM?

comment:23 Changed 5 years ago by jengelh@…

With the Advanced Properties dialog in JOSM, one can set a personal preference for a font. Unfortunately, this does not seem to change the fonts everywhere in JOSM. Most of the UI - title bar, dialogs, etc. - continue to use the system fonts instead. If that problem can be fixed (perhaps all it takes is calling some SetFont on the mainwindow), we would be a step closer to a feasible workaround.

comment:24 Changed 5 years ago by Don-vip

I wrote something like that in the past (see alpha patch in #8334) but encountered performance issues and didn't look at it since.

comment:25 Changed 5 years ago by Don-vip

Keywords: font added

comment:27 Changed 5 years ago by stoecker

According to that ticket it seems thus installation of these two fixes the bug.


comment:28 in reply to:  22 Changed 5 years ago by stoecker

Replying to Don-vip:

Do you think we can do something in JOSM?

No. That's a java bug and must be fixed there. I doubt we can can fix it in JOSM, except we find a place, where we can catch any such exception and replace the text display with something else.

Nevertheless I'd let this bug stay open for reference some time.

comment:29 Changed 5 years ago by stoecker

I'll setup a minimal openSUSE system next days and document the font usage for reference.

comment:30 Changed 5 years ago by anonymous

Uninstalling texlive-arphic-fonts fixed a similar problem for me.

comment:31 Changed 5 years ago by stoecker

Tested a bit:
The crashs happen when "texlive-arphic-fonts" is installed, but not "arphic-gbsn00lp-fonts" or "arphic-bsmi00lp-fonts". Either one of the normal arphic fonts must be installed or the texlive variant must not be installed.

comment:32 Changed 5 years ago by jengelh@…

openSUSE makes TeX fonts (.pfa/.pfb) selectible through fontconfig/freetype since some releases, which is also something relatively new since some releases, and other distributions may still be not searching through pfb files (but just the regular pcf,ttfs).

comment:33 Changed 5 years ago by stoecker

Resolution: fixed
Status: reopenedclosed

JOSM for openSUSE now has a recommended fonts package, which fixes this issue.

comment:34 Changed 5 years ago by Don-vip

Milestone: 15.02

comment:35 Changed 5 years ago by stoecker

Ticket #11296 has been marked as a duplicate of this ticket.

comment:36 Changed 5 years ago by Don-vip

Ticket #12010 has been marked as a duplicate of this ticket.

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain jengelh@….
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.