HTML-like label styling (FONT, B, I, ...)

Hi,

I am struggling with styling of HTML-like label inside table. If I use style tags like , etc. then ouput line contains odd spacing (horizontal and vertical too). Please see attachments (First line is without any formating tag).

NOTE: In SVG format it is even more visible.

Is it bug or just wrong usage?

//EDIT: Added another example.

Thank you, Martin

AttachmentSize
graphInvalid.txt1.12 KB
dot.gif3.11 KB
graphInvalid-more.txt1.45 KB
invalid_rendered_svg.PNG78.19 KB

Shape of subgraphs, overlaping nodes.

Is there any way how to set "tab" shape for subgraphs (instead of default "box")?
How can I create overlaping nodes like this: 


if it is even possible with dot?

Thank you,
Martin

Sorry, there is no built-in

Sorry, there is no built-in mechanism at present for fancier subgraph or node shapes beyond the node shapes shown in http://www.graphviz.org/content/node-shapes. And one of the main aesthetics of dot is to prevent node overlap.

Depending on your requirement, it would be possible to achieve what you want with several passes. For example, you could replace these fancy nodes with a simple box of the right size and use that for layout. The second pass would replace these box nodes with two overlapping nodes. The final pass would be to use neato -n to do the edge routing.

I am not seeing any odd

I am not seeing any odd vertical spacing. Each line seems to have the same base line across it. Was there something particular that you are seeing?

As for oddities in horizontal spacing, the two most egregious ones are the last two lines. This is due to the lack of a space after the colon. The other slight variations you are seeing are probably due to not processing the line as a whole. We rely on pango or svg to handle the style variations, and in each case, the string "Class" is started at the same horizontal position. So this is either a bug in pango or a misuse on our part. (It is easy to see that the left side of the underline and slash line up with the left side of Class in the unannotated version. The use of bold and italic probably cause a similar shift.) As I suggested, it would be interesting to pass the entire annotated line to pango/svg and see if the problem is resolved, since then it could handle kerning, spacing, etc.

Concerning svg, this format is very underspecified. When dot runs, it uses the font metrics for the fonts it has. When the output is viewed in an svg viewer, it may use totally different fonts, with unexpected results. The only way to avoid this for certain is to use -Tsvg:cairo, so the font glyphs are included in the svg output.

 

First post is edited with

First post is edited with further example (vertical and horizontal spacing is more visible). How can I test a possible pango/svg issue?

The vertical differences

The vertical differences appear to be something we are doing wrong in our code, in that the y coordinate used for # and for "attr" are different. I'll have to find out where this difference comes from. As for the horizontal differences, the question is why is there a difference between treating "attr: Class" as a unit vs. treating it as "attr: " and "Class" when specified as

attr: <FONT>Class</FONT>

In the second case, our code prints "attr: ", computes the width of "attr: ", and shifts the x position by that amount to print "Class". Either pango does some compaction in the first case, or we are misinterpreting how much to shift the x position.

For all of these, the cleanest solution may be to pack up an entire annotated line, or as much as possible, before passing it off to pango or svg.

By the way, the much larger shift in your svg example is probably due to the problem of the viewer using different fonts and font metrics than used by Graphviz. In particular, if I view the svg in inkscape, the later lines have Class shifted to the left of Class in the first line, while the svg in Chrome the later lines have Class shifted to the right.

When it could be solved? I

When it could be solved? I need correct visualising to my master thesis. Thank you, Martin

Recent comments