Fix inconsistent arrow size when annotating the name of an association on OSX

[earlchew]

Fix https://github.com/umlet/umlet/issues/530

[afdia]

thanks for the contribution, so basically you're just replacing the 3 fontfamilies with existing mac fonts which don't have the arrow-problem. As mentioned in the comment above please replace the tinyurl with the full one, but other than that it looks fine to me.

Do you have any concerns that this causes other things to break due to this change? Perhaps you can check if chinese and cyrillic characters still work, e.g. using the following text as properties:

的 形 音 碼 形 码
Ԯ Ԓ Ԡ Ф

[earlchew]

@afdia I'm not sure how to quantify the effect (positive or negative) across all fonts and glyphs across the board. Here are the cases that you highlighted.

The first case uses OSX 10.12.6 (Sierra) with the characters you provide using stock 14.3.0. As you can see, only 1 out of 4 Cyrillic glyphs are visible in the drawing pane, even though all are visible in the markup pane:

Here is how the same UXF file is rendered using stock 14.3.0 on OSX 10.10.5 (Yosemite). As you can see, 3 out of 4 Cyrillic glyphs are visible in both the drawing and markup panes:

Now using the proposed changes on OSX 10.12.6 (Sierra), I can see that only 2 out of 4 Cyrillic glyphs are visible in the drawing pane (again all are visible in the markup pane):

Overall:

• For OSX 10.12.6, there is an improvement from 14.3.0 which showed only one out of 4, and now shows 2 out of 4 Cyrillic glyphs
• The markup pane manages to show all of the glpyhs you called out
• Even OSX 10.10.5 has missing glyphs with 14.3.0, but in both drawing and markup panes

Do you have any hints as to how the font is selected for the "Properties" pane which shows the markup?

[afdia]

It's hard to say how to quantify the effect, but umlet shouldn't "break" for people using them, so perhaps we could provide a property to disable this default-font-switch? Like: osx_replace_default_fonts with the default value of true If something breaks, I can suggest to set this property to false to get the old font families.

Or even more flexible (I'm not sure if this is necessary): osx_replace_default_fonts with the default value of Arial,Times New Roman,Menlo the property has 3 values which replace SANS_SERIF,SERIF,MONOSPACED If the property is missing, no replacement is done

In either case I would just write and read the property from the file without integration into the options-gui, because it's a very specific edge case and just a safety net in case this change causes some problems.

What do you think?

Btw: The properties panel font is set here: https://github.com/umlet/umlet/blob/master/umlet-swing/src/main/java/com/baselet/gui/pane/OwnSyntaxPane.java#L87

[earlchew]

Before answering your questions, another experiment on OSX 10.12.6 (Sierra) with stock 14.3.0 showing how the arrows and Cyrillic glyphs manifest in the drawing pane vs the markup pane. This example is interesting because while both the panes use SansSerif, the Cyrillic glyphs show up in the markup pane but have missing components in the drawing pane.

Putting in some logging I see:

2019-01-06 15:51:15,224 |   1527 | ERROR | com.baselet.gui.pane.OwnSyntaxPane | @@@ FONT java.awt.Font[family=SansSerif,name=SansSerif,style=bold,size=11]
...
2019-01-06 15:51:22,158 |   8461 | ERROR | com.baselet.diagram.draw.swing.DrawHandlerSwing | @@@ drawText java.awt.Font[family=SansSerif,name=SansSerif,style=plain,size=14]

Do you recall the reason that the OwnSyntaxPane uses style=bold vs the style=plain in DrawHandlerSwing?

[afdia]

I guess you are talking about the header of the syntaxpane which is bold. The content uses the following font java.awt.Font[family=Monospaced,name=Monospaced,style=plain,size=11] and I think the main difference is the fontfamily, but not the style

(You should check DerivedConfig.getPanelContentFont() instead of getPanelHeaderFont())

Please post your teststring here, so I can check it using Win10 if it works.