Graphviz Issue Tracker
Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001411graphvizDotpublic2008-09-20 09:022013-10-22 10:47
ReporterJulian Reschke 
Assigned Toellson 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOS*-*-*OS Version
Summary0001411: SVG 1.1 output
Description



There seem to be several issues with the SVG output, for instance:
<CD>
- version=1.0, not 1.1 (probably intentional, but why?)



- svg:a elements generated without xlink:href attribute



- content attribute on svg:title



- empty svg:a elements being generated
</CD>



I'm currently working around these issues (that trigger errors in the W3C
validator) using XSLT.



So is compliance to the SVG 1.1 DTD a goal?
Steps To Reproduce

digraph {
  rankdir=LR;
  label = "RFCs related to Content-Disposition in HTTP";

  subgraph cluster_0 {
    color = gray;
    label = "Content-Disposition Header";
    "RFC1806" [URL = "http://tools.ietf.org/html/rfc1806" [^]][tooltip = "Communicating Presentation Information in Internet Messages: The Content-Disposition Header"][style = "filled", fillcolor = white, shape=box];
    "RFC2183" [URL = "http://tools.ietf.org/html/rfc2183" [^]][tooltip = "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field"][style = "filled", fillcolor = yellow, shape=box];
  }

  subgraph cluster_1 {
    color = gray;
    label = "HTTP/1.1";
    "RFC2068" [URL = "http://tools.ietf.org/html/rfc2068" [^]][tooltip = "Hypertext Transfer Protocol -- HTTP/1.1"][style = "filled", fillcolor = yellow, shape=box];
    "RFC2616" [URL = "http://greenbytes.de/tech/webdav/rfc2616.html" [^]][tooltip = "Hypertext Transfer Protocol -- HTTP/1.1"][style = "filled", fillcolor = orange, shape=box];
  }

  subgraph cluster_2 {
    color = gray;
    label = "MIME";
    "RFC2047" [URL = "http://tools.ietf.org/html/rfc2047" [^]][tooltip = "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text"][style = "filled", fillcolor = orange, shape=box];
    "RFC2184" [URL = "http://tools.ietf.org/html/rfc2184" [^]][tooltip = "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations"][style = "filled", fillcolor = yellow, shape=box];
    "RFC2231" [URL = "http://greenbytes.de/tech/webdav/rfc2231.html" [^]][tooltip = "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations"][style = "filled", fillcolor = yellow, shape=box];
  }

  "RFC2183" -> "RFC1806" [style = solid, color = red, tooltip = "obsoletes", URL = "http://www.rfc-editor.org/errata_search.php?rfc=2183&eid=1457" [^] ];
  "RFC2184" -> "RFC2047" [style = solid, tooltip = "updates"];
  "RFC2184" -> "RFC2183" [style = solid, tooltip = "updates"];
  "RFC2231" -> "RFC2047" [style = solid, tooltip = "updates"];
  "RFC2231" -> "RFC2183" [style = solid, tooltip = "updates"];
  "RFC2231" -> "RFC2184" [style = solid, color = red, tooltip = "obsoletes"];
  "RFC2616" -> "RFC2068" [style = solid, color = red, tooltip = "obsoletes"];

  "RFC2183" -> "RFC2184" [style = dotted, tooltip = "references"];
  "RFC2616" -> "RFC1806" [style = dotted, tooltip = "references"];
  "RFC2616" -> "RFC2047" [style = dotted, tooltip = "references"];
  "RFC2616" -> "RFC2183" [style = dotted, tooltip = "references"];
}
Additional Information

[ellson]
<CD>
= - version=1.0, not 1.1 (probably intentional, but why?)
=

More likely just because of when I wrote it.

Can you identify the areas which are not 1.1 compliant?

= - svg:a elements generated without xlink:href attribute
=

Because your graph doesn't provide one. Your graph contains:

= "RFC2183" -\> "RFC2184" [style = dotted, tooltip = "references"]

This results in an object with a tooltip, but no hyperlink. Independent tooltips like this have been found useful for high-density graphs that don't have room for labels.

= - content attribute on svg:title
=

I don't know what this means? Can you hand-code an svg fragment to illustrate what you expect?

= - empty svg:a elements being generated
=

That looks like a bug...

