Graphviz Issue Tracker
Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002333graphvizOutput Generationpublic2013-08-22 03:182013-09-05 10:18
Reporterryandesign 
Assigned Toerg 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Platformx86_64OSOS XOS Version10.8.4
Summary0002333: Inconsistent text position in xdot with HTML-like label
DescriptionI've been trying to improve the accuracy of my xdot renderer, Canviz. Text position has always been a bit off, and in trying to get to the bottom of it I've concluded that Graphviz isn't giving me consistent information. The Y-coordinate of text in _*draw_ commands varies based on whether the text came from a normal label or an HTML-like label with an embedded font face tag.

In the attached test graph there are two nodes side by side rendering the same string of text, one using a normal label, and one using an HTML-like label with an embedded font face tag. Since coordinates in xdot format are interpreted at 72 points per inch, I've set the graph dpi to 72 so that the png version is comparable.

I would expect both nodes to look identical. In the png rendering, in fact the text drawn using the HTML-like label with an embedded font face tag is one pixel up from where it should be. I would say that's a bug.

The bigger surprise comes in the xdot output, where the text from the HTML-like label with font face tag is 2.8 points up from where it should be. I cannot explain this inconsistency compared with png the output.

There's also some small horizontal positioning difference between a normal label and an HTML-like label with font face tag that I can't account for.
Steps To Reproducedot -Tpng -ofont2.gv.png -Txdot -ofont2.gv.xdot font2.gv
Additional InformationA normal label and an HTML-like label that *doesn't* use an embedded font face tag do look identical.
TagsNo tags attached.
AUXILLARY-FILES
DATE-FIXED
FIX-COMMENTpatch applied - then XDOTVERSION changed to 1.5
FORMER-ID
INPUT-FILE
OUTPUT-FILE
STATUS-COMMENT
VERSION2.33.20130815.0446
Attached Files? file icon font2.gv [^] (131 bytes) 2013-08-22 03:18
? file icon font2.gv.xdot [^] (608 bytes) 2013-08-22 03:18
png file icon font2.gv.png [^] (1,409 bytes) 2013-08-22 03:19


? file icon font.gv [^] (1,199 bytes) 2013-08-27 06:02
? file icon font.gv.xdot [^] (3,361 bytes) 2013-08-27 06:02
png file icon font.gv.png [^] (23,263 bytes) 2013-08-27 06:02


? file icon font3.gv [^] (3,064 bytes) 2013-08-27 06:02
? file icon font3.gv.xdot [^] (5,434 bytes) 2013-08-27 06:03
png file icon font3.gv.png [^] (13,643 bytes) 2013-08-27 06:03


diff file icon patch-xdot.diff [^] (595 bytes) 2013-09-02 23:32 [Show Content]

- Relationships

-  Notes
User avatar (0000438)
erg (administrator)
2013-08-23 16:22

There is no specification that the two types of labels should appear the same, but I guess it is not unreasonable. Actually, for multiple lines, the HTML label code produces a better packing, but all of this
font processing is complex enough, I decided not to push my luck. So for simple HTML labels, ones that could be expressed as ordinary labels, should appear the same as their ordinary versions. At some future date, all of this should be folded into a single mechanism.
User avatar (0000440)
ryandesign (reporter)
2013-08-24 05:31

I'm less concerned that the plain label and the HTML-like label with a font face tag differ by one pixel vertical in PNG output. I'm more concerned that in XDOT output they vary by 2.8 pixels. It means that, using the XDOT output, I cannot reconstruct an accurate bitmapped representation that matches the PNG Graphviz would have generated. That's what I really want to fix.
User avatar (0000441)
erg (administrator)
2013-08-24 08:11

That should be fixed now.
User avatar (0000451)
ryandesign (reporter)
2013-08-27 06:01

Thanks. The specific example I attached here is now fixed, but I'm still seeing problems with some others.

After some investigation, I think the problem is that in xdot output the Y-coordinate is not adjusted to take yoffset_centerline into account -- or maybe it is and it shouldn't be.

