Re: [Ksummit-discuss] Including images on Sphinx documents

[Johannes Berg]

On Sat, 2016-11-19 at 10:15 -0700, Jonathan Corbet wrote:
>Â
> I don't know what the ultimate source of these images is (Mauro,
> perhaps you could shed some light there?).

I'd argue that it probably no longer matters. Whether it's xfig, svg,
graphviz originally etc. - the source is probably long lost. Recreating
these images in any other format is probably not very difficult for
most or almost all of them.

> Rather than beating our heads against the wall trying to convert
> between various image formats, maybe we need to take a step
> back.ÂÂWe're trying to build better documentation, and there is
> certainly a place for diagrams and such in that
> documentation.ÂÂJohannes was asking about it for the 802.11 docs, and
> I know Paul has run into these issues with the RCU docs as
> well.ÂÂMight there be a tool or an extension out there that would
> allow us to express these diagrams in a text-friendly, editable
> form?
> 
> With some effort, I bet we could get rid of a number of the images,
> and perhaps end up with something that makes sense when read in the
> .rst source files as an extra benefit.Â

I tend to agree, and I think that having this readable in the text
would be good.

You had pointed me to this plugin before
https://pythonhosted.org/sphinxcontrib-aafig/

but I don't think it can actually represent any of the pictures.

Some surely could be represented directly by having the graphviz source
inside the rst file:
http://www.sphinx-doc.org/en/1.4.8/ext/graphviz.html

(that's even an included plugin, no need to install anything extra)

graphviz is actually quite powerful, so I suspect things like
dvbstb.png can be represented there, perhaps not pixel-identically, but
at least semantically equivalently.


However, I don't think we'll actually find a catch-all solution, so we
need to continue this discussion here for a fallback anyway - as you
stated (I snipped that quote, sorry), a picture describing the video
formats will likely not be representable in text.


As far as my use-case for sequence diagrams is concerned, I'd really
like to see this integrated with the toolchain since the source format
for them is in fact a text format.

johannes