Subject: Re: Graphic to visualize data flow between processes, buffers
 and files
To: pgsql-docs@postgresql.org
References: <20160105193334.GA296052@alvherre.pgsql>
 <5690218B.9060103@purtz.de>
From: Alexander Law <exclusion@gmail.com>
Cc: =?UTF-8?Q?J=c3=bcrgen_Purtz?= <juergen@purtz.de>
Message-ID: <569BB477.6010405@gmail.com>
Date: Sun, 17 Jan 2016 18:34:15 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <5690218B.9060103@purtz.de>
Content-Type: multipart/alternative;
 boundary="------------020800070804070207020509"
Precedence: bulk
Sender: pgsql-docs-owner@postgresql.org

This is a multi-part message in MIME format.
--------------020800070804070207020509
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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
>
>
>


--------------020800070804070207020509
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hello,<br>
      I think, that SVG should be preferred format too, as it (beside
      other forementioned advantages):<br>
      1) Supported by DocBook
      (<a class="moz-txt-link-freetext" href="http://www.docbook.org/tdg/en/html/svg-svg.html">http://www.docbook.org/tdg/en/html/svg-svg.html</a>) and you can just
      embed an image in the docbook.xml
      (<a class="moz-txt-link-freetext" href="http://www.docbook.org/tdg5/publishers/5.1b3/en/html/_any.svg.html">http://www.docbook.org/tdg5/publishers/5.1b3/en/html/_any.svg.html</a>).<br>
      2) xml-based so it can be translated to other languages with using
      well-known tools (xml2po/gettext)<br>
      <br>
      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.<br>
      So we don't need to introduce some complex processes to support
      graphics, it's already supported by docbook.<br>
      I think we should move documentation to the XML format and then we
      could use SVG for free.<br>
      <br>
      Best regards,<br>
      Alexander<br>
      <br>
      <br>
      <br>
      08.01.2016 23:52, Jürgen Purtz пишет:<br>
    </div>
    <blockquote cite="mid:5690218B.9060103@purtz.de" type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      <br>
      <div class="moz-cite-prefix">On 05.01.2016 20:33, Alvaro Herrera
        wrote:<br>
      </div>
      <blockquote cite="mid:20160105193334.GA296052@alvherre.pgsql"
        type="cite"> 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. </blockquote>
      <br>
      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.<br>
      <br>
      To achieve these objectives I composed a suite of tools and
      templates:<br>
      <ul>
        <li>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.</li>
        <li>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.</li>
        <li>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.</li>
        <li>Using xmlling the SVN files can be validated against the SVN
          DTD.</li>
        <li>In the readme file there are examples of converting and XML
          validation.</li>
        <li>There is the problem, that Inscape does not consider
          external CSS files. I described a workaround in the CSS file.<br>
        </li>
      </ul>
      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.<br>
      <br>
      <br>
      Regards, Jürgen Purtz<br>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------020800070804070207020509--