From: Alexander Law <exclusion@gmail.com>
To: pgsql-docs@postgresql.org
Cc: Jürgen Purtz <juergen@purtz.de>
Subject: Re: Graphic to visualize data flow between processes, buffers and files
Date: Sun, 17 Jan 2016 18:34:15 +0300
Message-ID: <569BB477.6010405@gmail.com> (raw)
In-Reply-To: <5690218B.9060103@purtz.de>
References: <20160105193334.GA296052@alvherre.pgsql>
<5690218B.9060103@purtz.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-docs>
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
>
>
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: exclusion@gmail.com, juergen@purtz.de
Subject: Re: Graphic to visualize data flow between processes, buffers and files
In-Reply-To: <569BB477.6010405@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox