Am 28.11.2016 um 10:16 schrieb Jani Nikula <jani.nik...@intel.com>: >> Since this is for "figure" AND "image" (inline) I thought it is >> better to replace. But I'am open to change this .. concrete ideas? > > Please don't shadow Sphinx directives. Otherwise people will look for > Sphinx documentation for the directive, and will be confused that it > doesn't do what the documentation says. And we'll be able to add our own > directive options to our own extensions without adding to the confusion.
OK, I will use kernel-figure mentioned by Daniel. For inline images I will use kernel-image. [snip] >>> - We don't want to do the conversion unconditionally, right? SVG works >>> just fine for HTML output, we just need to do it for latex, as I >>> understand it. >> >> OK, by this explanation, you see, we have to convert in the writer >> phase, but this will bring some other drawbacks. E.g. we have >> to touch all writers (html, latex2e etc.), this means we have to write >> our own builders for for each output format. If we wan't to be academic >> this might be the best solution, but IMO maintaining own builder >> is not what we want, so I choose the more *pragmatic* solution, >> creating all potential formats in he reading phase ... any ideas ? > > Are we just doing an unnecessary conversion when we're only building > HTML, or will HTML also use the converted files while it could use the > source format directly? It's only about unnecessary conversion. BTW I just remember: if graphviz is not available, the DOT language is inserted as literal-include. This can't be implemented in the write phase, so I think we have to accept, that a (unused) PDF is generated from a SVG even if only HTML is build. [snip] -- Markus -- -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