= I'm currently working around these issues (that trigger errors in the W3C
= validator) using XSLT.
=
= So is compliance to the SVG 1.1 DTD a goal?
=

It wasn't, but thats probably not a bad idea. I'm game, so long as the validator can be convinced to accept the useful case of tooltips without hrefs.

[julian]

= More likely just because of when I wrote it.

Understood.

= Can you identify the areas which are not 1.1 compliant?

I guess it was mainly the "version" attribute; will have to check whether there was something else.

== - svg:a elements generated without xlink:href attribute
==
= Because your graph doesn't provide one. Your graph contains:
=
= = "RFC2183" -= "RFC2184" [style = dotted, tooltip = "references"]
=

= This results in an object with a tooltip, but no hyperlink. Independent tooltips like this have been found useful for high-density graphs that don't have room for labels.

Agreed. My workaround is to insert an xlink:href to the closest ancestor with an id attribute.

== - content attribute on svg:title
==
= I don't know what this means? Can you hand-code an svg fragment to illustrate what you expect?

It's not allowed; maybe it was something that was removed in 1.1?

== - empty svg:a elements being generated
==
= That looks like a bug...
== I'm currently working around these issues (that trigger errors in the W3C
== validator) using XSLT.
==
== So is compliance to the SVG 1.1 DTD a goal?
==
= It wasn't, but thats probably not a bad idea. I'm game, so long as the validator can be convinced to accept the useful case of tooltips without hrefs.

Yep, I wouldn't want to miss those.

= ...

I'm attaching the \<A HREF="b1447.xslt"\>XSLT\</A\> I currently use for cleanup.

[ellson]
=
== Can you identify the areas which are not 1.1 compliant?
=
= I guess it was mainly the "version" attribute; will have to check whether there was something else.

Well that should be an easy change...

What happens if someone has a SVG-1.0 browser? Will they be able to read svg-1.1 ? Do I reduce the set of applications that
can use my generated svg by claiming svg-1.1 if I don't really use any of its features?
=
=== - svg:a elements generated without xlink:href attribute
===
== Because your graph doesn't provide one. Your graph contains:
==
== = "RFC2183" -= "RFC2184" [style = dotted, tooltip = "references"]
==
== This results in an object with a tooltip, but no hyperlink. Independent tooltips like this have been found useful for high-density graphs that don't have room for labels.
=
= Agreed.
:-)
= My workaround is to insert an xlink:href to the closest ancestor with an id attribute.
I don't understand this, if you want a URL, why not provide one in the graph?
Doesn't matter to me really. As long as it works for you.
=
=== - content attribute on svg:title
===
== I don't know what this means? Can you hand-code an svg fragment to illustrate what you expect?
=
= It's not allowed; maybe it was something that was removed in 1.1?
I'm still not understanding. Can you cut&paste the fragment in question?
I can't see any <title= in the <svg=...</svg= only in <g= ... </g=
=
=== - empty svg:a elements being generated
===
== That looks like a bug...
Fixed (Wow! That generated a lot of clutter! ) Its in CVS now, should be in tomorrow's snapshot.

=
= I'm attaching the XSLT I currently use for cleanup.

So this shouldn't be necessary if I generate conformant svg-1.1, right?

[julian]
John Ellson wrote:
== I guess it was mainly the "version" attribute; will have to check whether there was something else.
=
= Well that should be an easy change...
=
= What happens if someone has a SVG-1.0 browser? Will they be able to read svg-1.1 ? Do I reduce the set of applications that
= can use my generated svg by claiming svg-1.1 if I don't really use any of its features?

I'm not sure. I didn't some tests with current browsers, plus IE+Adobe plugin, and they all like SVG 1.1.

==== - svg:a elements generated without xlink:href attribute
====
=== Because your graph doesn't provide one. Your graph contains:
===
=== = "RFC2183" -= "RFC2184" [style = dotted, tooltip = "references"]
===
=== This results in an object with a tooltip, but no hyperlink. Independent tooltips like this have been found useful for high-density graphs that don't have room for labels.
==
== Agreed.
= :-)
== My workaround is to insert an xlink:href to the closest ancestor with an id attribute.
= I don't understand this, if you want a URL, why not provide one in the graph?
= Doesn't matter to me really. As long as it works for you.

