#7004: Refactor the graph layout code, and add interface with graphviz
---------------------------------+------------------------------------------
Reporter: nthiery | Owner: nthiery
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.3.4
Component: graph theory | Keywords: graph layout, graphviz, acyclic
Author: Nicolas M. Thiéry | Upstream: N/A
Reviewer: vdelecroix | Merged:
Work_issues: |
---------------------------------+------------------------------------------
Comment(by nthiery):
Replying to [comment:21 vdelecroix]:
> > It's not clear from the graph documentation that we can use latex for
the output. It could be clearer to have a link in the docstring of the
plot method or in the one of the object (Graph or DiGraph) itself.
> The documentation is quite clear and complete but in an "hidden" file:
sage.graphs.graph_latex
+1 on adding appropriate links.
> The refactorization of the code is really good,
:-)
> I will just talk about the graphviz, string and latex possibilities.
Perhaps for other tickets...
> 1) __graph to text conversion__
>
> There is different standards format for string representations of graph
objects. At least two or three
> * graphml (http://graphml.graphdrawing.org) which uses XML
> * dot (http://www.graphviz.org) which was created by graphviz
> * xdot which is can be considered as an extension of dot with non
standard options
>
> From now, there exists a method graphviz_string. Could we prefer a
> dot_string ? and in the same manner think about a graphml_string ?
Yup. Note that there already exists methods graph6_string
sparse6_string, and so on.
> The main problem with those two names is that there does not start
> with the same prefix... and we get a contradiction with the use of
> the tab completion. As the refactorization for layout is perhaps we
> can consider string_dot and string_gml ? and string(format='dot')
> string(format='gml')
The ..._string convention is followed consistently; so it might be a
bit late to change it. On the other hand, it could be nice indeed to
have a string(format='...') method
> 2) __latex generation__
>
> There is a intersection between the two format of GraphLatex (which is
written in the description). dot2tex is able to produce a lot of different
format...
>
> Couldn't we prefer in the GraphLatex file some different methods
>
> * picture_tikz
> * picture_pstricks
> * which can also be used from picture(format='tikz')
picture(format='pstricks')
>
> and have an option inside picture_tikz to consider whether we use
dot2tex or we use the actual code ?
I see all those methods as internal (actually, maybe they should start
with _), while the main entry point for the user is the latex method.
With this in mind, each picture_* method should concentrate on a
specific task (creating a tikz picture manually / creating a picture
by calling dot2tex), whereas all the dispatching job should go in the
latex method.
I would not mind if the latex method would take extra arguments (as a
shortcut to calling set_latex_options).
> 3) __latency__
>
> It took one second to execute in a console
>
> {{{
> neato -Txdot my_graph.dot | dot2tex -ftikz | pdflatex
> }}}
>
> And almost one minute for
> {{{
> sage: G = MyGraph()
> sage: G.set_latex_options(format='dot2tex')
> sage: view(G)
> }}}
>
> Do you have an idea where the time is lost ?
Ah, interesting! On extra thing that dot2tex does it to run latex on
each node to get the dimension of its bounding box. In principle, this
is done in one swoop for all nodes, so that should not be that bad. So
we should check whether it is dot2tex or the interface to dot2tex
which is to be blamed. Could you give me your example and/or run the
dot2tex script on it?
> 4) __graph editor__
>
> There is a java program which can be used to interact with graphviz:
http://www.dynagraph.org/
> The program is made of two things dynagraph and grappa. It could be
really nice to have an applet inside the notebook to use it directly as
graph_editor works !!
>
> It is available under the Common Public License
+1 definitely!
It does not seem to have been very active recently though.
Cheers,
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7004#comment:22>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
