ModelicaSpecification
ModelicaSpecification copied to clipboard
Detailed text rendering
In https://github.com/modelica/ModelicaStandardLibrary/pull/3638 it was noted that tools differ in the text-rendering, primarily in icons.
There are two issues: font-size and how the text is centered in the extent:
For the font-size the difference is that Dymola just uses the font-size for the text, whereas SystemModeler renders the font-size in the original coordinate system and then scales it similarly as other primitives, thus: In Dymola a suitable font-size is 10 for an icon in the package-browser. In Wolfram SystemModeler a suitable font-size is 800. I have not investigated other tools.
The extent-difference is more subtle, but visible. It should be investigated further (as I don't fully understand it yet, @DagBruck ?). At least one of these should be clarified to get consistent rendering in this linked PR.
It would be good to have this clarified.
Phone meeting: Possibly that extent is irrelevant, and the difference is due to different fonts.
Specifying the font-size that is used for a diagram should possibly be a different setting; the goal with that setting is to get a consistent size for different texts and without having to ensure that the extent has the same height.
Poll (when actually specifying fontSize):
- Specifying font-size for Icon (will be scaled down, 110): Henrik
- Specifying font-size for Diagram (as default component size, 11): Dag, Ben, Hans,
- Delay decision: (Dag), Elena, Gerd, Markus, (Henrik)
- Abstain: Martin, Stephan, Delay.
Considering that we should provide migration paths for both tools and libraries adhering to the respective interpretations, the following would seem like a pragmatic solution:
- Deprecate the use of
fontSize
inText
inside anIcon
. - Introduce
fontSizeIcon
andfontSizeDiagram
that are only allowed forText
inside anIcon
, and wherefontSizeIcon
defines the font size in theIcon
's coordinate system, whilefontSizeDiagram
defines the fontsize when the icon is drawn on a diagram layer (regardless of how the extent of the icon is scaled).
According to this design, tools can go ahead and implement a deprecation warning and support for the new size specifiers. Users upgrading their tool can keep using their libraries as they were developed, albeit with a deprecation warning, and addressing the deprecation warning is a simple matter of replacing fontSize
by either fontSizeIcon
or fontSizeDiagram
depending on preferred interpretation. Of course, a tool can even offer to do this automatically.
Open question regarding fontSizeDiagram
:
- Obviously the size seen on the diagram doesn't depend on how the icon is scaled, but what about flipping and rotation?
Here's an alternative solution coming out of a coffee break discussion at MathCore:
- Introduce a
Boolean scale
which is mandatory forText
inside anIcon
. Also specify thatscale
either has no meaning or is not allowed forText
in other contexts. - When
scale = true
, scale the text with theextent
, similar to any other graphic item in the icon. - When
scale = false
usefontSize
when showing the icon on a diagram layer, regardless of how theextent
of the icon is scaled.
In practice, the effect of making scale
mandatory corresponds to making fontSize
deprecated in the proposal above. One could even make this explicit by saying that not specifying scale
is deprecated, and that tool-dependent behavior should be expected in this case.
The questions about flipping and rotation should of course also be answered in case of scale = false
.
Would it be safe to say that a Text
with scale = false
should be excluded when showing an icon in places like a package browser?
I'm all in favor of deprecating the fontSize
attribute in icons. I don't see the need to add new font size attributes, I think the concept of a zero-width bounding box to specify the height to be much better and already scales to whatever icon size is used by by browsers in the tool.
I can see the argument
But all icons should have the same size of their names texts regardless of how big I have made the icon.
But in that case, wouldn't it make more sense to set that as an attribute of the diagram where the icons are placed? Or maybe as a tool option.