Community
Participate
Working Groups
Created attachment 276556 [details] Screenshot about the current rendering The DOT Graph View should render graphs with fontname attribute values properly. Example: graph { subgraph cluster_0 { fontname=arial label = "subgraph" 1[label= "subgraph"] } }
GitHub Pull Request 42 created by [prggz] https://github.com/eclipse/gef/pull/42
This is a log for documentation purposes. I am currently preparing another pull request. The pull request 42 implementation supports only the case where the fontname matches exactly a font-family installed on the system. However reality is more complex: Firstly, Graphviz supports the 35 postscript 2 font names that are currently seen in Graphviz's sources at src/lib/common/ps_font_equiv.txt. We should detect these font names and use graphviz's replacement fonts for displaying these depending on Fonts available on the user's machine. For use with the Pango library the replacement order can be found in Graphviz's sources at plugin/pango/gvplugin_pango.c. For other font names, we cannot determine the font-family properly as the fontname attribute then depends on the system font library in use (see graphviz attribute reference for more detail). I would, however, propose, we try to find common keywords (like "bold", "italic", "oblique") and use these for the -fx-font-style and -fx-font-weigth CSS styles. This would allow us to display a large number of fontnames used in .dot documents.
For documentation purposes: We are considering implementing a DotFontUtil, corresponding to the existing DotColorUtil. We will continue to use the javafx Font class due to no apparent alternative. However, extensive testing has shown: Under Windows, neither Pango nor JavaFX seem to have any support for fontweight other than bold, nor for any options set for gravity, stretch or variant style options. We may fare best, if we implement Style (Italic/Oblique) and Bold weight, only. Under Linux, JavaFX again seems to not be able to use settings for e.g. Thin font weight, even though the settings exist. Most notably, the font class uses Strings to reference FontFamilies and FontNames. FontNames can be used to uniquely identify a Font. However, we cannot, as does Pango under linux, see which is the thinnest (/boldest, ...) font. For example, on my machine, there is a font family called "Lato" installed. It has various weights, i.e. hairline, thin, light, bold, heavy, etc.... Pango uses the Family name ("Lato") and the font weight set to determine the correct Font to use. This does not, however need to align by name. I.e. "Thin" is the 'official' OS/2 descriptor for fontweight 100, i.e. extremely thin. Hence the correct Font to pick for "Lato, Thin" would be the font named "Lato Hairline" and not "Lato Thin" or any other. However, Font.getFamilies() returns multiple families for the Lato font family. I.e. one for every weight except BOLD. Hence, we are unable to use the Font.font(family, weight, size) static factory method to get the correct font, as we would prior to this need to know which Family i.e. "Lato Hairline", "Lato Thin", ... we have to specify for the family attribute. Hence, for now, we will try to implement support for visualizing italic/oblique style and bold weight as well as visualizing the first available font from family list.
If in the future this is revisted: Another idea would be to use Font.getFontNames to acquire a full list of installed font names. This could then, for example, be filtered in a stream by family name specified. We could then "look" at the remaining font names. If there was only one left, we would create the font by font name (to call getFamily() for use in CSS). If there were multiple left, we would have to use common names describing weight (and stretch - in practice, this would be "condensed" only) to somehow filter further and produce a best guess. Personally, I am not particularly keen on this implementation as it is debatable of how much use it is and one would never be sure, if our software picked the right font. Still, it is the closest result to the original, I can currently imagine as being realistically achievable.
Thank you Zoey for your contribution! I merged your PR into the master branch.
Thank you Zoey for your contribution! I merged your PR into the master branch. Resolving as fixed in 5.1.0 (2019-06).