Actually, I don't have a URL. If I had one, I would be specifiying it.

What I'm putting in is a relative reference, pointing to the container element, such as in

<CD>
<!-- RFC4035->RFC4470 -->
<g id="edge14" class="edge"=<title=RFC4035->RFC4470</title>
<a xlink:href="#edge14" xlink:title="updates" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
<path style="fill:none;stroke:black;stroke-dasharray:1,5;" d="M1295,-2990C1318,-3018 1355,-3061 1375,-3086"/>
<polygon style="fill:black;stroke:black;" points="1297.22,-2987.22 1288,-2982 1291.95,-2991.83 1297.22,-2987.22"/>
</a>
</CD>

==== - content attribute on svg:title
====
=== I don't know what this means? Can you hand-code an svg fragment to illustrate what you expect?
==
== It's not allowed; maybe it was something that was removed in 1.1?
= I'm still not understanding. Can you cut&paste the fragment in question?
= I can't see any <title= in the <svg=...</svg= only in <g= ... </g=

Ah, this took me some time.

The SVG output references "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd", [^] and that one defaults title/@content to "'structured text'" -- why on earth does it do that...?

==== - empty svg:a elements being generated
====
=== That looks like a bug...
= Fixed (Wow! That generated a lot of clutter! ) Its in CVS now, should be in tomorrow's snapshot.

Thanks.

==
== I'm attaching the XSLT I currently use for cleanup.
=
= So this shouldn't be necessary if I generate conformant svg-1.1, right?

Yes, that would be optimal.

Again, thanks a lot for the feedback!

[ellson]
=
==
=== My workaround is to insert an xlink:href to the closest ancestor with an id attribute.
== I don't understand this, if you want a URL, why not provide one in the graph?
== Doesn't matter to me really. As long as it works for you.
=
= Actually, I don't have a URL. If I had one, I would be specifiying it.
=
= What I'm putting in is a relative reference, pointing to the container element, such as in
=
= <!-- RFC4035->RFC4470 -->
= <g id="edge14" class="edge"=<title=RFC4035->RFC4470</title>
= <a xlink:href="#edge14" xlink:title="updates" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
= <path style="fill:none;stroke:black;stroke-dasharray:1,5;" d="M1295,-2990C1318,-3018 1355,-3061 1375,-3086"/>
= <polygon style="fill:black;stroke:black;" points="1297.22,-2987.22 1288,-2982 1291.95,-2991.83 1297.22,-2987.22"/>
= </a>

OK. I see what you are doing, but I'm still not understanding why. Are you telling me
that the svg-1.1 validator insists on an xlink:href in an <a= element? What if it was xlink:type="title" ?

And do I really have to generate all that cr*p for every <a...= element, or is there
some way of abbreviating it to something like the html-1.0 form: <a href="foo" title="bar">


=
===== - content attribute on svg:title
=====
==== I don't know what this means? Can you hand-code an svg fragment to illustrate what you expect?
===
=== It's not allowed; maybe it was something that was removed in 1.1?
== I'm still not understanding. Can you cut&paste the fragment in question?
== I can't see any <title= in the <svg=...</svg= only in <g= ... </g=
=
= Ah, this took me some time.
=
= The SVG output references "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd", [^] and that one defaults title/@content to "'structured text'" -- why on earth does it do that...?
So this just goes away if I change the header to version 1.1 !

[julian]
== <!-- RFC4035->RFC4470 -->
== <g id="edge14" class="edge"=<title=RFC4035->RFC4470</title>
== <a xlink:href="#edge14" xlink:title="updates" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
== <path style="fill:none;stroke:black;stroke-dasharray:1,5;" d="M1295,-2990C1318,-3018 1355,-3061 1375,-3086"/>
== <polygon style="fill:black;stroke:black;" points="1297.22,-2987.22 1288,-2982 1291.95,-2991.83 1297.22,-2987.22"/>
== </a>
=
= OK. I see what you are doing, but I'm still not understanding why. Are you telling me
= that the svg-1.1 validator insists on an xlink:href in an <a= element? What if it was xlink:type="title" ?

Interesting question.

It appears that SVG 1.1 only allows simple links: http://www.w3.org/TR/SVG/linking.html#Links. [^]

