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