Because I found that to get most of the text in my Canviz renderings to line up with a Graphviz PNG, I had to move the text up by 0.2 * fontsize, which is what is set for yoffset_centerline in plugin/pango/gvtextlayout_pango.c:

    /* The distance below midline for y centering of text strings */
    para->yoffset_centerline = 0.2 * para->fontsize;


This works for most graphs, including font3.gv, which has individual table cells, each with a different font and size.

However for font.gv, which has a single cell with multiple fonts and sizes in a single label, this adjustment is not correct. In the PNG rendering, the text is aligned at the baseline, and in xdot the Y-coordinate of all text operations on each line is the same. To get this graph to align, I have to move the text up by 1, regardless of fontsize. I believe this relates to the following code from lib/common/htmltable.c:

	    if (simple)
        tl.yoffset_centerline = ti->yoffset_centerline;
        else
        tl.yoffset_centerline = 1;
User avatar (0000473)
ryandesign (reporter)
2013-09-02 23:31

I've found this line in several plugin files:

./plugin/core/gvrender_core_dia.c
./plugin/core/gvrender_core_ps.c
./plugin/core/gvrender_core_svg.c
./plugin/lasi/gvrender_lasi.cpp
./plugin/quartz/gvrender_quartz.c

p.y += para->yoffset_centerline;


Copying this line into function xdot_textpara in ./plugin/core/gvrender_core_dot.c fixes the problem.

If you increase the xdotversion when making this fix, then I can detect those versions of xdot with the problem and adjust the Y-coordinate to fix it, at least for simple labels.

I'm attaching a patch to do this.

I only increased the xdotversion from 1.4 to 1.4.1, because there is no difference for xdot parsers between these versions; the difference is only in how the values are interpreted, and less picky renderers don't even have to care about that. On the other hand, you might choose to up the xdotversion to 1.5, because xdotversions 1.3 and 1.4 are parsed no differently from 1.2 either.
User avatar (0000486)
ellson (administrator)
2013-09-05 10:17

patch applied. then XDOTVERSION changed to 1.5

- Issue History
Date Modified Username Field Change
2013-08-22 03:18 ryandesign New Issue
2013-08-22 03:18 ryandesign File Added: font2.gv
2013-08-22 03:18 ryandesign File Added: font2.gv.xdot
2013-08-22 03:19 ryandesign File Added: font2.gv.png
2013-08-23 16:22 erg Note Added: 0000438
2013-08-23 16:22 erg Assigned To => erg
2013-08-23 16:22 erg Status new => resolved
2013-08-23 16:22 erg Resolution open => fixed
2013-08-24 05:31 ryandesign Note Added: 0000440
2013-08-24 05:31 ryandesign Status resolved => feedback
2013-08-24 05:31 ryandesign Resolution fixed => reopened
2013-08-24 08:11 erg Note Added: 0000441
2013-08-24 08:11 erg Resolution reopened => fixed
2013-08-27 06:01 ryandesign Note Added: 0000451
2013-08-27 06:01 ryandesign Status feedback => assigned
2013-08-27 06:02 ryandesign File Added: font.gv
2013-08-27 06:02 ryandesign File Added: font.gv.xdot
2013-08-27 06:02 ryandesign File Added: font.gv.png
2013-08-27 06:02 ryandesign File Added: font3.gv
2013-08-27 06:03 ryandesign File Added: font3.gv.xdot
2013-08-27 06:03 ryandesign File Added: font3.gv.png
2013-09-02 23:31 ryandesign Note Added: 0000473
2013-09-02 23:32 ryandesign File Added: patch-xdot.diff
2013-09-05 10:17 ellson Note Added: 0000486
2013-09-05 10:18 ellson FIX-COMMENT => patch applied - then XDOTVERSION changed to 1.5
2013-09-05 10:18 ellson Status assigned => resolved


MantisBT 1.2.5[^]
Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker