Llevo unos días haciendo un poco de investigación sobre gráficos en el modo org. El objetivo es dibujar un perfil para el MiniMult, ese proyecto que llevo ya un tiempo desarrollando. Elegí varias vías de investigación y es momento de aclarar un poco cómo van las cosas.
He encontrado varias maneras de incorporar gráficos en un archivo
org. Y hablaré brevemente sobre las alternativas gráficas que he ido
trabajando, dejando para el final la que de momento es la más
prometedora y resultona que no es sino utilizar una plantilla .svg
y
modificar al vuelo el dibujo. Esta opción la presentaré en otro futuro
post cuando resuelva algunos problemas menores que me he
encontrado para hacerla funcionar.
Configuración para gráficos
Buscando información por ahí encontré información más detallada que explica cómo utilizar dos paquetes gráficos ditaa y plantUML para realizar gráficos en modo texto. donde Sin embargo, a esas dos opciones yo he añadido en mis pruebas graphviz, un paquete gráfico que he utilizado más con anterioridad y que me parece más interesante que los otros dos.
Lo primero que hice fue añadir a mi .emacs.el
la variable en el
apartado custom-set-variables
:
'(org-babel-load-languages (quote ((ditaa . t) (dot . t) (plantuml . t))))
Además hay que decirle a Emacs donde encontrar los programas. Bueno, en el caso de ditaa y de plantUML que no los tengo instalados en mi sistema –ahora explicaré cómo y porqué–. Graphviz está en el sistema y parece que lo encuentra sin necesidad de ponerle ningún path en la configuración:
(setq org-plantuml-jar-path
(expand-file-name "~/bin/plantuml.jar"))
(setq org-ditaa-jar-path
(expand-file-name "~/bin/ditaa.jar"))
PlantUML y ditaa son aplicaciones java. Para OpenSuSe no hay paquetes preparados para instalarlos en los repositorios que tengo configurados y en los que prefiero no revolver.
Así pues, me bajé los ficheros .jar
de sus «sitios oficiales» y los
metí en directorio bin
que tengo configurado para mi usuario. Por
supuesto, también añadí el correspondiente script que llama al jar
para poder llamarlos desde cualquier sitio. Ditaa y plantUML no
los conocía y me parecen bastante usables.
Ditaa
Ditaa es una forma de hacer los gráficos bastante sencilla, por su forma directa de abordarlos. Sin embargo, son un engorro final. Cualquier cambio en el gráfico se combierte en la muerte a pellizcos.
Por ejemplo:
#+BEGIN_SRC ditaa :file images/org-grafico.png :cmdline -r -s 0.8
+---------+ +---------+ +--------------+ +---------+
|{io} | | {d} | |{s} | |cBLU |
| Entrada +-->+ Doc +-->+ Almacén +-->+ Color |
| c1BA | | | | | | |
+---------+ +---------+ +-------+------+ +---------+
| +------------+
| | {o} |
| | Elipse |
| | |
| +------+-----+
v |
/-------\ | +---------+
| c2BA | | | c1AB | /-=--------\
| Forma +------*----->+ Color +------->+ punteado |
| | | | \----------/
\-------/ +---------+
#+END_SRC
Ese formato es fácilmente legible, por lo directo. Una vez procesado se convierte en un diagrama gráfico, con las líneas y formas especificadas.
Es un gráfico resultón. Pero no hay muchas más opciones, si obviamos
los cambios de color. En
el sitio de internet se
pueden ver todas las opciones que proporciona dentro del típico
README.md
de GibHub.
Otro tipo de gráficos, los de caja son también sencillos y resultones sin mucho esfuerzo. El código
#+BEGIN_SRC ditaa :file images/org-ditaa.png :cmdline -r
+--------------------------------+
| |
| Distros |
| |
+---------------+----------------+
| | |
| GNU | Linux |
| | cRED |
+---------------+----------------+
#+END_SRC
genera el siguiente gráfico:
Como se puede ver en el gráfico, las líneas las divide y separa para
hacer el gráfico de cajas. Si no se quiere este comportamiento se
puede pasar -E
en la parte de :cmdline
para que no lo haga. El
parámetro -r
que se ve en el código sirve para redondear las
esquinas.
Y no hay mucho más que explicar sobre ditaa. Quizás de los tres paquetes que he probado sea el más sencillo de entender para cualquiera, a pesar de ser texto tiene una forma muy gráfica de trabajar.
PlantUML
Este paquete gráfico es mucho más completo y tiene opciones para todos los aspectos que, –como su nombre indica– pueden necesitar las especificaciones del UML. Son tantas opciones que no caben en un articulillo como este, pero he seleccionado algunos.
El primero es un gráfico de estados –que es uno de los que me gustan de UML– y el código es muy sencillo:
#+BEGIN_SRC plantuml :file images/org-estados.png
[*] --> Estado1
Estado1 --> [*]
Estado1 : esto es una cadena
Estado1 : esto es otra cadena
Estado1 -> Estado2
Estado2 --> [*]
#+END_SRC
Este sencillo código genera un gráfico de estados (bueno, vale, el gráfico de estados también es muy sencillo) pero se puede apreciar que el resultado es bastante profesional. En cierto modo, me recuerda a los gráficos UML que se suelen ver en libros y documentos sobre programación.
Tiene muchas características interesantes, mencionaré dos que me han llamado la atención, como la posibilidad de definir iconos sólo con texto, como en el siguiente ejemplo:
#+BEGIN_SRC plantuml :file images/org-sprite.png
sprite $foo1 {
FFFFFFFFFFFFFFFF
F0123456789ABCDF
F0123456789ABCDF
F0123456789ABCDF
F0123456789ABCDF
F0123456789ABCDF
F0123456789ABCDF
F0123456789ABCDF
F0123456789ABCDF
FFFFFFFFFFFFFFFF
}
Remigio -> Abdón : y pongo un <i>sprite</i> <$foo1>
#+END_SRC
En el código se puede ver cómo con el código alfanumérico se pueden generar niveles de grises distintos... y también cómo se puede utilizar los códigos HTML para darle formato al texto de los gráficos.
Otro de los puntos de PlantUML que me ha llamado la atención es la
generación de gráficos de interfaces con la instrucción salt
.
Por ejemplo:
#+BEGIN_SRC plantuml :file images/org-interface.png
salt
{
Ejemplo de interface PlatUML
[ Esto es un botón ]
() Botón radio sin seleccionar
(X) Botón radio seleccionado
[] Caja sin seleccionar
[X] Caja seleccionada
"Entrar texto aquí "
^Esto es una lista enrollable^
}
#+END_SRC
Es también una forma bastante gráfica de trabajar sobre una interface. Permite mostrar muchos tipo de widgets para diseñar cualquier «ventanica» para una aplicación.
De este paquete hay que destacar lo completo que es. Sus gráficos son muy buenos. Son tan buenos y tan completos para el UML que no pueden utilizarse para otra cosa. Es una aplicación para un uso muy específico, pero lo que hace lo hace muy bien.
Graphviz
Mi favorito de los tres. Quizás porque lo llevo utilizando desde hace bastante tiempo para hacer gráficos. Pondré sólo un ejemplo para no extenderme demasiado:
#+BEGIN_SRC dot :file images/org-grafo.png :cmdline -Tpng
digraph g {
node [shape = record,height=.1];
node0 [label = "<f0> | <f1> "];
node1 [label = "<f0> | <f1> "];
node2 [label = "<f0> | <f1> "];
ramo -> node0:f0;
"node0":f0 -> "rosa";
"node0":f1 -> "node1":f0 [tailport=e, headport=w];
"node1":f0 -> "violeta";
"node1":f1 -> "node2":f0 [tailport=e, headport=w];
"node2":f0 -> "margarita";
"node2":f1 -> nil [tailport=e, headport=w];
{rank = same; node0; node1; node2; nil}
}
#+END_SRC
No diré mucho más sobre graphviz ni de las muchísimas opciones que se pueden utilizar. Tantas que cada vez que abro la documentación encuentro algo nuevo o aprendo a hacer algo que desconocía.
Los gráficos de flechas, entidades, cajas, cualquiera sea su
complejidad se pueden hacer con graphviz. Recuerdo un experimento
con un sociograma con 28 sujetos y el gráfico que generó fue
impresionante y el esfuerzo fue marcar cada elección de un sujeto como
->
y poniendo el nombre del seleccionado.
La salida por defecto de graphviz es quizá un poco espartano, como se puede ver en la imagen que genera. Sin embargo, con un poco de trabajo se le puede dar acabados más vistosos.
La ventaja de este paquete es que también Emacs cuenta con un modo graphviz para la edición del código.