Re: Graphic to visualize data flow between processes, buffers and files

Hello,
I think, that SVG should be preferred format too, as it (beside other
forementioned advantages):
1) Supported by DocBook
(http://www.docbook.org/tdg/en/html/svg-svg.html) and you can just embed
an image in the docbook.xml
(http://www.docbook.org/tdg5/publishers/5.1b3/en/html/_any.svg.html)
2) xml-based so it can be translated to other languages with using
well-known tools (xml2po/gettext)

I've tried to embed a sample SVG image into postgres.xml and generate
PDF with xsltproc/fop and I've got the image in the PDF.
So we don't need to introduce some complex processes to support
graphics, it's already supported by docbook.
I think we should move documentation to the XML format and then we could
use SVG for free.

Best regards,
Alexander

08.01.2016 23:52, Jürgen Purtz пишет:
>
> On 05.01.2016 20:33, Alvaro Herrera wrote:
>> As in the original discussion, this is probably too fiddly and the
>> resulting SVG files are going to be really ugly anyway. I think the
>> consensus was that we should use some toolchain that uses a source
>> format that looks like actual source code, such as the dot or xfig
>> formats, of stuff like that -- which is "compiled" into the target
>> graphic format. As I recall, what we lacked was somebody with time
>> and knowledge to actually produce a useful image starting from such a
>> source, produce Makefile rules to run the transformation from the
>> Makefiles, and to inject the image into the SGML so that it works in
>> the HTML and PDF outputs. With such a proof of concept we're much
>> more likely to take this idea seriously.
>
> I don't want to be intrusive, but obviously I didn't get the point at
> the first attempt. I hope that I now have understood the needs and
> concerns of the community: you are looking for tools and a source code
> format for SVN files which is easy to handle, diff-able and
> convertible into different graphic formats.
>
> To achieve these objectives I composed a suite of tools and templates:
>
> * The SVN file is edited with a text editor. This sounds a little
> crazy, as SVN editors are trendy and easy to handle. But in
> conjunction with a set of templates this job gets relative easy.
> Of course the developer needs some knowledge about SVN, but it is
> intended that only few and simple elements of SVN are used to keep
> the source clear. After a short period of familiarization and with
> a look at existing files everyone can work this way. Also the
> range of lines keeps small as there are predefined complex objects
> which can be included with one line of code.
> * Actually there are three files with predefined SVN objects and CSS
> definitions. This facilitates the work and leads to consistent use
> of graphic elements like fonts, colors, sizes. One file contains
> simple objects like text or ellipses with predefined attributes,
> the next one contains complex pictures like PCs, and the last one
> contains all CSS stuff.
> * As fare as I have seen, the SVN files are rendered consistently by
> browsers and image viewers. Using Inkscape in batch-mode they can
> be converted to pdf, png and other formats without loss of
> elements or significant image sharpness.
> * Using xmlling the SVN files can be validated against the SVN DTD.
> * In the readme file there are examples of converting and XML
> validation.
> * There is the problem, that Inscape does not consider external CSS
> files. I described a workaround in the CSS file.
>
> Please study the attached three example files: simple.svn,
> simple_with_external_file.svn and pg_processes.svn. The last two make
> use of pg_lib_basic_objects.svn, pg_lib_external_objects.svn and
> pg_lib_css.svn.
>
>
> Regards, Jürgen Purtz
>
>
>