= And do I really have to generate all that cr*p for every <a...= element, or is there
= some way of abbreviating it to something like the html-1.0 form: <a href="foo" title="bar">

I fear you have to do that; or try to use DTD magic (which I would strongly recommend not to).

== The SVG output references "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd", [^] and that one defaults title/@content to "'structured text'" -- why on earth does it do that...?
= So this just goes away if I change the header to version 1.1 !

Right. Attribute defaulting through DTD is totally evil.

[ellson]
OK, I've made changes in CVS with the goal of SVG-1.1 conformance. It should be in tomorrow's snapshot.

For the cases of tooltips without links, I did generate an xlink:href to the enclosing object, but this results in the link being displayed in the bottom information area of firefox, leading the user to think that it is a real link, which it is not. So I feel that the suggestion is not correct. Is it the SVG-1.1 specification that you think requires this? Or just the validator? If its just the validator, then the validator needs to be trained for this usage.

The example you referenced: http://www.w3.org/TR/SVG/linking.html#Links [^] does not use the: xlink:type="simple" property. So I've omitted this verbosity too.

Could you take a look at the attached \<A HREF="b1447a.svg"\>output\</A\> to see if there are any other issues?

[julian]
= OK, I've made changes in CVS with the goal of SVG-1.1 conformance. It should be in tomorrow's snapshot.

Sounds good.

= For the cases of tooltips without links, I did generate an xlink:href to the enclosing object, but this results in the link being displayed in the bottom information area of firefox, leading the user to think that it is a real link, which it is not. So I feel that the suggestion is not correct. Is it the SVG-1.1 specification that you think requires this? Or just the validator? If its just the validator, then the validator needs to be trained for this usage.

I think it's the specification.

When I researched this a few weeks ago I think I found it's a known shortcoming of SVG 1.1 that it's too hard to attach a tooltip to an object,

= The example you referenced: http://www.w3.org/TR/SVG/linking.html#Links [^] does not use the: xlink:type="simple" property. So I've omitted this verbosity too.

It may have a default value due to the DTD.

= Could you take a look at the attached output to see if there are any other issues?

I'm getting 10 validation errors because of missing xlink:xhref elements (see http://validator.w3.org/ [^]).

[ellson]
Thanks for the pointer to the validator.
So I'm stuck. I have a feature that I want, that works in firefox in the way I want it to, but the validator definitely
doesn't like it, and the specification needs a lawyer to interpret on the matter.

Is there an alternative for tooltips without links, that doesn't require javascript? Is the issue being discussed someplace?

For now, my inclination is to remain non-conformant on this point. (Or perhaps I should just call it SVG-1.0 again ?)

[julian]
= Thanks for the pointer to the validator. So I'm stuck. I have a feature that I want, that works in firefox in the way I want it to, but the validator definitely
= doesn't like it, and the specification needs a lawyer to interpret on the matter.

Agreed.

= Is there an alternative for tooltips without links, that doesn't require javascript? Is the issue being discussed someplace?

Good question. Looking at the W3C mailing lists, <http://lists.w3.org/Archives/Public/www-svg/= [^] seems to be the best place to me.

= For now, my inclination is to remain non-conformant on this point. (Or perhaps I should just call it SVG-1.0 again ?)

I just tried, and SVG-1.0 seems to have the same requirement.

</CD>
TagsNo tags attached.
AUXILLARY-FILEShttp://www.graphviz.org/bugs/b1447.xslt [^] http://www.graphviz.org/bugs/b1447a.svg [^]
DATE-FIXED
FIX-COMMENTpresumed fixed - please open a new bug for any current svg issues
FORMER-ID1447
INPUT-FILE
OUTPUT-FILEhttp://www.graphviz.org/bugs/b1447.svg [^]
STATUS-COMMENT*
VERSION     2.20.2
Attached Files

- Relationships

-  Notes
There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2011-04-28 04:03 user1 New Issue
2011-04-28 04:03 user1 Assigned To => user695
2013-10-22 10:47 ellson FIX-COMMENT => presumed fixed - please open a new bug for any current svg issues
2013-10-22 10:47 ellson Status acknowledged => closed
2013-10-22 10:47 ellson Resolution open => fixed


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