Graphviz Issue Tracker
Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002339graphvizOutput Generationpublic2013-08-25 18:112013-09-13 10:54
Reporterryandesign 
Assigned Toerg 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusresolvedResolutionfixed 
Platformx86_64OSOS XOS Version10.8.4
Summary0002339: xdot output does not contain HTML-like label formatting (bold, italic, underline, subscript, superscript)
DescriptionThe xdot "F" command tells me what font size and family to use (e.g. "F 14 11 -Times-Roman") and the "T" command tells me what coordinates to move to, the text alignment, the text width, and the characters to draw (e.g. "T 14.5 14.3 -1 25 3 -"), but nowhere does it say whether to draw it bold, italic, underline, subscript, or superscript, when that information had been provided in an HTML-like label.
Steps To Reproducedot -Tpng -ohtml-formatting.gv.png -Txdot -ohtml-formatting.gv.xdot html-formatting.gv
TagsNo tags attached.
AUXILLARY-FILES
DATE-FIXED
FIX-COMMENT
FORMER-ID
INPUT-FILE
OUTPUT-FILE
STATUS-COMMENT
VERSION2.33.20130825.0446
Attached Files? file icon html-formatting.gv [^] (270 bytes) 2013-08-25 18:11
png file icon html-formatting.gv.png [^] (3,053 bytes) 2013-08-25 18:11


? file icon html-formatting.gv.xdot [^] (1,085 bytes) 2013-08-25 18:11

- Relationships

-  Notes
User avatar (0000445)
erg (administrator)
2013-08-26 09:13

The only real issue here is deciding on another extension of xdot to support the notation. The two obvious choices are to add a new operator, say 't', that specifies the set of font options set or that reproduces the 'T' flag but with an extra field for denoting the font options. Suggestions?
User avatar (0000446)
ryandesign (reporter)
2013-08-26 09:31

You once said that "new [xdot] versions are upward compatible with earlier versions":

http://lists.research.att.com/pipermail/graphviz-interest/2007q1/003115.html [^]

So the latter choice doesn't seem good to me, because the new operator would duplicate information already in the "T" operator (which would have to stay in the file for backward compatibility) and that would make all xdot files unnecessarily larger even though most don't use this feature.

I would go with the former choice and have the new operator just specify bold, italic, underline, subscript, superscript, which would apply to all future text operations. To allow for additional flags in the future it could be a bitmask, like you implemented for the "H" operator in 2010 that's still hidden behind the NEW_XDOT pre-processor flag because I still haven't submitted feedback to you about it. (Sorry! I'll get to that...)
User avatar (0000447)
erg (administrator)
2013-08-26 09:53

Sorry. I wasn't clear. I did not mean to imply that 'T' would change but that the new operator 't' would have all of the same fields plus one more. This version of the 't' operator would only be used if one of the bold, italic, etc. options is used.

The problem with using an operator to turn on and off text characteristics is that the xdot renderer would need to keep state information. Admittedly, this would not be that hard. I'm just not a big fan of extra state.

As for further extensions to xdot, there is something to be said for considering a whole new language, either one modeled on an extant language or at least one avoiding the limitations of the current xdot.
User avatar (0000448)
ryandesign (reporter)
2013-08-26 12:51

Oh ok. Using "t" *instead of* "T", when formatting is requested, would be fine. We've already established that xdot parsers would need to be updated anyway when a new operator is introduced: http://lists.research.att.com/pipermail/graphviz-devel/2010/001251.html [^]

But the other option, of requiring the xdot parser to maintain this state, doesn't sound problematic to me. I don't know how many xdot parsers have been written, but for Canviz, I already maintain all sorts of state -- font face and size, fill and stroke color, pen width, etc. -- so maintaining the state of text formatting is not a significant additional burden.
User avatar (0000525)
ryandesign (reporter)
2013-09-13 08:13

Looks like the "t" operator made its way into xdotversion 1.5 / graphviz 2.34.0 so this ticket can be marked resolved; thanks!

- Issue History
Date Modified Username Field Change
2013-08-25 18:11 ryandesign New Issue
2013-08-25 18:11 ryandesign File Added: html-formatting.gv
2013-08-25 18:11 ryandesign File Added: html-formatting.gv.png
2013-08-25 18:11 ryandesign File Added: html-formatting.gv.xdot
2013-08-26 09:13 erg Note Added: 0000445
2013-08-26 09:31 ryandesign Note Added: 0000446
2013-08-26 09:53 erg Note Added: 0000447
2013-08-26 12:51 ryandesign Note Added: 0000448
2013-09-13 08:13 ryandesign Note Added: 0000525
2013-09-13 10:54 erg Assigned To => erg
2013-09-13 10:54 erg Status new => resolved
2013-09-13 10:54 erg Resolution open => fixed


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