Обсуждение: First SVG graphic
Please find in the attachment a SVG file which shows the internal structure of PG's pages and a patch to insert it to "storage.sgml". Because this is the first graphic for our documentation many additional work must be done. SvgHandling.pdf explains how to create graphics and integrate them into the textual description, which definitions are actually missing (style guide?), and what problems may occur. We shall create two new directories: doc/src/sgml/svg (as source directory for all svg files) and doc/src/sgml/html/svg. The patch for Makefile is also attached - HTML, PDF, and EPUB are tested. There is a conceptual problem with single-page HTML. The SVG files keep separate and I don't know how to include them into the generated single file "postgres.html". @Committers: If you tend to accept this patch, I will start to create wiki-pages and additional documentation pages to describe the proceeding. If you reject the patch, please give me a justification. Kind regards Jürgen Purtz
Вложения
After one week no response at all? Neither positive nor negative. It seems that the community has little interest in the SVG issue. Or in my suggestion?
Jürgen Purtz
On Wed, Nov 28, 2018 at 06:34:26PM +0100, Jürgen Purtz wrote: > After one week no response at all? Neither positive nor negative. It seems that > the community has little interest in the SVG issue. Or in my suggestion? I have been waiting for someone to take leadership on this important topic, and have read your 11-page PDF with great interest. I think your work flow on page 4 clearly illustrates that, even if we store both native, e.g., Inkscape, and optimized SVG files, we are going to have a problem. If someone takes the optimized SVG file, loads it into a tool other than the tool that created the original file, modifies it, saves new native and optimized SVG files, and then someone goes back to the original tool, the native file will not have the modifications that were made by the new tool and in the new native SVG file. This suggests we should just use one tool to handle SVG files, probably Inkscape. We can consider other tools later, but let's just standardize on one tool now and get going. I realize you can import SVG files into tools that did not create them, but it seems unlikely the new optimized SVG file will appear similar to the old one. As far as rendering in HTML, I think we have two choices: 1. make images a link to an SVG file that can be rendered in a new browser tab 2. convert the SVG to PNG for HTML rendering. I kind of prefer #2. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Wed, Nov 28, 2018 at 01:05:28PM -0500, Bruce Momjian wrote: > On Wed, Nov 28, 2018 at 06:34:26PM +0100, Jürgen Purtz wrote: > > After one week no response at all? Neither positive nor negative. It seems that > > the community has little interest in the SVG issue. Or in my suggestion? > > I have been waiting for someone to take leadership on this important > topic, and have read your 11-page PDF with great interest. Also, I like your idea of a default Inkscape configuration file. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Hi, On 2018-11-28 18:34:26 +0100, Jürgen Purtz wrote: > After one week no response at all? Neither positive nor negative. It seems > that the community has little interest in the SVG issue. Or in my > suggestion? I'd suggest describing your proposed workflow in sgml, not a pdf file. Greetings, Andres Freund
On Wed, Nov 28, 2018 at 11:46:33AM -0800, Andres Freund wrote: > Hi, > > On 2018-11-28 18:34:26 +0100, Jürgen Purtz wrote: > > After one week no response at all? Neither positive nor negative. It seems > > that the community has little interest in the SVG issue. Or in my > > suggestion? > > I'd suggest describing your proposed workflow in sgml, not a pdf file. Well, there were a number of images in the PDF that would be harder to do in SGML. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Hi, On 2018-11-28 14:49:10 -0500, Bruce Momjian wrote: > On Wed, Nov 28, 2018 at 11:46:33AM -0800, Andres Freund wrote: > > Hi, > > > > On 2018-11-28 18:34:26 +0100, Jürgen Purtz wrote: > > > After one week no response at all? Neither positive nor negative. It seems > > > that the community has little interest in the SVG issue. Or in my > > > suggestion? > > > > I'd suggest describing your proposed workflow in sgml, not a pdf file. > > Well, there were a number of images in the PDF that would be harder to > do in SGML. My point is that that description is going to be needed going forward, and thus needs to be in a normal doc format. And if the graphics therein are the first examples for graphics in PG docs, that works for me. Greetings, Andres Freund
On 2018-Nov-28, Bruce Momjian wrote: > On Wed, Nov 28, 2018 at 11:46:33AM -0800, Andres Freund wrote: > > Hi, > > > > On 2018-11-28 18:34:26 +0100, Jürgen Purtz wrote: > > > After one week no response at all? Neither positive nor negative. It seems > > > that the community has little interest in the SVG issue. Or in my > > > suggestion? > > > > I'd suggest describing your proposed workflow in sgml, not a pdf file. > > Well, there were a number of images in the PDF that would be harder to > do in SGML. I think the point is how do you integrate the images from the SVG source into the documentation output. Presumably that won't be PDF, for example the HTML output will not use a PDF as an image embedded in the page. It probably works ok for the PDF output (of the whole documentation) to use the PDF of the image ... I suppose the HTML output will need a PNG or such. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, Nov 28, 2018 at 8:53 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
On 2018-Nov-28, Bruce Momjian wrote:
> On Wed, Nov 28, 2018 at 11:46:33AM -0800, Andres Freund wrote:
> > Hi,
> >
> > On 2018-11-28 18:34:26 +0100, Jürgen Purtz wrote:
> > > After one week no response at all? Neither positive nor negative. It seems
> > > that the community has little interest in the SVG issue. Or in my
> > > suggestion?
> >
> > I'd suggest describing your proposed workflow in sgml, not a pdf file.
>
> Well, there were a number of images in the PDF that would be harder to
> do in SGML.
I think the point is how do you integrate the images from the SVG source
into the documentation output. Presumably that won't be PDF, for
example the HTML output will not use a PDF as an image embedded in the
page. It probably works ok for the PDF output (of the whole
documentation) to use the PDF of the image ... I suppose the HTML output
will need a PNG or such.
If the source is SVG, why not just use SVG? SVG support in browsers has to be pushing 10 years now, shouldn't be a problem at all... And SVG can be embedded in the HTML itself (whether that would work in this particular case I don't know, but in theory it can)
> On Wed, Nov 28, 2018 at 8:53 PM Alvaro Herrera <alvherre@2ndquadrant.com> > wrote: > >> On 2018-Nov-28, Bruce Momjian wrote: >> >> > On Wed, Nov 28, 2018 at 11:46:33AM -0800, Andres Freund wrote: >> > > Hi, >> > > >> > > On 2018-11-28 18:34:26 +0100, Jürgen Purtz wrote: >> > > > After one week no response at all? Neither positive nor negative. It >> seems >> > > > that the community has little interest in the SVG issue. Or in my >> > > > suggestion? >> > > >> > > I'd suggest describing your proposed workflow in sgml, not a pdf file. >> > >> > Well, there were a number of images in the PDF that would be harder to >> > do in SGML. >> >> I think the point is how do you integrate the images from the SVG source >> into the documentation output. Presumably that won't be PDF, for >> example the HTML output will not use a PDF as an image embedded in the >> page. It probably works ok for the PDF output (of the whole >> documentation) to use the PDF of the image ... I suppose the HTML output >> will need a PNG or such. >> >> > If the source is SVG, why not just use SVG? SVG support in browsers has to > be pushing 10 years now, shouldn't be a problem at all... And SVG can be > embedded in the HTML itself (whether that would work in this particular > case I don't know, but in theory it can) +1. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
On Thu, 29 Nov 2018 at 01:33, Jürgen Purtz <juergen@purtz.de> wrote:
After one week no response at all? Neither positive nor negative. It seems that the community has little interest in the SVG issue. Or in my suggestion?
I'm excited you're doing it. I thought it was part of an existing/ongoing discussion and didn't really have much to say. I think it's a vital step forward and we really need to get some graphics into Pg.
Personally I want to let go a bit of the diff-able, merge-able requirements and accept that not everything plays well when hand written. I got tired of the arguments that seemed to require that no tool written since 1972 could be used in our source tree lest SunOS 0.9.ancient have a fit, or someone find a (gasp) binary in a diff.
So good on you for getting positive action rolling.
On Wed, Nov 28, 2018 at 8:33 PM Jürgen Purtz <juergen@purtz.de> wrote: > > After one week no response at all? Neither positive nor negative. It seems that the community has little interest in theSVG issue. Or in my suggestion? First of all, I am BIG + for having diagrams in our documentation. I once estimated the number of diagrams in our official documentation and it was only 50 or so, that means, it is possible to make them more or less centralized, at least for the initial version. If Jurgen+ agree to work on this I would be happy to help them in the parts I was working on. For the initial version we could even provide the generated images along with SVG-source files. > > Jürgen Purtz > > -- Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
I take the reactions of the last days as a strong consent to go on with the effort to integrate graphics into the documentation and use SVG as the language which creates such graphics. Also the proposed parallel handling of two SVG files - a rich but tool-specific version (optional and not normative) and a poor tool-independent version (mandatory and normative) - for the same graphic seems to be accepted. The community agrees that this way is not optimal because the use of different SVG-tools will lead to unnecessary problems - but there is no consensus about tools.
What shall we do next:
- I will create one or more wiki pages where the procedure is described. Everybody can extend this pages or contribute to their discussion sites. The pages will be found in the category 'Documentation' and its subcategory 'SVG' (to be created).
- Actually, we have the very simple example 'PageLayout.svg' and an example of medium complexity 'gin.svg'. For testing purposes we shall have a third one of high complexity and with many different graphical elements. Can someone send such an example - as a screenshot or in any other format?
- I want to engage everybody to identify important issues of PG and visualize them (similar to Oleg's proposal). We will have a - possibly long lasting - period of experiments with different examples. I think, it's necessary that we make our experiences with different tools and proceedings (one person creates a graphic, another one contributes changes, using the same or a different tool, ...). Those examples shall not be pure academic use cases. They shall reflect real situations with the expectation to be included into the documentation - one day or another.
- In the initial phase, it may be helpful to do some centralized clearings on the first SVG source files. 'Copy&Paste' is widely used and the first examples will have the meaning of a lighthouse.
- I will contact our web-team to discuss style-guide related issues.
Kind regards, Jürgen
On Fri, Nov 30, 2018 at 06:04:06PM +0100, Jürgen Purtz wrote:
> I take the reactions of the last days as a strong consent to go on with the
> effort to integrate graphics into the documentation and use SVG as the language
> which creates such graphics. Also the proposed parallel handling of two SVG
> files - a rich but tool-specific version (optional and not normative) and a
> poor tool-independent version (mandatory and normative) - for the same graphic
> seems to be accepted. The community agrees that this way is not optimal because
> the use of different SVG-tools will lead to unnecessary problems - but there is
> no consensus about tools.
>
> What shall we do next:
>
> • I will create one or more wiki pages where the procedure is described.
> Everybody can extend this pages or contribute to their discussion sites.
> The pages will be found in the category 'Documentation' and its subcategory
> 'SVG' (to be created).
> • Actually, we have the very simple example 'PageLayout.svg' and an example
> of medium complexity 'gin.svg'. For testing purposes we shall have a third
> one of high complexity and with many different graphical elements. Can
> someone send such an example - as a screenshot or in any other format?
> • I want to engage everybody to identify important issues of PG and visualize
> them (similar to Oleg's proposal). We will have a - possibly long lasting -
> period of experiments with different examples. I think, it's necessary that
> we make our experiences with different tools and proceedings (one person
> creates a graphic, another one contributes changes, using the same or a
> different tool, ...). Those examples shall not be pure academic use cases.
> They shall reflect real situations with the expectation to be included into
> the documentation - one day or another.
> • In the initial phase, it may be helpful to do some centralized clearings on
> the first SVG source files. 'Copy&Paste' is widely used and the first
> examples will have the meaning of a lighthouse.
> • I will contact our web-team to discuss style-guide related issues.
Sounds good. I have many xfig/SVG images in my presentations if you
want to use any of them:
https://momjian.us/presentations
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
> I will create one or more wiki pages where the procedure is described. > Everybody can extend this pages or contribute to their discussion > sites. The pages will be found in the category 'Documentation' and its > subcategory 'SVG' (to be created). The wiki pages are online: https://wiki.postgresql.org/wiki/Category:SVG Kind regards Jürgen Purtz
There are three wiki pages describing the procedure: general description, Inkscape specifics, colors. You can find them in the category SVG. This mail has 3 SVG graphics attached, each in pure SVG and in Inksape SVG format. Furthermore there is a patch for the Makefile and the modifications to three sgml files, which are necessary to incorporate the graphics. Kind regards Jürgen Purtz
Вложения
a) The "Entry tree" and the "Posting trees" of the graphic "gin.svg" shows links not only from one tree-level to the next but also within each level from node to node. Is that correct? b) Is it worth to visualize PG's tree-implementation in a separate graphic - or is it the same as in every other tree-implementation that you have learned in your academic studies? If yes: in which chapter? Kind regards, Jürgen
I failed to generate the "single HTML file".
The default Makefile task, which creates multiple HTML files, works properly, because it confines itself to create links to SVG files. The SVG structure keeps hidden to the Docbook validation and processing - Docbook recognises only some additional links. What I have tried to generate a single HTML file is the use of xi:XInclude before validating and further processing. In this case the SVG structure is visible to Docbook.
In general it is possible to use SVG within Docbook 4.x, if you switch the doctype to
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook SVG Module V1.1CR1//EN" "http://www.oasis-open.org/docbook/xml/svg/1.1CR1/dbsvg.dtd"
This is an Docbook 4.x extension (https://docbook.org/specs/wd-docbook-svg-1.1cr1) for SVG-integration. But it's only a working draft from 2004, it never reached the status of an official OASIS standard. As far as I have seen, it works (with some limitations), if the SVG data is an integral part of the xml/sgml source file. I failed to combine it with xi:XInclude. In opposite to this the combination of xi:XInclude, SVG, and Docbook 5.1 works well. In my opinion this results from the fact, that the structure of Docbook 4.x is based on a DTD, whereas Docbook 5.x uses Relax-NG (and generates xsd files out of rng). DTDs natively are not namespace-aware, you must do some trickery to handle namespaces. Docbook 5.x is not only namespace aware, it natively includes definitions for SVG and other important standards like MathML.
My questions to the community are:
- Does anyone has an idea how to generate single HTML file in the actual situation?
- Shall we delay the SVG integration until we have switched to Docbook 5.x? This task is a great step, but it must be done in any case, because Docbook 4.x is outdated since many years. Btw: Because of other problems (https://github.com/docbook/docbook/issues/74) it is likely that we cannot use 5.1 but have to wait for the upcoming release 5.2.
Kind regards
Jürgen Purtz
My questions to the community are:
- Does anyone has an idea how to generate single HTML file in the actual situation?
Thanks to an additional template created by Alexander Lakhin, which extends the 'nochunk' stylesheet for SVG and MathML processing, it is now possible to create the "single HTML file" of our documentation including SVG. For me this is a working solution as long as we use Docbook 4. After the migration to Docbook 5, both languages as well as full namespace support will be natively included in Docbook.
Does anyone faced some more problems? Or can we start to include the three first SVG graphics into PG's documentation?
Kind regards
Jürgen Purtz
Вложения
On Sun, Dec 23, 2018 at 04:10:30PM +0100, Jürgen Purtz wrote: > a) The "Entry tree" and the "Posting trees" of the graphic "gin.svg" shows > links not only from one tree-level to the next but also within each level > from node to node. Is that correct? > > b) Is it worth to visualize PG's tree-implementation in a separate graphic - > or is it the same as in every other tree-implementation that you have > learned in your academic studies? If yes: in which chapter? I am CC'ing Oleg, Teodor, and Alexander, who can answer the first question, and maybe the second. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Mon, Jan 7, 2019 at 05:44:07PM +0000, Jürgen Purtz wrote: > My questions to the community are: > > □ Does anyone has an idea how to generate single HTML file in the actual > situation? > > > Thanks to an additional template created by Alexander Lakhin, which extends the > 'nochunk' stylesheet for SVG and MathML processing, it is now possible to > create the "single HTML file" of our documentation including SVG. For me this > is a working solution as long as we use Docbook 4. After the migration to > Docbook 5, both languages as well as full namespace support will be natively > included in Docbook. > > Does anyone faced some more problems? Or can we start to include the three > first SVG graphics into PG's documentation? OK, the wiki pages look good, as do the diagrams, and I think you have the process we all agreed with. Should we move ahead and commit some of these diagrams to the souce tree for PG 12? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On 2018-Dec-23, Jürgen Purtz wrote: > b) Is it worth to visualize PG's tree-implementation in a separate graphic - > or is it the same as in every other tree-implementation that you have > learned in your academic studies? If yes: in which chapter? Who's to say that every single reader of the PG documentation has had relevant academic studies? My opinion is that these graphics are worth including even if they're well-known to many. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Jan 17, 2019 at 02:49:48PM -0300, Alvaro Herrera wrote: > On 2018-Dec-23, Jürgen Purtz wrote: > > > b) Is it worth to visualize PG's tree-implementation in a separate graphic - > > or is it the same as in every other tree-implementation that you have > > learned in your academic studies? If yes: in which chapter? > > Who's to say that every single reader of the PG documentation has had > relevant academic studies? My opinion is that these graphics are worth > including even if they're well-known to many. Agreed. Indexing methods are mysterious without diagrams. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
>> Thanks to an additional template created by Alexander Lakhin, which extends the >> 'nochunk' stylesheet for SVG and MathML processing, it is now possible to >> create the "single HTML file" of our documentation including SVG. For me this >> is a working solution as long as we use Docbook 4. After the migration to >> Docbook 5, both languages as well as full namespace support will be natively >> included in Docbook. >> >> Does anyone faced some more problems? Or can we start to include the three >> first SVG graphics into PG's documentation? > > OK, the wiki pages look good, as do the diagrams, and I think you have > the process we all agreed with. Should we move ahead and commit some of > these diagrams to the souce tree for PG 12? Yes, I think we should. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
The attached patch contains all necessary changes to the sgml, svg, and Makefile. (Possibly we need some more changes regarding the 'install*' tasks of Makefile.) How to go on? Shall I send the patch to a different list or to Commitfest 2019-03? Kind regards Jürgen Purtz On 17.01.19 23:43, Tatsuo Ishii wrote: >>> Thanks to an additional template created by Alexander Lakhin, which extends the >>> 'nochunk' stylesheet for SVG and MathML processing, it is now possible to >>> create the "single HTML file" of our documentation including SVG. For me this >>> is a working solution as long as we use Docbook 4. After the migration to >>> Docbook 5, both languages as well as full namespace support will be natively >>> included in Docbook. >>> >>> Does anyone faced some more problems? Or can we start to include the three >>> first SVG graphics into PG's documentation? >> OK, the wiki pages look good, as do the diagrams, and I think you have >> the process we all agreed with. Should we move ahead and commit some of >> these diagrams to the souce tree for PG 12? > Yes, I think we should. > > Best regards, > -- > Tatsuo Ishii > SRA OSS, Inc. Japan > English: http://www.sraoss.co.jp/index_en.php > Japanese:http://www.sraoss.co.jp > >
Вложения
On Mon, Jan 21, 2019 at 03:02:43PM +0100, Jürgen Purtz wrote: > The attached patch contains all necessary changes to the sgml, svg, and > Makefile. (Possibly we need some more changes regarding the 'install*' tasks > of Makefile.) How to go on? Shall I send the patch to a different list or to > Commitfest 2019-03? This is a pretty complicated issue with a lot of back-story. I am thinking Tatsuo or me will probably commit it before March. --------------------------------------------------------------------------- > > Kind regards > > Jürgen Purtz > > > On 17.01.19 23:43, Tatsuo Ishii wrote: > >>>Thanks to an additional template created by Alexander Lakhin, which extends the > >>>'nochunk' stylesheet for SVG and MathML processing, it is now possible to > >>>create the "single HTML file" of our documentation including SVG. For me this > >>>is a working solution as long as we use Docbook 4. After the migration to > >>>Docbook 5, both languages as well as full namespace support will be natively > >>>included in Docbook. > >>> > >>>Does anyone faced some more problems? Or can we start to include the three > >>>first SVG graphics into PG's documentation? > >>OK, the wiki pages look good, as do the diagrams, and I think you have > >>the process we all agreed with. Should we move ahead and commit some of > >>these diagrams to the souce tree for PG 12? > >Yes, I think we should. > > > >Best regards, > >-- > >Tatsuo Ishii > >SRA OSS, Inc. Japan > >English: http://www.sraoss.co.jp/index_en.php > >Japanese:http://www.sraoss.co.jp > > > > > diff --git a/doc/src/sgml/Makefile b/doc/src/sgml/Makefile > index 8326c7c673..27d1e674f4 100644 > --- a/doc/src/sgml/Makefile > +++ b/doc/src/sgml/Makefile > @@ -57,6 +57,8 @@ GENERATED_SGML = version.sgml \ > > ALLSGML := $(wildcard $(srcdir)/*.sgml $(srcdir)/ref/*.sgml) $(GENERATED_SGML) > > +SVGSRC := $(wildcard $(srcdir)/svg/*.svg) > + > > ## > ## Man pages > @@ -125,10 +127,12 @@ endif > > html: html-stamp > > -html-stamp: stylesheet.xsl postgres.sgml $(ALLSGML) > +html-stamp: stylesheet.xsl postgres.sgml $(ALLSGML) $(SVGSRC) > $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^) > $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) $(XSLTPROC_HTML_FLAGS) $(wordlist 1,2,$^) > cp $(srcdir)/stylesheet.css html/ > + $(MKDIR_P) html/svg > + cp $(SVGSRC) html/svg > touch $@ > > htmlhelp: stylesheet-hh.xsl postgres.sgml $(ALLSGML) > @@ -136,7 +140,7 @@ htmlhelp: stylesheet-hh.xsl postgres.sgml $(ALLSGML) > $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) $(wordlist 1,2,$^) > > # single-page HTML > -postgres.html: stylesheet-html-nochunk.xsl postgres.sgml $(ALLSGML) > +postgres.html: stylesheet-html-nochunk.xsl postgres.sgml $(ALLSGML) $(SVGSRC) > $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^) > $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) $(XSLTPROC_HTML_FLAGS) -o $@ $(wordlist 1,2,$^) > > @@ -152,15 +156,15 @@ postgres.txt: postgres.html > postgres.pdf: > $(error Invalid target; use postgres-A4.pdf or postgres-US.pdf as targets) > > -%-A4.fo: stylesheet-fo.xsl %.sgml $(ALLSGML) > +%-A4.fo: stylesheet-fo.xsl %.sgml > $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^) > $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) --stringparam paper.type A4 -o $@ $(wordlist 1,2,$^) > > -%-US.fo: stylesheet-fo.xsl %.sgml $(ALLSGML) > +%-US.fo: stylesheet-fo.xsl %.sgml > $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^) > $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) --stringparam paper.type USletter -o $@ $(wordlist 1,2,$^) > > -%.pdf: %.fo > +%.pdf: %.fo $(ALLSGML) $(SVGSRC) > $(FOP) -fo $< -pdf $@ > > > @@ -169,7 +173,7 @@ postgres.pdf: > ## > > epub: postgres.epub > -postgres.epub: postgres.sgml $(ALLSGML) > +postgres.epub: postgres.sgml $(ALLSGML) $(SVGSRC) > $(XMLLINT) --noout --valid $< > $(DBTOEPUB) $< > > @@ -209,7 +213,7 @@ check: postgres.sgml $(ALLSGML) check-tabs > install: install-html install-man > > installdirs: > - $(MKDIR_P) '$(DESTDIR)$(htmldir)'/html $(addprefix '$(DESTDIR)$(mandir)'/man, 1 3 $(sqlmansectnum)) > + $(MKDIR_P) '$(DESTDIR)$(htmldir)'/html/svg html/svg $(addprefix '$(DESTDIR)$(mandir)'/man, 1 3 $(sqlmansectnum)) > > # If the install used a man directory shared with other applications, this will remove all files. > uninstall: > diff --git a/doc/src/sgml/gin.sgml b/doc/src/sgml/gin.sgml > index cc7cd1ed2c..195e385798 100644 > --- a/doc/src/sgml/gin.sgml > +++ b/doc/src/sgml/gin.sgml > @@ -453,6 +453,17 @@ > key values for different columns can be of different types. > </para> > > + <para> > + <mediaobject id="gin-trees-and-lists"> > + <imageobject role="html"> > + <imagedata fileref="svg/gin.svg" format="SVG" align="center" /> > + </imageobject> > + <imageobject role="fo"> > + <imagedata fileref="svg/gin.svg" format="SVG" scale="70" /> > + </imageobject> > + </mediaobject> > + </para> > + > <sect2 id="gin-fast-update"> > <title>GIN Fast Update Technique</title> > > diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml > index 9e0bb93f08..1fd9ced5f5 100644 > --- a/doc/src/sgml/ref/pg_dump.sgml > +++ b/doc/src/sgml/ref/pg_dump.sgml > @@ -73,6 +73,17 @@ PostgreSQL documentation > architectures. > </para> > > + <para> > + <mediaobject id="pg-dump-svg"> > + <imageobject role="html"> > + <imagedata fileref="svg/pgDump.svg" format="SVG" align="center" /> > + </imageobject> > + <imageobject role="fo"> > + <imagedata fileref="svg/pgDump.svg" format="SVG" scale="70" /> > + </imageobject> > + </mediaobject> > + </para> > + > <para> > When used with one of the archive file formats and combined with > <application>pg_restore</application>, > diff --git a/doc/src/sgml/storage.sgml b/doc/src/sgml/storage.sgml > index 8ef2ac8010..4d39ceb958 100644 > --- a/doc/src/sgml/storage.sgml > +++ b/doc/src/sgml/storage.sgml > @@ -775,6 +775,17 @@ data. Empty in ordinary tables.</entry> > </tgroup> > </table> > > + <para> > + <mediaobject id="PageLayoutSVG"> > + <imageobject role="html"> > + <imagedata fileref="svg/PageLayout.svg" format="SVG" align="center" /> > + </imageobject> > + <imageobject role="fo"> > + <imagedata fileref="svg/PageLayout.svg" format="SVG" scale="70" /> > + </imageobject> > + </mediaobject> > + </para> > + > <para> > > The first 24 bytes of each page consists of a page header > diff --git a/doc/src/sgml/stylesheet-html-nochunk.xsl b/doc/src/sgml/stylesheet-html-nochunk.xsl > index ffd2012e91..9e756708f5 100644 > --- a/doc/src/sgml/stylesheet-html-nochunk.xsl > +++ b/doc/src/sgml/stylesheet-html-nochunk.xsl > @@ -9,4 +9,27 @@ > <xsl:include href="stylesheet-html-common.xsl" /> > <xsl:include href="stylesheet-speedup-xhtml.xsl" /> > > +<!-- > + Integrate SVG and MathML files into the nochunk version (one single HTML file). > + After migrating to Docbook 5.x this template becomes superfluous. > +--> > +<xsl:template match="imagedata"> > + <xsl:variable name="filename"> > + <xsl:call-template name="mediaobject.filename"> > + <xsl:with-param name="object" select=".."/> > + </xsl:call-template> > + </xsl:variable> > + > + <xsl:choose> > + <!-- Handle MathML and SVG markup in imagedata --> > + <xsl:when xmlns:mml="http://www.w3.org/1998/Math/MathML" test="mml:*"> > + <xsl:apply-templates/> > + </xsl:when> > + <xsl:when xmlns:svg="http://www.w3.org/2000/svg" test="svg:*"> > + <xsl:apply-templates/> > + </xsl:when> > + </xsl:choose> > + <xsl:copy-of select="document($filename)"/> > +</xsl:template> > + > </xsl:stylesheet> > diff --git a/doc/src/sgml/svg/Inkscape/PageLayout_Inkscape.svg b/doc/src/sgml/svg/Inkscape/PageLayout_Inkscape.svg > new file mode 100644 > index 0000000000..5803077781 > --- /dev/null > +++ b/doc/src/sgml/svg/Inkscape/PageLayout_Inkscape.svg > @@ -0,0 +1,81 @@ > +<?xml version="1.0" encoding="UTF-8" standalone="no"?> > +<svg xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg"xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"width="580" height="280" viewBox="0 0 580 280" version="1.1"id="svg53" sodipodi:docname="PageLayout_Inkscape.svg" inkscape:version="0.92.3 (2405546, 2018-03-11)"> > + <metadata id="metadata57"> > + <rdf:RDF> > + <cc:Work rdf:about=""> > + <dc:format>image/svg+xml</dc:format> > + <dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> > + <dc:title></dc:title> > + </cc:Work> > + </rdf:RDF> > + </metadata> > + <sodipodi:namedview pagecolor="#ffffff" bordercolor="#666666" borderopacity="1" objecttolerance="10" gridtolerance="10"guidetolerance="10" inkscape:pageopacity="0" inkscape:pageshadow="2" inkscape:window-width="640" inkscape:window-height="480"id="namedview55" showgrid="false" inkscape:zoom="1.2896552" inkscape:cx="329.04306" inkscape:cy="137.84105"inkscape:current-layer="svg53" /> > + <style type="text/css" id="style2"> > + .text_small {font-style:normal; > + font-weight:normal; > + font-size:11px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_normal {font-style:normal; > + font-weight:normal; > + font-size:14px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_big {font-style:normal; > + font-weight:normal; > + font-size:28px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_comment {font-style:italic; > + font-weight:normal; > + font-size:14px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_mono {font-style:normal; > + font-weight:normal; > + font-size:14px; > + font-family:monospace, monospace; > + white-space:pre; > + fill:black; > + } > + </style> > + <defs id="defs7"> > + <marker id="a" markerHeight="10" markerWidth="10" orient="auto" refY="5"> > + <path d="m0 0 10 5-10 5 3-5z" id="path4" /> > + </marker> > + </defs> > + <!-- border and background --> > + <rect x="1" y="1" width="99.4%" height="99.4%" rx="1%" fill="whitesmoke" stroke="#CCCCCC" id="rect9" /> > + <!-- fill="hsl(0, 0%, 97%)" stroke="hsl(0, 0%, 80%)" /> --> > + <!-- outer rectangle and texts --> > + <rect x="20" y="80" width="500" height="150" fill="white" stroke="black" id="rect11" /> > + <text class="text_big" x="178" y="50" id="text13">Page Layout</text> > + <text class="text_mono" x="540" y="125" transform="rotate(90 540 125)" id="text15">8 k B</text> > + <text class="text_normal" x="392" y="144" id="text17">Free space</text> > + <!-- first line --> > + <rect x="20" y="80" width="90" height="30" fill="lime" stroke="black" id="rect19" /> > + <text class="text_normal" x="30" y="100" id="text21">Header</text> > + <rect x="110" y="80" width="60" height="30" fill="cornflowerblue" stroke="black" id="rect23" /> > + <text class="text_normal" x="115" y="100" id="text25">ItemId</text> > + <rect x="170" y="80" width="60" height="30" fill="cornflowerblue" stroke="black" id="rect27" /> > + <text class="text_normal" x="175" y="100" id="text29">ItemId</text> > + <path d="m235 95h78" style="marker-end:url(#a);stroke-dasharray:5, 5" stroke="black" id="path31" /> > + <path d="m184 105-71 85" style="marker-end:url(#a)" fill="none" stroke="black" id="path33" /> > + <path d="m138 105 202 85" style="marker-end:url(#a)" fill="none" stroke="black" id="path35" /> > + <!-- last line --> > + <path d="m100 215h-30" style="marker-end:url(#a);stroke-dasharray:5, 5" stroke="black" id="path37" /> > + <rect x="105" y="200" width="245" height="30" style="fill:#80BFFF" stroke="black" id="rect39" /> > + <!-- fill:hsl(210, 100%, 75%) --> > + <text class="text_normal" x="121" y="220" id="text41">Item</text> > + <rect x="345" y="200" width="85" height="30" style="fill:#80BFFF" stroke="black" id="rect43" /> > + <!-- fill:hsl(210, 100%, 75%) --> > + <text class="text_normal" x="352" y="220" id="text45">Item</text> > + <rect x="430" y="200" width="90" height="30" style="fill:springgreen" stroke="black" id="rect47" /> > + <text class="text_normal" x="440" y="220" id="text49">Special</text> > + <!-- explanation --> > + <text class="text_small" x="100" y="260" id="text51">Content grows from start to center and from end to center.</text> > +</svg> > diff --git a/doc/src/sgml/svg/Inkscape/gin_Inkscape.svg b/doc/src/sgml/svg/Inkscape/gin_Inkscape.svg > new file mode 100644 > index 0000000000..be9a9b4c73 > --- /dev/null > +++ b/doc/src/sgml/svg/Inkscape/gin_Inkscape.svg > @@ -0,0 +1,124 @@ > +<?xml version="1.0" encoding="UTF-8" standalone="no"?> > +<svg xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg"xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"width="580" height="320" viewBox="0 0 580 320" version="1.1"id="svg139" sodipodi:docname="gin_Inkscape.svg" inkscape:version="0.92.3 (2405546, 2018-03-11)"> > + <metadata id="metadata143"> > + <rdf:RDF> > + <cc:Work rdf:about=""> > + <dc:format>image/svg+xml</dc:format> > + <dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> > + </cc:Work> > + </rdf:RDF> > + </metadata> > + <sodipodi:namedview pagecolor="#ffffff" bordercolor="#666666" borderopacity="1" objecttolerance="10" gridtolerance="10"guidetolerance="10" inkscape:pageopacity="0" inkscape:pageshadow="2" inkscape:window-width="640" inkscape:window-height="480"id="namedview141" showgrid="false" inkscape:zoom="2.5793103" inkscape:cx="356.431" inkscape:cy="207.50734"inkscape:current-layer="svg139" /> > + <style type="text/css" id="style2"> > + .text_small {font-style:normal; > + font-weight:normal; > + font-size:11px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_normal {font-style:normal; > + font-weight:normal; > + font-size:14px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_big {font-style:normal; > + font-weight:normal; > + font-size:28px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_comment {font-style:italic; > + font-weight:normal; > + font-size:14px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_mono {font-style:normal; > + font-weight:normal; > + font-size:14px; > + font-family:monospace, monospace; > + white-space:pre; > + fill:black; > + } > + </style> > + <defs id="defs7"> > + <marker id="a" markerHeight="10" markerWidth="10" orient="auto" refY="5"> > + <path d="m0 0 10 5-10 5 3-5z" id="path4" /> > + </marker> > + </defs> > + <!-- border and background --> > + <rect x="1" y="1" width="99.4%" height="99.4%" rx="1%" fill="whitesmoke" stroke="#CCCCCC" id="rect9" /> > + <!-- fill="hsl(0, 0%, 97%)" stroke="hsl(0, 0%, 80%)" /> --> > + <!-- Meta page --> > + <rect x="30" y="50" width="80" height="40" fill="white" stroke="black" id="rect11" /> > + <text class="text_normal" x="32" y="65" id="text13">Meta page</text> > + <!-- Entry tree --> > + <rect x="181" y="19" width="209" height="160" fill="white" stroke="black" id="rect15" /> > + <text class="text_normal" x="186" y="35" id="text17">Entry tree</text> > + <path d="m110 70h83" style="marker-end:url(#a)" stroke="black" id="path19" /> > + <rect x="206" y="64" width="25" height="10" style="fill:lightgrey" stroke="black" id="rect21" /> > + <path d="m231 65 11-12" style="marker-end:url(#a)" stroke="black" id="path23" /> > + <path d="m231 69 11 9" style="marker-end:url(#a)" stroke="black" id="path25" /> > + <path d="m231 73 14 35" style="marker-end:url(#a)" stroke="black" id="path27" /> > + <rect x="251" y="39" width="25" height="10" style="fill:lightgrey" stroke="black" id="rect29" /> > + <rect x="251" y="79" width="25" height="10" style="fill:lightgrey" stroke="black" id="rect31" /> > + <rect x="251" y="119" width="25" height="10" style="fill:lightgrey" stroke="black" id="rect33" /> > + <path d="m266 49v18" style="marker-end:url(#a)" stroke="black" id="path35" /> > + <path d="m266 89v18" style="marker-end:url(#a)" stroke="black" id="path37" /> > + <path d="m276 44 32 -5" style="marker-end:url(#a)" stroke="black" id="path39" /> > + <path d="m276 44 32 15" style="marker-end:url(#a)" stroke="black" id="path41" /> > + <path d="m276 84 32 8" style="marker-end:url(#a)" stroke="black" id="path43" /> > + <path d="m276 124 32 0" style="marker-end:url(#a)" stroke="black" id="path45" /> > + <path d="m276 124 32 23" style="marker-end:url(#a)" stroke="black" id="path47" /> > + <rect x="320" y="30" width="25" height="10" style="fill:green" id="rect49" stroke="black" /> > + <rect x="320" y="60" width="25" height="10" style="fill:limegreen" id="rect51" stroke="black" /> > + <rect x="320" y="90" width="25" height="10" style="fill:green" id="rect53" stroke="black" /> > + <rect x="320" y="120" width="25" height="10" style="fill:limegreen" id="rect55" stroke="black" /> > + <rect x="320" y="150" width="25" height="10" style="fill:limegreen" id="rect57" stroke="black" /> > + <path d="m331 40v6" style="marker-end:url(#a)" stroke="black" id="path59" /> > + <path d="m331 70v6" style="marker-end:url(#a)" stroke="black" id="path61" /> > + <path d="m331 100v6" style="marker-end:url(#a)" stroke="black" id="path63" /> > + <path d="m331 130v6" style="marker-end:url(#a)" stroke="black" id="path65" /> > + <!-- Posting tree 1 --> > + <rect x="430" y="10" width="115" height="70" fill="white" stroke="black" id="rect67" /> > + <text class="text_normal" x="440" y="26" id="text69">Posting tree</text> > + <path d="m345 35 83 14" style="marker-end:url(#a)" stroke="black" id="path71" /> > + <rect x="440" y="45" width="25" height="10" style="fill:lightgrey" stroke="black" id="rect73" /> > + <path d="m465 50 30 -9" style="marker-end:url(#a)" stroke="black" id="path75" /> > + <path d="m465 50 30 18" style="marker-end:url(#a)" stroke="black" id="path77" /> > + <rect x="505" y="35" width="25" height="10" style="fill:limegreen" stroke="black" id="rect79" /> > + <rect x="505" y="65" width="25" height="10" style="fill:limegreen" stroke="black" id="rect81" /> > + <path d="m515 47v8" style="marker-end:url(#a)" stroke="black" id="path83" /> > + <!-- Posting tree 2 --> > + <rect x="430" y="100" width="115" height="70" fill="white" stroke="black" id="rect85" /> > + <text class="text_normal" x="440" y="115" id="text87">Posting tree</text> > + <path d="m345 95 148 37" style="marker-end:url(#a)" stroke="black" id="path89" /> > + <rect x="505" y="130" width="25" height="10" style="fill:limegreen" stroke="black" id="rect91" /> > + <!-- Posting tree 3 --> > + <rect x="430" y="190" width="115" height="70" fill="white" stroke="black" id="rect93" /> > + <text class="text_normal" x="440" y="205" id="text95">Posting tree</text> > + <path d="m345 95 85 125" style="marker-end:url(#a)" stroke="black" id="path97" /> > + <rect x="440" y="225" width="25" height="10" style="fill:lightgrey" stroke="black" id="rect99" /> > + <path d="m465 230 30 -9" style="marker-end:url(#a)" stroke="black" id="path101" /> > + <path d="m465 230 30 18" style="marker-end:url(#a)" stroke="black" id="path103" /> > + <rect x="505" y="215" width="25" height="10" style="fill:limegreen" stroke="black" id="rect105" /> > + <rect x="505" y="245" width="25" height="10" style="fill:limegreen" stroke="black" id="rect107" /> > + <path d="m515 227v8" style="marker-end:url(#a)" stroke="black" id="path109" /> > + <!-- Pending list --> > + <rect x="30" y="215" width="360" height="45" fill="white" stroke="black" id="rect111" /> > + <text class="text_normal" x="37" y="232" id="text113">Pending list</text> > + <path d="m70 90 77 138" style="fill:none;marker-end:url(#a)" stroke="black" id="path115" /> > + <rect x="155" y="235" width="25" height="10" style="fill:orangered" stroke="black" id="rect117" /> > + <rect x="210" y="235" width="25" height="10" style="fill:orangered" stroke="black" id="rect119" /> > + <rect x="265" y="235" width="25" height="10" style="fill:orangered" stroke="black" id="rect121" /> > + <rect x="320" y="235" width="25" height="10" style="fill:orangered" stroke="black" id="rect123" /> > + <path d="m180 240h18" style="marker-end:url(#a)" stroke="black" id="path125" /> > + <path d="m235 240h18" style="marker-end:url(#a)" stroke="black" id="path127" /> > + <path d="m290 240h18" style="marker-end:url(#a)" stroke="black" id="path129" /> > + <!-- Explanation --> > + <rect x="30" y="291" width="25" height="10" fill="green" stroke="black" id="rect131" /> > + <text class="text_small" x="60" y="300" id="text133">Pointers to Posting tree</text> > + <rect x="230" y="291" width="25" height="10" fill="limegreen" stroke="black" id="rect135" /> > + <text class="text_small" x="260" y="300" id="text137">Heap pointers (in Posting list or Posting tree)</text> > +</svg> > diff --git a/doc/src/sgml/svg/Inkscape/pgDump_Inkscape.svg b/doc/src/sgml/svg/Inkscape/pgDump_Inkscape.svg > new file mode 100644 > index 0000000000..3e74b485a0 > --- /dev/null > +++ b/doc/src/sgml/svg/Inkscape/pgDump_Inkscape.svg > @@ -0,0 +1,102 @@ > +<?xml version="1.0" encoding="UTF-8" standalone="no"?> > +<svg xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg"xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"width="580" height="370" viewBox="0 0 580 370" version="1.1"id="svg75" sodipodi:docname="pgDump_Inkscape.svg" inkscape:version="0.92.3 (2405546, 2018-03-11)"> > + <metadata id="metadata79"> > + <rdf:RDF> > + <cc:Work rdf:about=""> > + <dc:format>image/svg+xml</dc:format> > + <dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> > + <dc:title></dc:title> > + </cc:Work> > + </rdf:RDF> > + </metadata> > + <sodipodi:namedview pagecolor="#ffffff" bordercolor="#666666" borderopacity="1" objecttolerance="10" gridtolerance="10"guidetolerance="10" inkscape:pageopacity="0" inkscape:pageshadow="2" inkscape:window-width="640" inkscape:window-height="480"id="namedview77" showgrid="false" inkscape:zoom="0.57538462" inkscape:cx="-79.946524" inkscape:cy="185"inkscape:current-layer="svg75" /> > + <style type="text/css" id="style2"> > + .text_small {font-style:normal; > + font-weight:normal; > + font-size:11px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_normal {font-style:normal; > + font-weight:normal; > + font-size:14px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_big {font-style:normal; > + font-weight:normal; > + font-size:28px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_comment {font-style:italic; > + font-weight:normal; > + font-size:14px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_mono {font-style:normal; > + font-weight:normal; > + font-size:14px; > + font-family:monospace, monospace; > + white-space:pre; > + fill:black; > + } > + </style> > + <defs id="defs23"> > + <marker id="a" markerHeight="10" markerWidth="10" orient="auto" refY="5"> > + <path d="m0 0 10 5 -10 5 3 -5z" id="path4" /> > + </marker> > + <linearGradient id="gradient_disc" x1="0%" y1="0%" x2="100%" y2="0%"> > + <stop offset="10%" style="stop-color:white" id="stop7" /> > + <stop offset="90%" style="stop-color:steelblue" id="stop9" /> > + </linearGradient> > + <symbol id="disc" fill="url(#gradient_disc)" stroke="black"> > + <ellipse cx="52" cy="100" rx="50" ry="12" id="ellipse12" /> > + <!-- bottom --> > + <!-- hide upper half of bottom. use <rect> instead of <clipPath> to support gradient --> > + <rect x="2" y="20" width="100" height="80" stroke-width="0" id="rect14" /> > + <ellipse cx="52" cy="20" rx="50" ry="12" id="ellipse16" /> > + <!-- top --> > + <path d="m2 21 v80" id="path18" /> > + <!-- left --> > + <path d="m102 21 v80" id="path20" /> > + <!-- right --> > + </symbol> > + </defs> > + <!-- border and background --> > + <rect x="1" y="1" width="99.4%" height="99.4%" rx="1%" fill="whitesmoke" stroke="#CCCCCC" id="rect25" /> > + <!-- fill="hsl(0, 0%, 97%)" stroke="hsl(0, 0%, 80%)" /> --> > + <!-- Original DB --> > + <g transform="translate(220 10)" id="g33"> > + <use xlink:href="#disc" id="use27" /> > + <text x="25" y="60" class="text_normal" id="text29">Original</text> > + <text x="18" y="75" class="text_normal" id="text31">Database</text> > + </g> > + <text x="50" y="60" class="text_normal" id="text35">pg_dump, script format</text> > + <path d="m210 70 h-138 v40" fill="none" stroke="black" marker-end="url(#a)" id="path37" /> > + <text x="340" y="60" class="text_normal" id="text39">pg_dump, other archive formats</text> > + <path d="m340 70 h155 v40" fill="none" stroke="black" marker-end="url(#a)" id="path41" /> > + <!-- SQL script --> > + <g transform="translate(20 120)" id="g49"> > + <use xlink:href="#disc" id="use43" /> > + <text x="10" y="60" class="text_normal" id="text45">SQL INSERT</text> > + <text x="10" y="75" class="text_normal" id="text47">commands</text> > + </g> > + <text x="130" y="285" class="text_normal" id="text51">psql</text> > + <path d="m72 240 v55 h130" fill="none" stroke="black" marker-end="url(#a)" id="path53" /> > + <!-- Binary dump --> > + <g transform="translate(440 120)" id="g61"> > + <use xlink:href="#disc" id="use55" /> > + <text x="30" y="60" class="text_normal" id="text57">Binary</text> > + <text x="35" y="75" class="text_normal" id="text59">File(s)</text> > + </g> > + <text x="370" y="285" class="text_normal" id="text63">pg_restore</text> > + <path d="m495 240 v55 h-155" fill="none" stroke="black" marker-end="url(#a)" id="path65" /> > + <!-- New DB --> > + <g transform="translate(220 230)" id="g73"> > + <use xlink:href="#disc" id="use67" /> > + <text x="20" y="60" class="text_normal" id="text69">Restored</text> > + <text x="18" y="75" class="text_normal" id="text71">Database</text> > + </g> > +</svg> > diff --git a/doc/src/sgml/svg/PageLayout.svg b/doc/src/sgml/svg/PageLayout.svg > new file mode 100644 > index 0000000000..cf504ad640 > --- /dev/null > +++ b/doc/src/sgml/svg/PageLayout.svg > @@ -0,0 +1,70 @@ > +<svg width="580" height="280" viewBox="0 0 580 280" version="1.1" xmlns="http://www.w3.org/2000/svg"> > + <style type="text/css"> > + .text_small {font-style:normal; > + font-weight:normal; > + font-size:11px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_normal {font-style:normal; > + font-weight:normal; > + font-size:14px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_big {font-style:normal; > + font-weight:normal; > + font-size:28px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_comment {font-style:italic; > + font-weight:normal; > + font-size:14px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_mono {font-style:normal; > + font-weight:normal; > + font-size:14px; > + font-family:monospace, monospace; > + white-space:pre; > + fill:black; > + } > + </style> > + <defs> > + <marker id="a" markerHeight="10" markerWidth="10" orient="auto" refY="5"> > + <path d="m0 0 10 5-10 5 3-5z"/> > + </marker> > + </defs> > + > +<!-- border and background --> > + <rect x="1" y="1" width="99.4%" height="99.4%" rx="1%" > + fill="whitesmoke" stroke="#CCCCCC" /> <!-- fill="hsl(0, 0%, 97%)" stroke="hsl(0, 0%, 80%)" /> --> > +<!-- outer rectangle and texts --> > + <rect x="20" y="80" width="500" height="150" fill="white" stroke="black"/> > + <text class="text_big" x="178" y="50">Page Layout</text> > + <text class="text_mono" x="540" y="125" transform="rotate(90 540 125)">8 k B</text> > + <text class="text_normal" x="392" y="144">Free space</text> > +<!-- first line --> > + <rect x="20" y="80" width="90" height="30" fill="lime" stroke="black"/> > + <text class="text_normal" x="30" y="100">Header</text> > + <rect x="110" y="80" width="60" height="30" fill="cornflowerblue" stroke="black"/> > + <text class="text_normal" x="115" y="100">ItemId</text> > + <rect x="170" y="80" width="60" height="30" fill="cornflowerblue" stroke="black"/> > + <text class="text_normal" x="175" y="100">ItemId</text> > + <path d="m235 95h78" style="marker-end:url(#a);stroke-dasharray:5, 5" stroke="black"/> > + <path d="m184 105-71 85" style="marker-end:url(#a)" fill="none" stroke="black"/> > + <path d="m138 105 202 85" style="marker-end:url(#a)" fill="none" stroke="black"/> > +<!-- last line --> > + <path d="m100 215h-30" style="marker-end:url(#a);stroke-dasharray:5, 5" stroke="black"/> > + <rect x="105" y="200" width="245" height="30" style="fill:#80BFFF" stroke="black"/> <!-- fill:hsl(210, 100%, 75%) --> > + <text class="text_normal" x="121" y="220">Item</text> > + <rect x="345" y="200" width="85" height="30" style="fill:#80BFFF" stroke="black"/> <!-- fill:hsl(210, 100%, 75%) --> > + <text class="text_normal" x="352" y="220">Item</text> > + <rect x="430" y="200" width="90" height="30" style="fill:springgreen" stroke="black"/> > + <text class="text_normal" x="440" y="220">Special</text> > +<!-- explanation --> > + <text class="text_small" x="100" y="260">Content grows from start to center and from end to center.</text> > +</svg> > + > diff --git a/doc/src/sgml/svg/gin.svg b/doc/src/sgml/svg/gin.svg > new file mode 100644 > index 0000000000..8a5e77b252 > --- /dev/null > +++ b/doc/src/sgml/svg/gin.svg > @@ -0,0 +1,123 @@ > +<svg width="580" height="320" viewBox="0 0 580 320" version="1.1" xmlns="http://www.w3.org/2000/svg"> > + <style type="text/css"> > + .text_small {font-style:normal; > + font-weight:normal; > + font-size:11px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_normal {font-style:normal; > + font-weight:normal; > + font-size:14px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_big {font-style:normal; > + font-weight:normal; > + font-size:28px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_comment {font-style:italic; > + font-weight:normal; > + font-size:14px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_mono {font-style:normal; > + font-weight:normal; > + font-size:14px; > + font-family:monospace, monospace; > + white-space:pre; > + fill:black; > + } > + </style> > + <defs> > + <marker id="a" markerHeight="10" markerWidth="10" orient="auto" refY="5"> > + <path d="m0 0 10 5-10 5 3-5z"/> > + </marker> > + </defs> > +<!-- border and background --> > + <rect x="1" y="1" width="99.4%" height="99.4%" rx="1%" > + fill="whitesmoke" stroke="#CCCCCC" /> <!-- fill="hsl(0, 0%, 97%)" stroke="hsl(0, 0%, 80%)" /> --> > + > +<!-- Meta page --> > + <rect x="30" y="50" width="80" height="40" fill="white" stroke="black"/> > + <text class="text_normal" x="32" y="65">Meta page</text> > + > +<!-- Entry tree --> > + <rect x="181" y="19" width="209" height="160" fill="white" stroke="black"/> > + <text class="text_normal" x="186" y="35">Entry tree</text> > + <path d="m110 70h83" style="marker-end:url(#a)" stroke="black"/> > + <rect x="206" y="64" width="25" height="10" style="fill:lightgrey" stroke="black"/> > + <path d="m231 65 11-12" style="marker-end:url(#a)" stroke="black"/> > + <path d="m231 69 11 9" style="marker-end:url(#a)" stroke="black"/> > + <path d="m231 73 14 35" style="marker-end:url(#a)" stroke="black"/> > + <rect x="251" y="39" width="25" height="10" style="fill:lightgrey" stroke="black"/> > + <rect x="251" y="79" width="25" height="10" style="fill:lightgrey" stroke="black"/> > + <rect x="251" y="119" width="25" height="10" style="fill:lightgrey" stroke="black"/> > + <path d="m266 49v18" style="marker-end:url(#a)" stroke="black"/> > + <path d="m266 89v18" style="marker-end:url(#a)" stroke="black"/> > + <path d="m276 44 32 -5" style="marker-end:url(#a)" stroke="black"/> > + <path d="m276 44 32 15" style="marker-end:url(#a)" stroke="black"/> > + <path d="m276 84 32 8" style="marker-end:url(#a)" stroke="black"/> > + <path d="m276 124 32 0" style="marker-end:url(#a)" stroke="black"/> > + <path d="m276 124 32 23" style="marker-end:url(#a)" stroke="black"/> > + <rect x="320" y="30" width="25" height="10" style="fill:green" stroke="black"/> > + <rect x="320" y="60" width="25" height="10" style="fill:limegreen" stroke="black"/> > + <rect x="320" y="90" width="25" height="10" style="fill:green" stroke="black"/> > + <rect x="320" y="120" width="25" height="10" style="fill:limegreen" stroke="black"/> > + <rect x="320" y="150" width="25" height="10" style="fill:limegreen" stroke="black"/> > + <path d="m331 40v6" style="marker-end:url(#a)" stroke="black"/> > + <path d="m331 70v6" style="marker-end:url(#a)" stroke="black"/> > + <path d="m331 100v6" style="marker-end:url(#a)" stroke="black"/> > + <path d="m331 130v6" style="marker-end:url(#a)" stroke="black"/> > + > + > +<!-- Posting tree 1 --> > + <rect x="430" y="10" width="115" height="70" fill="white" stroke="black"/> > + <text class="text_normal" x="440" y="26">Posting tree</text> > + <path d="m345 35 83 14" style="marker-end:url(#a)" stroke="black"/> > + <rect x="440" y="45" width="25" height="10" style="fill:lightgrey" stroke="black"/> > + <path d="m465 50 30 -9" style="marker-end:url(#a)" stroke="black"/> > + <path d="m465 50 30 18" style="marker-end:url(#a)" stroke="black"/> > + <rect x="505" y="35" width="25" height="10" style="fill:limegreen" stroke="black"/> > + <rect x="505" y="65" width="25" height="10" style="fill:limegreen" stroke="black"/> > + <path d="m515 47v8" style="marker-end:url(#a)" stroke="black"/> > + > +<!-- Posting tree 2 --> > + <rect x="430" y="100" width="115" height="70" fill="white" stroke="black"/> > + <text class="text_normal" x="440" y="115">Posting tree</text> > + <path d="m345 95 148 37" style="marker-end:url(#a)" stroke="black"/> > + <rect x="505" y="130" width="25" height="10" style="fill:limegreen" stroke="black"/> > + > +<!-- Posting tree 3 --> > + <rect x="430" y="190" width="115" height="70" fill="white" stroke="black"/> > + <text class="text_normal" x="440" y="205">Posting tree</text> > + <path d="m345 95 85 125" style="marker-end:url(#a)" stroke="black"/> > + <rect x="440" y="225" width="25" height="10" style="fill:lightgrey" stroke="black"/> > + <path d="m465 230 30 -9" style="marker-end:url(#a)" stroke="black"/> > + <path d="m465 230 30 18" style="marker-end:url(#a)" stroke="black"/> > + <rect x="505" y="215" width="25" height="10" style="fill:limegreen" stroke="black"/> > + <rect x="505" y="245" width="25" height="10" style="fill:limegreen" stroke="black"/> > + <path d="m515 227v8" style="marker-end:url(#a)" stroke="black"/> > + > +<!-- Pending list --> > + <rect x="30" y="215" width="360" height="45" fill="white" stroke="black"/> > + <text class="text_normal" x="37" y="232">Pending list</text> > + <path d="m70 90 77 138" style="fill:none;marker-end:url(#a)" stroke="black"/> > + <rect x="155" y="235" width="25" height="10" style="fill:orangered" stroke="black"/> > + <rect x="210" y="235" width="25" height="10" style="fill:orangered" stroke="black"/> > + <rect x="265" y="235" width="25" height="10" style="fill:orangered" stroke="black"/> > + <rect x="320" y="235" width="25" height="10" style="fill:orangered" stroke="black"/> > + <path d="m180 240h18" style="marker-end:url(#a)" stroke="black"/> > + <path d="m235 240h18" style="marker-end:url(#a)" stroke="black"/> > + <path d="m290 240h18" style="marker-end:url(#a)" stroke="black"/> > + > +<!-- Explanation --> > + <rect x="30" y="291" width="25" height="10" fill="green" stroke="black"/> > + <text class="text_small" x="60" y="300">Pointers to Posting tree</text> > + <rect x="230" y="291" width="25" height="10" fill="limegreen" stroke="black"/> > + <text class="text_small" x="260" y="300">Heap pointers (in Posting list or Posting tree)</text> > + > +</svg> > diff --git a/doc/src/sgml/svg/pgDump.svg b/doc/src/sgml/svg/pgDump.svg > new file mode 100644 > index 0000000000..33e4a7d467 > --- /dev/null > +++ b/doc/src/sgml/svg/pgDump.svg > @@ -0,0 +1,96 @@ > +<svg width="580" height="370" viewBox="0 0 580 370" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> > + <style type="text/css"> > + .text_small {font-style:normal; > + font-weight:normal; > + font-size:11px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_normal {font-style:normal; > + font-weight:normal; > + font-size:14px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_big {font-style:normal; > + font-weight:normal; > + font-size:28px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_comment {font-style:italic; > + font-weight:normal; > + font-size:14px; > + font-family:"Open Sans", sans-serif; > + fill:black; > + } > + .text_mono {font-style:normal; > + font-weight:normal; > + font-size:14px; > + font-family:monospace, monospace; > + white-space:pre; > + fill:black; > + } > + </style> > + <defs> > + <marker id="a" markerHeight="10" markerWidth="10" orient="auto" refY="5"> > + <path d="m0 0 10 5 -10 5 3 -5z"/> > + </marker> > + > + <linearGradient id="gradient_disc" x1="0%" y1="0%" x2="100%" y2="0%"> > + <stop offset="10%" style="stop-color:white" /> > + <stop offset="90%" style="stop-color:steelblue" /> > + </linearGradient> > + > + <symbol id="disc" fill="url(#gradient_disc)" stroke="black"> > + <ellipse cx="52" cy="100" rx="50" ry="12" /> <!-- bottom --> > + <!-- hide upper half of bottom. use <rect> instead of <clipPath> to support gradient --> > + <rect x="2" y="20" width="100" height="80" stroke-width="0" /> > + <ellipse cx="52" cy="20" rx="50" ry="12"/> <!-- top --> > + <path d="m2 21 v80"/> <!-- left --> > + <path d="m102 21 v80"/> <!-- right --> > + </symbol> > + </defs> > + > +<!-- border and background --> > + <rect x="1" y="1" width="99.4%" height="99.4%" rx="1%" > + fill="whitesmoke" stroke="#CCCCCC" /> <!-- fill="hsl(0, 0%, 97%)" stroke="hsl(0, 0%, 80%)" /> --> > + > + <!-- Original DB --> > + <g transform="translate(220 10)"> > + <use xlink:href="#disc" /> > + <text x="25" y="60" class="text_normal">Original</text> > + <text x="18" y="75" class="text_normal">Database</text> > + </g> > + <text x="50" y="60" class="text_normal">pg_dump, script format</text> > + <path d="m210 70 h-138 v40" fill="none" stroke="black" marker-end="url(#a)"/> > + <text x="340" y="60" class="text_normal">pg_dump, other archive formats</text> > + <path d="m340 70 h155 v40" fill="none" stroke="black" marker-end="url(#a)"/> > + > + <!-- SQL script --> > + <g transform="translate(20 120)"> > + <use xlink:href="#disc"/> > + <text x="10" y="60" class="text_normal">SQL INSERT</text> > + <text x="10" y="75" class="text_normal">commands</text> > + </g> > + <text x="130" y="285" class="text_normal">psql</text> > + <path d="m72 240 v55 h130" fill="none" stroke="black" marker-end="url(#a)"/> > + > + <!-- Binary dump --> > + <g transform="translate(440 120)"> > + <use xlink:href="#disc"/> > + <text x="30" y="60" class="text_normal">Binary</text> > + <text x="35" y="75" class="text_normal">File(s)</text> > + </g> > + <text x="370" y="285" class="text_normal">pg_restore</text> > + <path d="m495 240 v55 h-155" fill="none" stroke="black" marker-end="url(#a)"/> > + > + <!-- New DB --> > + <g transform="translate(220 230)"> > + <use xlink:href="#disc"/> > + <text x="20" y="60" class="text_normal">Restored</text> > + <text x="18" y="75" class="text_normal">Database</text> > + </g> > + > +</svg> > + -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
> On Mon, Jan 21, 2019 at 03:02:43PM +0100, Jürgen Purtz wrote: >> The attached patch contains all necessary changes to the sgml, svg, and >> Makefile. (Possibly we need some more changes regarding the 'install*' tasks >> of Makefile.) How to go on? Shall I send the patch to a different list or to >> Commitfest 2019-03? > > This is a pretty complicated issue with a lot of back-story. I am > thinking Tatsuo or me will probably commit it before March. Maybe I am missing in the discussion, but I realized that the patch does not include something like "figure number". I think it would be convenient for users to find that in the index. BTW, the patch has some trailing spaces. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp > --------------------------------------------------------------------------- > > >> >> Kind regards >> >> Jürgen Purtz >> >> >> On 17.01.19 23:43, Tatsuo Ishii wrote: >> >>>Thanks to an additional template created by Alexander Lakhin, which extends the >> >>>'nochunk' stylesheet for SVG and MathML processing, it is now possible to >> >>>create the "single HTML file" of our documentation including SVG. For me this >> >>>is a working solution as long as we use Docbook 4. After the migration to >> >>>Docbook 5, both languages as well as full namespace support will be natively >> >>>included in Docbook. >> >>> >> >>>Does anyone faced some more problems? Or can we start to include the three >> >>>first SVG graphics into PG's documentation? >> >>OK, the wiki pages look good, as do the diagrams, and I think you have >> >>the process we all agreed with. Should we move ahead and commit some of >> >>these diagrams to the souce tree for PG 12? >> >Yes, I think we should. >> > >> >Best regards, >> >-- >> >Tatsuo Ishii >> >SRA OSS, Inc. Japan >> >English: http://www.sraoss.co.jp/index_en.php >> >Japanese:http://www.sraoss.co.jp >> > >> > > >> diff --git a/doc/src/sgml/Makefile b/doc/src/sgml/Makefile >> index 8326c7c673..27d1e674f4 100644 >> --- a/doc/src/sgml/Makefile >> +++ b/doc/src/sgml/Makefile >> @@ -57,6 +57,8 @@ GENERATED_SGML = version.sgml \ >> >> ALLSGML := $(wildcard $(srcdir)/*.sgml $(srcdir)/ref/*.sgml) $(GENERATED_SGML) >> >> +SVGSRC := $(wildcard $(srcdir)/svg/*.svg) >> + >> >> ## >> ## Man pages >> @@ -125,10 +127,12 @@ endif >> >> html: html-stamp >> >> -html-stamp: stylesheet.xsl postgres.sgml $(ALLSGML) >> +html-stamp: stylesheet.xsl postgres.sgml $(ALLSGML) $(SVGSRC) >> $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^) >> $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) $(XSLTPROC_HTML_FLAGS) $(wordlist 1,2,$^) >> cp $(srcdir)/stylesheet.css html/ >> + $(MKDIR_P) html/svg >> + cp $(SVGSRC) html/svg >> touch $@ >> >> htmlhelp: stylesheet-hh.xsl postgres.sgml $(ALLSGML) >> @@ -136,7 +140,7 @@ htmlhelp: stylesheet-hh.xsl postgres.sgml $(ALLSGML) >> $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) $(wordlist 1,2,$^) >> >> # single-page HTML >> -postgres.html: stylesheet-html-nochunk.xsl postgres.sgml $(ALLSGML) >> +postgres.html: stylesheet-html-nochunk.xsl postgres.sgml $(ALLSGML) $(SVGSRC) >> $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^) >> $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) $(XSLTPROC_HTML_FLAGS) -o $@ $(wordlist 1,2,$^) >> >> @@ -152,15 +156,15 @@ postgres.txt: postgres.html >> postgres.pdf: >> $(error Invalid target; use postgres-A4.pdf or postgres-US.pdf as targets) >> >> -%-A4.fo: stylesheet-fo.xsl %.sgml $(ALLSGML) >> +%-A4.fo: stylesheet-fo.xsl %.sgml >> $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^) >> $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) --stringparam paper.type A4 -o $@ $(wordlist 1,2,$^) >> >> -%-US.fo: stylesheet-fo.xsl %.sgml $(ALLSGML) >> +%-US.fo: stylesheet-fo.xsl %.sgml >> $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^) >> $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) --stringparam paper.type USletter -o $@ $(wordlist 1,2,$^) >> >> -%.pdf: %.fo >> +%.pdf: %.fo $(ALLSGML) $(SVGSRC) >> $(FOP) -fo $< -pdf $@ >> >> >> @@ -169,7 +173,7 @@ postgres.pdf: >> ## >> >> epub: postgres.epub >> -postgres.epub: postgres.sgml $(ALLSGML) >> +postgres.epub: postgres.sgml $(ALLSGML) $(SVGSRC) >> $(XMLLINT) --noout --valid $< >> $(DBTOEPUB) $< >> >> @@ -209,7 +213,7 @@ check: postgres.sgml $(ALLSGML) check-tabs >> install: install-html install-man >> >> installdirs: >> - $(MKDIR_P) '$(DESTDIR)$(htmldir)'/html $(addprefix '$(DESTDIR)$(mandir)'/man, 1 3 $(sqlmansectnum)) >> + $(MKDIR_P) '$(DESTDIR)$(htmldir)'/html/svg html/svg $(addprefix '$(DESTDIR)$(mandir)'/man, 1 3 $(sqlmansectnum)) >> >> # If the install used a man directory shared with other applications, this will remove all files. >> uninstall: >> diff --git a/doc/src/sgml/gin.sgml b/doc/src/sgml/gin.sgml >> index cc7cd1ed2c..195e385798 100644 >> --- a/doc/src/sgml/gin.sgml >> +++ b/doc/src/sgml/gin.sgml >> @@ -453,6 +453,17 @@ >> key values for different columns can be of different types. >> </para> >> >> + <para> >> + <mediaobject id="gin-trees-and-lists"> >> + <imageobject role="html"> >> + <imagedata fileref="svg/gin.svg" format="SVG" align="center" /> >> + </imageobject> >> + <imageobject role="fo"> >> + <imagedata fileref="svg/gin.svg" format="SVG" scale="70" /> >> + </imageobject> >> + </mediaobject> >> + </para> >> + >> <sect2 id="gin-fast-update"> >> <title>GIN Fast Update Technique</title> >> >> diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml >> index 9e0bb93f08..1fd9ced5f5 100644 >> --- a/doc/src/sgml/ref/pg_dump.sgml >> +++ b/doc/src/sgml/ref/pg_dump.sgml >> @@ -73,6 +73,17 @@ PostgreSQL documentation >> architectures. >> </para> >> >> + <para> >> + <mediaobject id="pg-dump-svg"> >> + <imageobject role="html"> >> + <imagedata fileref="svg/pgDump.svg" format="SVG" align="center" /> >> + </imageobject> >> + <imageobject role="fo"> >> + <imagedata fileref="svg/pgDump.svg" format="SVG" scale="70" /> >> + </imageobject> >> + </mediaobject> >> + </para> >> + >> <para> >> When used with one of the archive file formats and combined with >> <application>pg_restore</application>, >> diff --git a/doc/src/sgml/storage.sgml b/doc/src/sgml/storage.sgml >> index 8ef2ac8010..4d39ceb958 100644 >> --- a/doc/src/sgml/storage.sgml >> +++ b/doc/src/sgml/storage.sgml >> @@ -775,6 +775,17 @@ data. Empty in ordinary tables.</entry> >> </tgroup> >> </table> >> >> + <para> >> + <mediaobject id="PageLayoutSVG"> >> + <imageobject role="html"> >> + <imagedata fileref="svg/PageLayout.svg" format="SVG" align="center" /> >> + </imageobject> >> + <imageobject role="fo"> >> + <imagedata fileref="svg/PageLayout.svg" format="SVG" scale="70" /> >> + </imageobject> >> + </mediaobject> >> + </para> >> + >> <para> >> >> The first 24 bytes of each page consists of a page header >> diff --git a/doc/src/sgml/stylesheet-html-nochunk.xsl b/doc/src/sgml/stylesheet-html-nochunk.xsl >> index ffd2012e91..9e756708f5 100644 >> --- a/doc/src/sgml/stylesheet-html-nochunk.xsl >> +++ b/doc/src/sgml/stylesheet-html-nochunk.xsl >> @@ -9,4 +9,27 @@ >> <xsl:include href="stylesheet-html-common.xsl" /> >> <xsl:include href="stylesheet-speedup-xhtml.xsl" /> >> >> +<!-- >> + Integrate SVG and MathML files into the nochunk version (one single HTML file). >> + After migrating to Docbook 5.x this template becomes superfluous. >> +--> >> +<xsl:template match="imagedata"> >> + <xsl:variable name="filename"> >> + <xsl:call-template name="mediaobject.filename"> >> + <xsl:with-param name="object" select=".."/> >> + </xsl:call-template> >> + </xsl:variable> >> + >> + <xsl:choose> >> + <!-- Handle MathML and SVG markup in imagedata --> >> + <xsl:when xmlns:mml="http://www.w3.org/1998/Math/MathML" test="mml:*"> >> + <xsl:apply-templates/> >> + </xsl:when> >> + <xsl:when xmlns:svg="http://www.w3.org/2000/svg" test="svg:*"> >> + <xsl:apply-templates/> >> + </xsl:when> >> + </xsl:choose> >> + <xsl:copy-of select="document($filename)"/> >> +</xsl:template> >> + >> </xsl:stylesheet> >> diff --git a/doc/src/sgml/svg/Inkscape/PageLayout_Inkscape.svg b/doc/src/sgml/svg/Inkscape/PageLayout_Inkscape.svg >> new file mode 100644 >> index 0000000000..5803077781 >> --- /dev/null >> +++ b/doc/src/sgml/svg/Inkscape/PageLayout_Inkscape.svg >> @@ -0,0 +1,81 @@ >> +<?xml version="1.0" encoding="UTF-8" standalone="no"?> >> +<svg xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg"xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"width="580" height="280" viewBox="0 0 580 280" version="1.1"id="svg53" sodipodi:docname="PageLayout_Inkscape.svg" inkscape:version="0.92.3 (2405546, 2018-03-11)"> >> + <metadata id="metadata57"> >> + <rdf:RDF> >> + <cc:Work rdf:about=""> >> + <dc:format>image/svg+xml</dc:format> >> + <dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> >> + <dc:title></dc:title> >> + </cc:Work> >> + </rdf:RDF> >> + </metadata> >> + <sodipodi:namedview pagecolor="#ffffff" bordercolor="#666666" borderopacity="1" objecttolerance="10" gridtolerance="10"guidetolerance="10" inkscape:pageopacity="0" inkscape:pageshadow="2" inkscape:window-width="640" inkscape:window-height="480"id="namedview55" showgrid="false" inkscape:zoom="1.2896552" inkscape:cx="329.04306" inkscape:cy="137.84105"inkscape:current-layer="svg53" /> >> + <style type="text/css" id="style2"> >> + .text_small {font-style:normal; >> + font-weight:normal; >> + font-size:11px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_normal {font-style:normal; >> + font-weight:normal; >> + font-size:14px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_big {font-style:normal; >> + font-weight:normal; >> + font-size:28px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_comment {font-style:italic; >> + font-weight:normal; >> + font-size:14px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_mono {font-style:normal; >> + font-weight:normal; >> + font-size:14px; >> + font-family:monospace, monospace; >> + white-space:pre; >> + fill:black; >> + } >> + </style> >> + <defs id="defs7"> >> + <marker id="a" markerHeight="10" markerWidth="10" orient="auto" refY="5"> >> + <path d="m0 0 10 5-10 5 3-5z" id="path4" /> >> + </marker> >> + </defs> >> + <!-- border and background --> >> + <rect x="1" y="1" width="99.4%" height="99.4%" rx="1%" fill="whitesmoke" stroke="#CCCCCC" id="rect9" /> >> + <!-- fill="hsl(0, 0%, 97%)" stroke="hsl(0, 0%, 80%)" /> --> >> + <!-- outer rectangle and texts --> >> + <rect x="20" y="80" width="500" height="150" fill="white" stroke="black" id="rect11" /> >> + <text class="text_big" x="178" y="50" id="text13">Page Layout</text> >> + <text class="text_mono" x="540" y="125" transform="rotate(90 540 125)" id="text15">8 k B</text> >> + <text class="text_normal" x="392" y="144" id="text17">Free space</text> >> + <!-- first line --> >> + <rect x="20" y="80" width="90" height="30" fill="lime" stroke="black" id="rect19" /> >> + <text class="text_normal" x="30" y="100" id="text21">Header</text> >> + <rect x="110" y="80" width="60" height="30" fill="cornflowerblue" stroke="black" id="rect23" /> >> + <text class="text_normal" x="115" y="100" id="text25">ItemId</text> >> + <rect x="170" y="80" width="60" height="30" fill="cornflowerblue" stroke="black" id="rect27" /> >> + <text class="text_normal" x="175" y="100" id="text29">ItemId</text> >> + <path d="m235 95h78" style="marker-end:url(#a);stroke-dasharray:5, 5" stroke="black" id="path31" /> >> + <path d="m184 105-71 85" style="marker-end:url(#a)" fill="none" stroke="black" id="path33" /> >> + <path d="m138 105 202 85" style="marker-end:url(#a)" fill="none" stroke="black" id="path35" /> >> + <!-- last line --> >> + <path d="m100 215h-30" style="marker-end:url(#a);stroke-dasharray:5, 5" stroke="black" id="path37" /> >> + <rect x="105" y="200" width="245" height="30" style="fill:#80BFFF" stroke="black" id="rect39" /> >> + <!-- fill:hsl(210, 100%, 75%) --> >> + <text class="text_normal" x="121" y="220" id="text41">Item</text> >> + <rect x="345" y="200" width="85" height="30" style="fill:#80BFFF" stroke="black" id="rect43" /> >> + <!-- fill:hsl(210, 100%, 75%) --> >> + <text class="text_normal" x="352" y="220" id="text45">Item</text> >> + <rect x="430" y="200" width="90" height="30" style="fill:springgreen" stroke="black" id="rect47" /> >> + <text class="text_normal" x="440" y="220" id="text49">Special</text> >> + <!-- explanation --> >> + <text class="text_small" x="100" y="260" id="text51">Content grows from start to center and from end to center.</text> >> +</svg> >> diff --git a/doc/src/sgml/svg/Inkscape/gin_Inkscape.svg b/doc/src/sgml/svg/Inkscape/gin_Inkscape.svg >> new file mode 100644 >> index 0000000000..be9a9b4c73 >> --- /dev/null >> +++ b/doc/src/sgml/svg/Inkscape/gin_Inkscape.svg >> @@ -0,0 +1,124 @@ >> +<?xml version="1.0" encoding="UTF-8" standalone="no"?> >> +<svg xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg"xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"width="580" height="320" viewBox="0 0 580 320" version="1.1"id="svg139" sodipodi:docname="gin_Inkscape.svg" inkscape:version="0.92.3 (2405546, 2018-03-11)"> >> + <metadata id="metadata143"> >> + <rdf:RDF> >> + <cc:Work rdf:about=""> >> + <dc:format>image/svg+xml</dc:format> >> + <dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> >> + </cc:Work> >> + </rdf:RDF> >> + </metadata> >> + <sodipodi:namedview pagecolor="#ffffff" bordercolor="#666666" borderopacity="1" objecttolerance="10" gridtolerance="10"guidetolerance="10" inkscape:pageopacity="0" inkscape:pageshadow="2" inkscape:window-width="640" inkscape:window-height="480"id="namedview141" showgrid="false" inkscape:zoom="2.5793103" inkscape:cx="356.431" inkscape:cy="207.50734"inkscape:current-layer="svg139" /> >> + <style type="text/css" id="style2"> >> + .text_small {font-style:normal; >> + font-weight:normal; >> + font-size:11px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_normal {font-style:normal; >> + font-weight:normal; >> + font-size:14px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_big {font-style:normal; >> + font-weight:normal; >> + font-size:28px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_comment {font-style:italic; >> + font-weight:normal; >> + font-size:14px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_mono {font-style:normal; >> + font-weight:normal; >> + font-size:14px; >> + font-family:monospace, monospace; >> + white-space:pre; >> + fill:black; >> + } >> + </style> >> + <defs id="defs7"> >> + <marker id="a" markerHeight="10" markerWidth="10" orient="auto" refY="5"> >> + <path d="m0 0 10 5-10 5 3-5z" id="path4" /> >> + </marker> >> + </defs> >> + <!-- border and background --> >> + <rect x="1" y="1" width="99.4%" height="99.4%" rx="1%" fill="whitesmoke" stroke="#CCCCCC" id="rect9" /> >> + <!-- fill="hsl(0, 0%, 97%)" stroke="hsl(0, 0%, 80%)" /> --> >> + <!-- Meta page --> >> + <rect x="30" y="50" width="80" height="40" fill="white" stroke="black" id="rect11" /> >> + <text class="text_normal" x="32" y="65" id="text13">Meta page</text> >> + <!-- Entry tree --> >> + <rect x="181" y="19" width="209" height="160" fill="white" stroke="black" id="rect15" /> >> + <text class="text_normal" x="186" y="35" id="text17">Entry tree</text> >> + <path d="m110 70h83" style="marker-end:url(#a)" stroke="black" id="path19" /> >> + <rect x="206" y="64" width="25" height="10" style="fill:lightgrey" stroke="black" id="rect21" /> >> + <path d="m231 65 11-12" style="marker-end:url(#a)" stroke="black" id="path23" /> >> + <path d="m231 69 11 9" style="marker-end:url(#a)" stroke="black" id="path25" /> >> + <path d="m231 73 14 35" style="marker-end:url(#a)" stroke="black" id="path27" /> >> + <rect x="251" y="39" width="25" height="10" style="fill:lightgrey" stroke="black" id="rect29" /> >> + <rect x="251" y="79" width="25" height="10" style="fill:lightgrey" stroke="black" id="rect31" /> >> + <rect x="251" y="119" width="25" height="10" style="fill:lightgrey" stroke="black" id="rect33" /> >> + <path d="m266 49v18" style="marker-end:url(#a)" stroke="black" id="path35" /> >> + <path d="m266 89v18" style="marker-end:url(#a)" stroke="black" id="path37" /> >> + <path d="m276 44 32 -5" style="marker-end:url(#a)" stroke="black" id="path39" /> >> + <path d="m276 44 32 15" style="marker-end:url(#a)" stroke="black" id="path41" /> >> + <path d="m276 84 32 8" style="marker-end:url(#a)" stroke="black" id="path43" /> >> + <path d="m276 124 32 0" style="marker-end:url(#a)" stroke="black" id="path45" /> >> + <path d="m276 124 32 23" style="marker-end:url(#a)" stroke="black" id="path47" /> >> + <rect x="320" y="30" width="25" height="10" style="fill:green" id="rect49" stroke="black" /> >> + <rect x="320" y="60" width="25" height="10" style="fill:limegreen" id="rect51" stroke="black" /> >> + <rect x="320" y="90" width="25" height="10" style="fill:green" id="rect53" stroke="black" /> >> + <rect x="320" y="120" width="25" height="10" style="fill:limegreen" id="rect55" stroke="black" /> >> + <rect x="320" y="150" width="25" height="10" style="fill:limegreen" id="rect57" stroke="black" /> >> + <path d="m331 40v6" style="marker-end:url(#a)" stroke="black" id="path59" /> >> + <path d="m331 70v6" style="marker-end:url(#a)" stroke="black" id="path61" /> >> + <path d="m331 100v6" style="marker-end:url(#a)" stroke="black" id="path63" /> >> + <path d="m331 130v6" style="marker-end:url(#a)" stroke="black" id="path65" /> >> + <!-- Posting tree 1 --> >> + <rect x="430" y="10" width="115" height="70" fill="white" stroke="black" id="rect67" /> >> + <text class="text_normal" x="440" y="26" id="text69">Posting tree</text> >> + <path d="m345 35 83 14" style="marker-end:url(#a)" stroke="black" id="path71" /> >> + <rect x="440" y="45" width="25" height="10" style="fill:lightgrey" stroke="black" id="rect73" /> >> + <path d="m465 50 30 -9" style="marker-end:url(#a)" stroke="black" id="path75" /> >> + <path d="m465 50 30 18" style="marker-end:url(#a)" stroke="black" id="path77" /> >> + <rect x="505" y="35" width="25" height="10" style="fill:limegreen" stroke="black" id="rect79" /> >> + <rect x="505" y="65" width="25" height="10" style="fill:limegreen" stroke="black" id="rect81" /> >> + <path d="m515 47v8" style="marker-end:url(#a)" stroke="black" id="path83" /> >> + <!-- Posting tree 2 --> >> + <rect x="430" y="100" width="115" height="70" fill="white" stroke="black" id="rect85" /> >> + <text class="text_normal" x="440" y="115" id="text87">Posting tree</text> >> + <path d="m345 95 148 37" style="marker-end:url(#a)" stroke="black" id="path89" /> >> + <rect x="505" y="130" width="25" height="10" style="fill:limegreen" stroke="black" id="rect91" /> >> + <!-- Posting tree 3 --> >> + <rect x="430" y="190" width="115" height="70" fill="white" stroke="black" id="rect93" /> >> + <text class="text_normal" x="440" y="205" id="text95">Posting tree</text> >> + <path d="m345 95 85 125" style="marker-end:url(#a)" stroke="black" id="path97" /> >> + <rect x="440" y="225" width="25" height="10" style="fill:lightgrey" stroke="black" id="rect99" /> >> + <path d="m465 230 30 -9" style="marker-end:url(#a)" stroke="black" id="path101" /> >> + <path d="m465 230 30 18" style="marker-end:url(#a)" stroke="black" id="path103" /> >> + <rect x="505" y="215" width="25" height="10" style="fill:limegreen" stroke="black" id="rect105" /> >> + <rect x="505" y="245" width="25" height="10" style="fill:limegreen" stroke="black" id="rect107" /> >> + <path d="m515 227v8" style="marker-end:url(#a)" stroke="black" id="path109" /> >> + <!-- Pending list --> >> + <rect x="30" y="215" width="360" height="45" fill="white" stroke="black" id="rect111" /> >> + <text class="text_normal" x="37" y="232" id="text113">Pending list</text> >> + <path d="m70 90 77 138" style="fill:none;marker-end:url(#a)" stroke="black" id="path115" /> >> + <rect x="155" y="235" width="25" height="10" style="fill:orangered" stroke="black" id="rect117" /> >> + <rect x="210" y="235" width="25" height="10" style="fill:orangered" stroke="black" id="rect119" /> >> + <rect x="265" y="235" width="25" height="10" style="fill:orangered" stroke="black" id="rect121" /> >> + <rect x="320" y="235" width="25" height="10" style="fill:orangered" stroke="black" id="rect123" /> >> + <path d="m180 240h18" style="marker-end:url(#a)" stroke="black" id="path125" /> >> + <path d="m235 240h18" style="marker-end:url(#a)" stroke="black" id="path127" /> >> + <path d="m290 240h18" style="marker-end:url(#a)" stroke="black" id="path129" /> >> + <!-- Explanation --> >> + <rect x="30" y="291" width="25" height="10" fill="green" stroke="black" id="rect131" /> >> + <text class="text_small" x="60" y="300" id="text133">Pointers to Posting tree</text> >> + <rect x="230" y="291" width="25" height="10" fill="limegreen" stroke="black" id="rect135" /> >> + <text class="text_small" x="260" y="300" id="text137">Heap pointers (in Posting list or Posting tree)</text> >> +</svg> >> diff --git a/doc/src/sgml/svg/Inkscape/pgDump_Inkscape.svg b/doc/src/sgml/svg/Inkscape/pgDump_Inkscape.svg >> new file mode 100644 >> index 0000000000..3e74b485a0 >> --- /dev/null >> +++ b/doc/src/sgml/svg/Inkscape/pgDump_Inkscape.svg >> @@ -0,0 +1,102 @@ >> +<?xml version="1.0" encoding="UTF-8" standalone="no"?> >> +<svg xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg"xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"width="580" height="370" viewBox="0 0 580 370" version="1.1"id="svg75" sodipodi:docname="pgDump_Inkscape.svg" inkscape:version="0.92.3 (2405546, 2018-03-11)"> >> + <metadata id="metadata79"> >> + <rdf:RDF> >> + <cc:Work rdf:about=""> >> + <dc:format>image/svg+xml</dc:format> >> + <dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> >> + <dc:title></dc:title> >> + </cc:Work> >> + </rdf:RDF> >> + </metadata> >> + <sodipodi:namedview pagecolor="#ffffff" bordercolor="#666666" borderopacity="1" objecttolerance="10" gridtolerance="10"guidetolerance="10" inkscape:pageopacity="0" inkscape:pageshadow="2" inkscape:window-width="640" inkscape:window-height="480"id="namedview77" showgrid="false" inkscape:zoom="0.57538462" inkscape:cx="-79.946524" inkscape:cy="185"inkscape:current-layer="svg75" /> >> + <style type="text/css" id="style2"> >> + .text_small {font-style:normal; >> + font-weight:normal; >> + font-size:11px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_normal {font-style:normal; >> + font-weight:normal; >> + font-size:14px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_big {font-style:normal; >> + font-weight:normal; >> + font-size:28px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_comment {font-style:italic; >> + font-weight:normal; >> + font-size:14px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_mono {font-style:normal; >> + font-weight:normal; >> + font-size:14px; >> + font-family:monospace, monospace; >> + white-space:pre; >> + fill:black; >> + } >> + </style> >> + <defs id="defs23"> >> + <marker id="a" markerHeight="10" markerWidth="10" orient="auto" refY="5"> >> + <path d="m0 0 10 5 -10 5 3 -5z" id="path4" /> >> + </marker> >> + <linearGradient id="gradient_disc" x1="0%" y1="0%" x2="100%" y2="0%"> >> + <stop offset="10%" style="stop-color:white" id="stop7" /> >> + <stop offset="90%" style="stop-color:steelblue" id="stop9" /> >> + </linearGradient> >> + <symbol id="disc" fill="url(#gradient_disc)" stroke="black"> >> + <ellipse cx="52" cy="100" rx="50" ry="12" id="ellipse12" /> >> + <!-- bottom --> >> + <!-- hide upper half of bottom. use <rect> instead of <clipPath> to support gradient --> >> + <rect x="2" y="20" width="100" height="80" stroke-width="0" id="rect14" /> >> + <ellipse cx="52" cy="20" rx="50" ry="12" id="ellipse16" /> >> + <!-- top --> >> + <path d="m2 21 v80" id="path18" /> >> + <!-- left --> >> + <path d="m102 21 v80" id="path20" /> >> + <!-- right --> >> + </symbol> >> + </defs> >> + <!-- border and background --> >> + <rect x="1" y="1" width="99.4%" height="99.4%" rx="1%" fill="whitesmoke" stroke="#CCCCCC" id="rect25" /> >> + <!-- fill="hsl(0, 0%, 97%)" stroke="hsl(0, 0%, 80%)" /> --> >> + <!-- Original DB --> >> + <g transform="translate(220 10)" id="g33"> >> + <use xlink:href="#disc" id="use27" /> >> + <text x="25" y="60" class="text_normal" id="text29">Original</text> >> + <text x="18" y="75" class="text_normal" id="text31">Database</text> >> + </g> >> + <text x="50" y="60" class="text_normal" id="text35">pg_dump, script format</text> >> + <path d="m210 70 h-138 v40" fill="none" stroke="black" marker-end="url(#a)" id="path37" /> >> + <text x="340" y="60" class="text_normal" id="text39">pg_dump, other archive formats</text> >> + <path d="m340 70 h155 v40" fill="none" stroke="black" marker-end="url(#a)" id="path41" /> >> + <!-- SQL script --> >> + <g transform="translate(20 120)" id="g49"> >> + <use xlink:href="#disc" id="use43" /> >> + <text x="10" y="60" class="text_normal" id="text45">SQL INSERT</text> >> + <text x="10" y="75" class="text_normal" id="text47">commands</text> >> + </g> >> + <text x="130" y="285" class="text_normal" id="text51">psql</text> >> + <path d="m72 240 v55 h130" fill="none" stroke="black" marker-end="url(#a)" id="path53" /> >> + <!-- Binary dump --> >> + <g transform="translate(440 120)" id="g61"> >> + <use xlink:href="#disc" id="use55" /> >> + <text x="30" y="60" class="text_normal" id="text57">Binary</text> >> + <text x="35" y="75" class="text_normal" id="text59">File(s)</text> >> + </g> >> + <text x="370" y="285" class="text_normal" id="text63">pg_restore</text> >> + <path d="m495 240 v55 h-155" fill="none" stroke="black" marker-end="url(#a)" id="path65" /> >> + <!-- New DB --> >> + <g transform="translate(220 230)" id="g73"> >> + <use xlink:href="#disc" id="use67" /> >> + <text x="20" y="60" class="text_normal" id="text69">Restored</text> >> + <text x="18" y="75" class="text_normal" id="text71">Database</text> >> + </g> >> +</svg> >> diff --git a/doc/src/sgml/svg/PageLayout.svg b/doc/src/sgml/svg/PageLayout.svg >> new file mode 100644 >> index 0000000000..cf504ad640 >> --- /dev/null >> +++ b/doc/src/sgml/svg/PageLayout.svg >> @@ -0,0 +1,70 @@ >> +<svg width="580" height="280" viewBox="0 0 580 280" version="1.1" xmlns="http://www.w3.org/2000/svg"> >> + <style type="text/css"> >> + .text_small {font-style:normal; >> + font-weight:normal; >> + font-size:11px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_normal {font-style:normal; >> + font-weight:normal; >> + font-size:14px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_big {font-style:normal; >> + font-weight:normal; >> + font-size:28px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_comment {font-style:italic; >> + font-weight:normal; >> + font-size:14px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_mono {font-style:normal; >> + font-weight:normal; >> + font-size:14px; >> + font-family:monospace, monospace; >> + white-space:pre; >> + fill:black; >> + } >> + </style> >> + <defs> >> + <marker id="a" markerHeight="10" markerWidth="10" orient="auto" refY="5"> >> + <path d="m0 0 10 5-10 5 3-5z"/> >> + </marker> >> + </defs> >> + >> +<!-- border and background --> >> + <rect x="1" y="1" width="99.4%" height="99.4%" rx="1%" >> + fill="whitesmoke" stroke="#CCCCCC" /> <!-- fill="hsl(0, 0%, 97%)" stroke="hsl(0, 0%, 80%)" /> --> >> +<!-- outer rectangle and texts --> >> + <rect x="20" y="80" width="500" height="150" fill="white" stroke="black"/> >> + <text class="text_big" x="178" y="50">Page Layout</text> >> + <text class="text_mono" x="540" y="125" transform="rotate(90 540 125)">8 k B</text> >> + <text class="text_normal" x="392" y="144">Free space</text> >> +<!-- first line --> >> + <rect x="20" y="80" width="90" height="30" fill="lime" stroke="black"/> >> + <text class="text_normal" x="30" y="100">Header</text> >> + <rect x="110" y="80" width="60" height="30" fill="cornflowerblue" stroke="black"/> >> + <text class="text_normal" x="115" y="100">ItemId</text> >> + <rect x="170" y="80" width="60" height="30" fill="cornflowerblue" stroke="black"/> >> + <text class="text_normal" x="175" y="100">ItemId</text> >> + <path d="m235 95h78" style="marker-end:url(#a);stroke-dasharray:5, 5" stroke="black"/> >> + <path d="m184 105-71 85" style="marker-end:url(#a)" fill="none" stroke="black"/> >> + <path d="m138 105 202 85" style="marker-end:url(#a)" fill="none" stroke="black"/> >> +<!-- last line --> >> + <path d="m100 215h-30" style="marker-end:url(#a);stroke-dasharray:5, 5" stroke="black"/> >> + <rect x="105" y="200" width="245" height="30" style="fill:#80BFFF" stroke="black"/> <!-- fill:hsl(210, 100%, 75%) --> >> + <text class="text_normal" x="121" y="220">Item</text> >> + <rect x="345" y="200" width="85" height="30" style="fill:#80BFFF" stroke="black"/> <!-- fill:hsl(210, 100%, 75%) --> >> + <text class="text_normal" x="352" y="220">Item</text> >> + <rect x="430" y="200" width="90" height="30" style="fill:springgreen" stroke="black"/> >> + <text class="text_normal" x="440" y="220">Special</text> >> +<!-- explanation --> >> + <text class="text_small" x="100" y="260">Content grows from start to center and from end to center.</text> >> +</svg> >> + >> diff --git a/doc/src/sgml/svg/gin.svg b/doc/src/sgml/svg/gin.svg >> new file mode 100644 >> index 0000000000..8a5e77b252 >> --- /dev/null >> +++ b/doc/src/sgml/svg/gin.svg >> @@ -0,0 +1,123 @@ >> +<svg width="580" height="320" viewBox="0 0 580 320" version="1.1" xmlns="http://www.w3.org/2000/svg"> >> + <style type="text/css"> >> + .text_small {font-style:normal; >> + font-weight:normal; >> + font-size:11px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_normal {font-style:normal; >> + font-weight:normal; >> + font-size:14px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_big {font-style:normal; >> + font-weight:normal; >> + font-size:28px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_comment {font-style:italic; >> + font-weight:normal; >> + font-size:14px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_mono {font-style:normal; >> + font-weight:normal; >> + font-size:14px; >> + font-family:monospace, monospace; >> + white-space:pre; >> + fill:black; >> + } >> + </style> >> + <defs> >> + <marker id="a" markerHeight="10" markerWidth="10" orient="auto" refY="5"> >> + <path d="m0 0 10 5-10 5 3-5z"/> >> + </marker> >> + </defs> >> +<!-- border and background --> >> + <rect x="1" y="1" width="99.4%" height="99.4%" rx="1%" >> + fill="whitesmoke" stroke="#CCCCCC" /> <!-- fill="hsl(0, 0%, 97%)" stroke="hsl(0, 0%, 80%)" /> --> >> + >> +<!-- Meta page --> >> + <rect x="30" y="50" width="80" height="40" fill="white" stroke="black"/> >> + <text class="text_normal" x="32" y="65">Meta page</text> >> + >> +<!-- Entry tree --> >> + <rect x="181" y="19" width="209" height="160" fill="white" stroke="black"/> >> + <text class="text_normal" x="186" y="35">Entry tree</text> >> + <path d="m110 70h83" style="marker-end:url(#a)" stroke="black"/> >> + <rect x="206" y="64" width="25" height="10" style="fill:lightgrey" stroke="black"/> >> + <path d="m231 65 11-12" style="marker-end:url(#a)" stroke="black"/> >> + <path d="m231 69 11 9" style="marker-end:url(#a)" stroke="black"/> >> + <path d="m231 73 14 35" style="marker-end:url(#a)" stroke="black"/> >> + <rect x="251" y="39" width="25" height="10" style="fill:lightgrey" stroke="black"/> >> + <rect x="251" y="79" width="25" height="10" style="fill:lightgrey" stroke="black"/> >> + <rect x="251" y="119" width="25" height="10" style="fill:lightgrey" stroke="black"/> >> + <path d="m266 49v18" style="marker-end:url(#a)" stroke="black"/> >> + <path d="m266 89v18" style="marker-end:url(#a)" stroke="black"/> >> + <path d="m276 44 32 -5" style="marker-end:url(#a)" stroke="black"/> >> + <path d="m276 44 32 15" style="marker-end:url(#a)" stroke="black"/> >> + <path d="m276 84 32 8" style="marker-end:url(#a)" stroke="black"/> >> + <path d="m276 124 32 0" style="marker-end:url(#a)" stroke="black"/> >> + <path d="m276 124 32 23" style="marker-end:url(#a)" stroke="black"/> >> + <rect x="320" y="30" width="25" height="10" style="fill:green" stroke="black"/> >> + <rect x="320" y="60" width="25" height="10" style="fill:limegreen" stroke="black"/> >> + <rect x="320" y="90" width="25" height="10" style="fill:green" stroke="black"/> >> + <rect x="320" y="120" width="25" height="10" style="fill:limegreen" stroke="black"/> >> + <rect x="320" y="150" width="25" height="10" style="fill:limegreen" stroke="black"/> >> + <path d="m331 40v6" style="marker-end:url(#a)" stroke="black"/> >> + <path d="m331 70v6" style="marker-end:url(#a)" stroke="black"/> >> + <path d="m331 100v6" style="marker-end:url(#a)" stroke="black"/> >> + <path d="m331 130v6" style="marker-end:url(#a)" stroke="black"/> >> + >> + >> +<!-- Posting tree 1 --> >> + <rect x="430" y="10" width="115" height="70" fill="white" stroke="black"/> >> + <text class="text_normal" x="440" y="26">Posting tree</text> >> + <path d="m345 35 83 14" style="marker-end:url(#a)" stroke="black"/> >> + <rect x="440" y="45" width="25" height="10" style="fill:lightgrey" stroke="black"/> >> + <path d="m465 50 30 -9" style="marker-end:url(#a)" stroke="black"/> >> + <path d="m465 50 30 18" style="marker-end:url(#a)" stroke="black"/> >> + <rect x="505" y="35" width="25" height="10" style="fill:limegreen" stroke="black"/> >> + <rect x="505" y="65" width="25" height="10" style="fill:limegreen" stroke="black"/> >> + <path d="m515 47v8" style="marker-end:url(#a)" stroke="black"/> >> + >> +<!-- Posting tree 2 --> >> + <rect x="430" y="100" width="115" height="70" fill="white" stroke="black"/> >> + <text class="text_normal" x="440" y="115">Posting tree</text> >> + <path d="m345 95 148 37" style="marker-end:url(#a)" stroke="black"/> >> + <rect x="505" y="130" width="25" height="10" style="fill:limegreen" stroke="black"/> >> + >> +<!-- Posting tree 3 --> >> + <rect x="430" y="190" width="115" height="70" fill="white" stroke="black"/> >> + <text class="text_normal" x="440" y="205">Posting tree</text> >> + <path d="m345 95 85 125" style="marker-end:url(#a)" stroke="black"/> >> + <rect x="440" y="225" width="25" height="10" style="fill:lightgrey" stroke="black"/> >> + <path d="m465 230 30 -9" style="marker-end:url(#a)" stroke="black"/> >> + <path d="m465 230 30 18" style="marker-end:url(#a)" stroke="black"/> >> + <rect x="505" y="215" width="25" height="10" style="fill:limegreen" stroke="black"/> >> + <rect x="505" y="245" width="25" height="10" style="fill:limegreen" stroke="black"/> >> + <path d="m515 227v8" style="marker-end:url(#a)" stroke="black"/> >> + >> +<!-- Pending list --> >> + <rect x="30" y="215" width="360" height="45" fill="white" stroke="black"/> >> + <text class="text_normal" x="37" y="232">Pending list</text> >> + <path d="m70 90 77 138" style="fill:none;marker-end:url(#a)" stroke="black"/> >> + <rect x="155" y="235" width="25" height="10" style="fill:orangered" stroke="black"/> >> + <rect x="210" y="235" width="25" height="10" style="fill:orangered" stroke="black"/> >> + <rect x="265" y="235" width="25" height="10" style="fill:orangered" stroke="black"/> >> + <rect x="320" y="235" width="25" height="10" style="fill:orangered" stroke="black"/> >> + <path d="m180 240h18" style="marker-end:url(#a)" stroke="black"/> >> + <path d="m235 240h18" style="marker-end:url(#a)" stroke="black"/> >> + <path d="m290 240h18" style="marker-end:url(#a)" stroke="black"/> >> + >> +<!-- Explanation --> >> + <rect x="30" y="291" width="25" height="10" fill="green" stroke="black"/> >> + <text class="text_small" x="60" y="300">Pointers to Posting tree</text> >> + <rect x="230" y="291" width="25" height="10" fill="limegreen" stroke="black"/> >> + <text class="text_small" x="260" y="300">Heap pointers (in Posting list or Posting tree)</text> >> + >> +</svg> >> diff --git a/doc/src/sgml/svg/pgDump.svg b/doc/src/sgml/svg/pgDump.svg >> new file mode 100644 >> index 0000000000..33e4a7d467 >> --- /dev/null >> +++ b/doc/src/sgml/svg/pgDump.svg >> @@ -0,0 +1,96 @@ >> +<svg width="580" height="370" viewBox="0 0 580 370" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> >> + <style type="text/css"> >> + .text_small {font-style:normal; >> + font-weight:normal; >> + font-size:11px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_normal {font-style:normal; >> + font-weight:normal; >> + font-size:14px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_big {font-style:normal; >> + font-weight:normal; >> + font-size:28px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_comment {font-style:italic; >> + font-weight:normal; >> + font-size:14px; >> + font-family:"Open Sans", sans-serif; >> + fill:black; >> + } >> + .text_mono {font-style:normal; >> + font-weight:normal; >> + font-size:14px; >> + font-family:monospace, monospace; >> + white-space:pre; >> + fill:black; >> + } >> + </style> >> + <defs> >> + <marker id="a" markerHeight="10" markerWidth="10" orient="auto" refY="5"> >> + <path d="m0 0 10 5 -10 5 3 -5z"/> >> + </marker> >> + >> + <linearGradient id="gradient_disc" x1="0%" y1="0%" x2="100%" y2="0%"> >> + <stop offset="10%" style="stop-color:white" /> >> + <stop offset="90%" style="stop-color:steelblue" /> >> + </linearGradient> >> + >> + <symbol id="disc" fill="url(#gradient_disc)" stroke="black"> >> + <ellipse cx="52" cy="100" rx="50" ry="12" /> <!-- bottom --> >> + <!-- hide upper half of bottom. use <rect> instead of <clipPath> to support gradient --> >> + <rect x="2" y="20" width="100" height="80" stroke-width="0" /> >> + <ellipse cx="52" cy="20" rx="50" ry="12"/> <!-- top --> >> + <path d="m2 21 v80"/> <!-- left --> >> + <path d="m102 21 v80"/> <!-- right --> >> + </symbol> >> + </defs> >> + >> +<!-- border and background --> >> + <rect x="1" y="1" width="99.4%" height="99.4%" rx="1%" >> + fill="whitesmoke" stroke="#CCCCCC" /> <!-- fill="hsl(0, 0%, 97%)" stroke="hsl(0, 0%, 80%)" /> --> >> + >> + <!-- Original DB --> >> + <g transform="translate(220 10)"> >> + <use xlink:href="#disc" /> >> + <text x="25" y="60" class="text_normal">Original</text> >> + <text x="18" y="75" class="text_normal">Database</text> >> + </g> >> + <text x="50" y="60" class="text_normal">pg_dump, script format</text> >> + <path d="m210 70 h-138 v40" fill="none" stroke="black" marker-end="url(#a)"/> >> + <text x="340" y="60" class="text_normal">pg_dump, other archive formats</text> >> + <path d="m340 70 h155 v40" fill="none" stroke="black" marker-end="url(#a)"/> >> + >> + <!-- SQL script --> >> + <g transform="translate(20 120)"> >> + <use xlink:href="#disc"/> >> + <text x="10" y="60" class="text_normal">SQL INSERT</text> >> + <text x="10" y="75" class="text_normal">commands</text> >> + </g> >> + <text x="130" y="285" class="text_normal">psql</text> >> + <path d="m72 240 v55 h130" fill="none" stroke="black" marker-end="url(#a)"/> >> + >> + <!-- Binary dump --> >> + <g transform="translate(440 120)"> >> + <use xlink:href="#disc"/> >> + <text x="30" y="60" class="text_normal">Binary</text> >> + <text x="35" y="75" class="text_normal">File(s)</text> >> + </g> >> + <text x="370" y="285" class="text_normal">pg_restore</text> >> + <path d="m495 240 v55 h-155" fill="none" stroke="black" marker-end="url(#a)"/> >> + >> + <!-- New DB --> >> + <g transform="translate(220 230)"> >> + <use xlink:href="#disc"/> >> + <text x="20" y="60" class="text_normal">Restored</text> >> + <text x="18" y="75" class="text_normal">Database</text> >> + </g> >> + >> +</svg> >> + > > > -- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + As you are, so once was I. As I am, so you will be. + > + Ancient Roman grave inscription + >
On 24/01/2019 00:53, Bruce Momjian wrote: > This is a pretty complicated issue with a lot of back-story. I am > thinking Tatsuo or me will probably commit it before March. Isn't that all the more reason to add it to the commitfest? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Jan 25, 2019 at 10:39:28AM +0100, Peter Eisentraut wrote: > On 24/01/2019 00:53, Bruce Momjian wrote: > > This is a pretty complicated issue with a lot of back-story. I am > > thinking Tatsuo or me will probably commit it before March. > > Isn't that all the more reason to add it to the commitfest? Uh, if you think so. Please add it then. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
> On 24/01/2019 00:53, Bruce Momjian wrote: >> This is a pretty complicated issue with a lot of back-story. I am >> thinking Tatsuo or me will probably commit it before March. > > Isn't that all the more reason to add it to the commitfest? +1. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
On 25.01.19 10:39, Peter Eisentraut wrote:
On 24/01/2019 00:53, Bruce Momjian wrote:This is a pretty complicated issue with a lot of back-story. I am thinking Tatsuo or me will probably commit it before March.Isn't that all the more reason to add it to the commitfest?
I added it to commitfest 2019-03.
In the attachment you find a new patch which extends the first one in regards of three topics:
- Index terms for each graphic
- List of figures in the TOC for HTML and PDF output
- More or less a side-effect: List of tables and examples for HTML. This already exists for PDF.
- (In a future version there may also be a 'List of Program-Listings'. But this requires some more actions.)
Kind regards, Jürgen Purtz
Вложения
First, let's fix some of these whitespace errors: firstSvg_2.patch:677: trailing whitespace. <rect x="1" y="1" width="99.4%" height="99.4%" rx="1%" firstSvg_2.patch:752: trailing whitespace. <rect x="1" y="1" width="99.4%" height="99.4%" rx="1%" firstSvg_2.patch:705: new blank line at EOF. + firstSvg_2.patch:936: new blank line at EOF. + warning: 4 lines add whitespace errors. Let's not use mixed-case file names: Inkscape/ PageLayout.svg gin.svg pgDump.svg > @@ -152,15 +156,15 @@ postgres.txt: postgres.html > postgres.pdf: > $(error Invalid target; use postgres-A4.pdf or postgres-US.pdf as targets) > > -%-A4.fo: stylesheet-fo.xsl %.sgml $(ALLSGML) > +%-A4.fo: stylesheet-fo.xsl %.sgml > $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^) > $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) --stringparam paper.type A4 -o $@ $(wordlist 1,2,$^) > > -%-US.fo: stylesheet-fo.xsl %.sgml $(ALLSGML) > +%-US.fo: stylesheet-fo.xsl %.sgml > $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^) > $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) --stringparam paper.type USletter -o $@ $(wordlist 1,2,$^) > > -%.pdf: %.fo > +%.pdf: %.fo $(ALLSGML) $(SVGSRC) > $(FOP) -fo $< -pdf $@ > This seems a bit wrong. The .fo target does depend on ALLSGML. The .pdf target does not, but it presumably does depend on SVGSRC. The variable name SVGSRC is a bit confusing. What is it the source of? > @@ -209,7 +213,7 @@ check: postgres.sgml $(ALLSGML) check-tabs > install: install-html install-man > > installdirs: > - $(MKDIR_P) '$(DESTDIR)$(htmldir)'/html $(addprefix '$(DESTDIR)$(mandir)'/man, 1 3 $(sqlmansectnum)) > + $(MKDIR_P) '$(DESTDIR)$(htmldir)'/html/svg html/svg $(addprefix '$(DESTDIR)$(mandir)'/man, 1 3 $(sqlmansectnum)) > > # If the install used a man directory shared with other applications, this will remove all files. > uninstall: html/svg is not an installation directory. You need to create it somewhere else. > + <part> > + <title>Lists of Figures, Tables and Examples</title> > + <appendix id="list-of-figures"> > + <title>List of Figures</title> > + <para /> > + </appendix> > + <appendix id="list-of-tables"> > + <title>List of Tables</title> > + <para /> > + </appendix> > + <appendix id="list-of-examples"> > + <title>List of Examples</title> > + <para /> > + </appendix> > + </part> These ought to be created by the stylesheet. We have probably turned them off somewhere, so you should see where you can turn them on. > diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml > index 9e0bb93f08..d31ee2d210 100644 > --- a/doc/src/sgml/ref/pg_dump.sgml > +++ b/doc/src/sgml/ref/pg_dump.sgml > @@ -73,6 +73,21 @@ > architectures. > </para> > > + <figure id="pg_dump_svg"> > + <title><command>pg_dump</command>: Formats and Restore Proceedings</title> This doesn't work for man page output. I think we should avoid putting images into reference pages. This one could perhaps go into the Backup chapter. Also, it should be linked to from somewhere. An image that's just floating around and not referred to in the text seems odd. Also we tend to use hyphens instead of underscores for IDs. (At some point, underscores where not allowed. I'm surprised that that's no longer the case.) I also wouldn't put "_svg" into the ID. The format is irrelevant to the ID. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 07.02.19 12:06, Peter Eisentraut wrote:
First, let's fix some of these whitespace errors: firstSvg_2.patch:677: trailing whitespace. <rect x="1" y="1" width="99.4%" height="99.4%" rx="1%" firstSvg_2.patch:752: trailing whitespace. <rect x="1" y="1" width="99.4%" height="99.4%" rx="1%" firstSvg_2.patch:705: new blank line at EOF. + firstSvg_2.patch:936: new blank line at EOF. + warning: 4 lines add whitespace errors.
Done.
Done.Let's not use mixed-case file names: Inkscape/ PageLayout.svg gin.svg pgDump.svg
It's a transitive dependency: the pdf target is triggered after changes in svg (or sgml), this triggers the fo targets. Therefore it's not necessary to have svg (or sgml) dependencies at the fo level.@@ -152,15 +156,15 @@ postgres.txt: postgres.html postgres.pdf: $(error Invalid target; use postgres-A4.pdf or postgres-US.pdf as targets) -%-A4.fo: stylesheet-fo.xsl %.sgml $(ALLSGML) +%-A4.fo: stylesheet-fo.xsl %.sgml $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^) $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) --stringparam paper.type A4 -o $@ $(wordlist 1,2,$^) -%-US.fo: stylesheet-fo.xsl %.sgml $(ALLSGML) +%-US.fo: stylesheet-fo.xsl %.sgml $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^) $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) --stringparam paper.type USletter -o $@ $(wordlist 1,2,$^) -%.pdf: %.fo +%.pdf: %.fo $(ALLSGML) $(SVGSRC) $(FOP) -fo $< -pdf $@This seems a bit wrong. The .fo target does depend on ALLSGML. The .pdf target does not, but it presumably does depend on SVGSRC.
The variable SVGSRC points to all svg-files, similar to ALLSGML which points to the sgml files. Whenever any of them changes, certain targets will fire.The variable name SVGSRC is a bit confusing. What is it the source of?
Please help. I haven't understood the distinction between installation directory and DESTDIR. On the other hand, in the Makefile there is a - redundant - command within the html-stamp target: $(MKDIR_P) html/svg. But this will run frequently, which is not necessary.@@ -209,7 +213,7 @@ check: postgres.sgml $(ALLSGML) check-tabs install: install-html install-man installdirs: - $(MKDIR_P) '$(DESTDIR)$(htmldir)'/html $(addprefix '$(DESTDIR)$(mandir)'/man, 1 3 $(sqlmansectnum)) + $(MKDIR_P) '$(DESTDIR)$(htmldir)'/html/svg html/svg $(addprefix '$(DESTDIR)$(mandir)'/man, 1 3 $(sqlmansectnum)) # If the install used a man directory shared with other applications, this will remove all files. uninstall:html/svg is not an installation directory. You need to create it somewhere else.
+ <part> + <title>Lists of Figures, Tables and Examples</title> + <appendix id="list-of-figures"> + <title>List of Figures</title> + <para /> + </appendix> + <appendix id="list-of-tables"> + <title>List of Tables</title> + <para /> + </appendix> + <appendix id="list-of-examples"> + <title>List of Examples</title> + <para /> + </appendix> + </part>These ought to be created by the stylesheet. We have probably turned them off somewhere, so you should see where you can turn them on.
There is a simple mechanism to create those list of figures: change line 55 of stylesheet-html-common.xsl to "book toc,title,figure". But the result is ugly - see attached screenshot. The list is out-of-line. Additionally, in the future we will have many figures (and examples and tables). This will lead to similar problems we actually faced with the release notes. The proposed solution moves this inflation of lists to deeper levels of the TOC. We can and have defined theirs layout within stylesheet-common.xsl.
diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml index 9e0bb93f08..d31ee2d210 100644 --- a/doc/src/sgml/ref/pg_dump.sgml +++ b/doc/src/sgml/ref/pg_dump.sgml @@ -73,6 +73,21 @@ architectures. </para> + <figure id="pg_dump_svg"> + <title><command>pg_dump</command>: Formats and Restore Proceedings</title>This doesn't work for man page output. I think we should avoid putting images into reference pages. This one could perhaps go into the Backup chapter.
What is the problem here? Actually I don't have enough time to evaluate it in deep. If it is an urgent problem (I have seen that the commitfest-entry is tagged as "release 12") we shall shift the pg_dump figure to a later release.
I think that the Backup chapter isn't a good place for this because it does not explain the complete interaction between pg_dump, psql and restore.
Done. (But I hate the use of the minus-signs within any identifier of any language. For me it's an operator.)Also, it should be linked to from somewhere. An image that's just floating around and not referred to in the text seems odd. Also we tend to use hyphens instead of underscores for IDs. (At some point, underscores where not allowed. I'm surprised that that's no longer the case.)
I also wouldn't put "_svg" into the ID. The format is irrelevant to the ID.
I changed _svg to _figure. I agree that the format is irrelevant. But it may be of interest, whether it is an id to a text or a figure.
Kind regards, Jürgen
Вложения
On 07/02/2019 18:11, Jürgen Purtz wrote: >>> @@ -152,15 +156,15 @@ postgres.txt: postgres.html >>> postgres.pdf: >>> $(error Invalid target; use postgres-A4.pdf or postgres-US.pdf as targets) >>> >>> -%-A4.fo: stylesheet-fo.xsl %.sgml $(ALLSGML) >>> +%-A4.fo: stylesheet-fo.xsl %.sgml >>> $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^) >>> $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) --stringparam paper.type A4 -o $@ $(wordlist 1,2,$^) >>> >>> -%-US.fo: stylesheet-fo.xsl %.sgml $(ALLSGML) >>> +%-US.fo: stylesheet-fo.xsl %.sgml >>> $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^) >>> $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) --stringparam paper.type USletter -o $@ $(wordlist 1,2,$^) >>> >>> -%.pdf: %.fo >>> +%.pdf: %.fo $(ALLSGML) $(SVGSRC) >>> $(FOP) -fo $< -pdf $@ >>> >> This seems a bit wrong. The .fo target does depend on ALLSGML. The >> .pdf target does not, but it presumably does depend on SVGSRC. > It's a transitive dependency: the pdf target is triggered after changes > in svg (or sgml), this triggers the fo targets. Therefore it's not > necessary to have svg (or sgml) dependencies at the fo level. If $(ALLSGML) changes, then the .fo file needs to be rebuilt. If $(SVGSRC) changes, then the .pdf file needs to be rebuilt. So those two groups of files need to be handled differently. The way you have written it, a change in $(ALLSGML) will just rebuild the .pdf file from a stale .fo. >> The variable name SVGSRC is a bit confusing. What is it the source of? > The variable SVGSRC points to all svg-files, similar to ALLSGML which > points to the sgml files. Whenever any of them changes, certain targets > will fire. Right, so maybe name it ALLSVG? >>> @@ -209,7 +213,7 @@ check: postgres.sgml $(ALLSGML) check-tabs >>> install: install-html install-man >>> >>> installdirs: >>> - $(MKDIR_P) '$(DESTDIR)$(htmldir)'/html $(addprefix '$(DESTDIR)$(mandir)'/man, 1 3 $(sqlmansectnum)) >>> + $(MKDIR_P) '$(DESTDIR)$(htmldir)'/html/svg html/svg $(addprefix '$(DESTDIR)$(mandir)'/man, 1 3 $(sqlmansectnum)) >>> >>> # If the install used a man directory shared with other applications, this will remove all files. >>> uninstall: >> html/svg is not an installation directory. You need to create it >> somewhere else. > Please help. I haven't understood the distinction between installation > directory and DESTDIR. On the other hand, in the Makefile there is a - > redundant - command within the html-stamp target: $(MKDIR_P) html/svg. > But this will run frequently, which is not necessary. Right, so you probably don't need this change in the installdirs target at all. > There is a simple mechanism to create those list of figures: change line > 55 of stylesheet-html-common.xsl to "book toc,title,*figure*". But > the result is ugly - see attached screenshot. The list is out-of-line. > Additionally, in the future we will have many figures (and examples and > tables). This will lead to similar problems we actually faced with the > release notes. Maybe we don't need a list of figures at all? Let's just turn it off if we don't like it. > What is the problem here? Actually I don't have enough time to evaluate > it in deep. If it is an urgent problem (I have seen that the > commitfest-entry is tagged as "release 12") we shall shift the pg_dump > figure to a later release. The problem is that images don't show up in man pages, so we can't put any images in there, or it will look silly. > I think that the Backup chapter isn't a good place for this because it > does not explain the complete interaction between pg_dump, psql and restore. Then maybe it should explain it. The pg_dump man page should be strictly about pg_dump. The Backup chapter should explain how it fits together with the other tools. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
The graphic for dump/restore is transferred from 'pg_dump utility' chapter to the 'backup and restore' chapter in sgml/backup.sgml. In this chapter I made a lot of textual changes to explain the relation between pg_dump, pg_restore and psql in more detail. Especially I tried to introduce a more stringent use of terms, eg: avoiding 'archive' because this term is used with a different meaning in the PITR chapter. (It would be a good idea to do the same for the description of the pg_dump utility.) Because I'm not a native English speaker, feel free to correct my wording. The list of figures as well as lists of other prominent elements are removed. 'lists in TOC' seems to be a topic of its own and will be resumed later. Kind regards, Jürgen
Вложения
On 2019-02-15 11:58, Jürgen Purtz wrote: > The graphic for dump/restore is transferred from 'pg_dump utility' > chapter to the 'backup and restore' chapter in sgml/backup.sgml. In this > chapter I made a lot of textual changes to explain the relation between > pg_dump, pg_restore and psql in more detail. Especially I tried to > introduce a more stringent use of terms, eg: avoiding 'archive' because > this term is used with a different meaning in the PITR chapter. (It > would be a good idea to do the same for the description of the pg_dump > utility.) Because I'm not a native English speaker, feel free to correct > my wording. I think we should have some in-tree documentation about how to edit images, probably at doc/src/sgml/svg/README. You had published some of that documentation earlier in this thread, and whatever is relevant to developers should be included in the tree. I'm specifically wondering about the relationship between the *.svg and the inkscape/*.svg files. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 20.02.19 17:28, Peter Eisentraut wrote: > On 2019-02-15 11:58, Jürgen Purtz wrote: >> The graphic for dump/restore is transferred from 'pg_dump utility' >> chapter to the 'backup and restore' chapter in sgml/backup.sgml. In this >> chapter I made a lot of textual changes to explain the relation between >> pg_dump, pg_restore and psql in more detail. Especially I tried to >> introduce a more stringent use of terms, eg: avoiding 'archive' because >> this term is used with a different meaning in the PITR chapter. (It >> would be a good idea to do the same for the description of the pg_dump >> utility.) Because I'm not a native English speaker, feel free to correct >> my wording. > I think we should have some in-tree documentation about how to edit > images, probably at doc/src/sgml/svg/README. You had published some of > that documentation earlier in this thread, and whatever is relevant to > developers should be included in the tree. I'm specifically wondering > about the relationship between the *.svg and the inkscape/*.svg files. Good idea. README is created. Also chapter "J.4. Documentation Authoring" has some enhancements to differentiate between text and graphic. It's also possible that we will see more sub-chapters in J.4 in the future, e.g.: "Creating Mathematical Formulas". Kind regards, Jürgen
Вложения
How do you get from the Inkscape SVG files to the what you call "optimized SVG" files? I loaded the gin_inkscape.svg file into Inkscape, saved it back out as "Plain SVG", but the resultant file did not look at all similar to the existing gin.svg. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 08.03.19 18:55, Peter Eisentraut wrote: > How do you get from the Inkscape SVG files to the what you call > "optimized SVG" files? > > I loaded the gin_inkscape.svg file into Inkscape, saved it back out as > "Plain SVG", but the resultant file did not look at all similar to the > existing gin.svg. > Inkscape supports a lot of different formats. "Plain SVG" and "Optimized SVG" are two of them - and they differ in some aspects. "Plain SVG" is in some respect garrulous and generates unnecessary elements: namespaces, metadata, IDs, XML-entities. "Optimized SVG" avoids them, as long as you follow the hints described in https://wiki.postgresql.org/wiki/SVG_using_Inkscape. Conclusion: People working with Inkscape shall avoid "Plain SVG" and use "Optimized SVG". Nevertheless Peter points out an important aspect. If you generate "Optimized SVG" out of the uploaded files, they look different in comparison to their original version. As mentioned in https://wiki.postgresql.org/wiki/SVG_using_Inkscape#Manual_corrections, it is possible - and sometimes advised - to manually 'optimize' the generated "Optimized SVG" file. I used this technique and tried to make the files good readable for everyone, especially because we are in an early phase of SVG integration. But apparently I have overstressed this possibility. You will find the following differences between the uploaded 'additionally manually optimized' files and the generated "Optimized SVG" files: - newlines - <g stroke="black"> element. This is an Inkscape optimization, which generates a group out of those elements, which are in a sequence and use - by chance - the same stroke-attribute. This optimization step is purely formal and in my opinion misuses the meaning of the <g> element as a cramp for logically related elements, e.g. to resize or transform them simultaneously. As an example of such differences I append two files: gin.svg ("Optimized SVG" plus my manually optimizations; the originally uploaded file) and gin_pure_opt.svg (pure "Optimized SVG"). What is your opinion? Should we renounce the additional manual step and use only the pure "Optimized SVG" format? This will increase the 'diff-ablility', which may be valuable in the long term. But direct readability of the files suffers more or less. Kind regards, Jürgen
Вложения
On Sat, Mar 9, 2019 at 02:17:33PM +0300, Jürgen Purtz wrote:
> As an example of such differences I append two files: gin.svg ("Optimized
> SVG" plus my manually optimizations; the originally uploaded file) and
> gin_pure_opt.svg (pure "Optimized SVG").
>
> What is your opinion? Should we renounce the additional manual step and use
> only the pure "Optimized SVG" format? This will increase the
> 'diff-ablility', which may be valuable in the long term. But direct
> readability of the files suffers more or less.
Uh, so really there is plain SVG, "Optimized SVG", and readable SVG. I
am thinking you should store just "Optimized SVG", and provide a shell
script to convert to readable SVG for those that want it.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Bruce Momjian <bruce@momjian.us> writes:
> On Sat, Mar 9, 2019 at 02:17:33PM +0300, Jürgen Purtz wrote:
>> What is your opinion? Should we renounce the additional manual step and use
>> only the pure "Optimized SVG" format? This will increase the
>> 'diff-ablility', which may be valuable in the long term. But direct
>> readability of the files suffers more or less.
> Uh, so really there is plain SVG, "Optimized SVG", and readable SVG. I
> am thinking you should store just "Optimized SVG", and provide a shell
> script to convert to readable SVG for those that want it.
Man, this discussion is leaving me disheartened. It sure sounds like
we are going to end up in a situation where either everyone touching
the graphics has to use the same version of the same tool (with the
same options, even), or else we're going to have massive, unreadable,
and mostly content-free diffs in every patch.
regards, tom lane
On Sat, Mar 9, 2019 at 11:49:31AM -0500, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > On Sat, Mar 9, 2019 at 02:17:33PM +0300, Jürgen Purtz wrote: > >> What is your opinion? Should we renounce the additional manual step and use > >> only the pure "Optimized SVG" format? This will increase the > >> 'diff-ablility', which may be valuable in the long term. But direct > >> readability of the files suffers more or less. > > > Uh, so really there is plain SVG, "Optimized SVG", and readable SVG. I > > am thinking you should store just "Optimized SVG", and provide a shell > > script to convert to readable SVG for those that want it. > > Man, this discussion is leaving me disheartened. It sure sounds like > we are going to end up in a situation where either everyone touching > the graphics has to use the same version of the same tool (with the > same options, even), or else we're going to have massive, unreadable, > and mostly content-free diffs in every patch. Yes, that might end up being the case. I think the only saving part is that we aren't going to have lots of people editing the graphics. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Please forget the term "plain SVG". What we are speaking about is: (1) "Inkscape-original" format (2) "Optimized SVG" format (3) No. (2) plus"Manually modifications". Obviously this is too complicate to handle. Therefore we shall also forget no. (3). I made a small modification to the generation process of (2) by throwing the comments away (it's actually not documented in the wiki): "Save As" / "Optimized SVG Output" / "SVG Output" tab / "Remove comments" checkbox. The result is an easy readable file, without comments, without empty lines, diff-ing is easy. The only drawback is the strange <g stroke="black"> element, which may confuse at the first glance. But I can live with that. In a simple graphic it's obvious, what happens. In a complex graphic the likelihood of such a situation is low. Regarding comments, I believe tool-users will seldom use them. We can do without comments in the svg files of the repository. So find two files in the attachment: format (1): gin_Inkscape.svg and format (2): gin.svg. Kind regards, Jürgen Purtz
Вложения
I played with this further. My conclusion is that SVG as a source format is not workable. Aside from the tooling issues that are being discussed, which might be solvable, I think it's not the right level of abstraction. The problem is that it is a *vector* format, but not a *graph* or *chart* format. You can draw boxes and lines and text, but nothing in the format indicates how they are connected. You can see that in the provided example graphs: The alignment of the arrow tips to the boxes and the text in the boxes is not pixel-perfect. If you open this in Inkscape and move a box around, the edges don't move with it. The final appearance of the picture is subject to how shaky the hand holding the mouse was. ;-) I suppose experienced graphics artists have ways to deal with that, but they are not in evidence here. I'm thinking of someone, say, adding a tweak to the GIN code and wanting to update the image, and I don't see that as being pleasant. I looked at some alternatives. I rebuilt the GIN image using Graphviz and the page layout image using Ditaa. See attached patch. The results look fine and useful to me. I would be much more comfortable using those tools: They use a higher level of abstraction, so an author can focus on the logical structure of the image and not the pixel details. The source formats are easily diffable. Both can convert to SVG, so the rest of the tooling can still be used. (I didn't find the pg_dump image all that useful, so I didn't do anything with it here. But I think it could be done using either Ditaa or Graphviz.) Using SVG as an output format looks good. It works in HTML, PDF, and EPUB. I did some tweaks to your tooling so that the images scale automatically in the PDF output. Everything looks good, so I would be happy to proceed in this direction. (We can have some discussion about whether we want to commit the intermediate SVG files and what the directory layout should be etc. I didn't bother with that in my patch yet.) -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> I played with this further. My conclusion is that SVG as a source
> format is not workable. Aside from the tooling issues that are being
> discussed, which might be solvable, I think it's not the right level of
> abstraction.
It does seem like using SVG as an intermediate format rather than a source
format might be a better idea.
> (We can have some discussion about whether we want to commit the
> intermediate SVG files and what the directory layout should be etc. I
> didn't bother with that in my patch yet.)
Ideally, we'd treat them much as we do for bison output files:
we'll supply them in tarballs but you'd better have the relevant
tools if you want to build docs from a git pull. However, that
may be assuming too much about the portability of the tools ...
regards, tom lane
On 11.03.19 12:13, Peter Eisentraut wrote: > I played with this further. My conclusion is that SVG as a source > format is not workable. Aside from the tooling issues that are being > discussed, which might be solvable, I think it's not the right level of > abstraction. The problem is that it is a *vector* format, but not a > *graph* or *chart* format. You can draw boxes and lines and text, but > nothing in the format indicates how they are connected. Yes, SVG knows nothing about higher level concepts. That's one of the reasons why there are tools to create SVG, eg. Inkscape with the connectors feature (it was not used in the examples but obviously it's possible.) > I looked at some alternatives. I rebuilt the GIN image using Graphviz > and the page layout image using Ditaa. That was the heart of the proposal: Since we couldn't find consensus about a single tool in the long lasting discussion, everybody shall use his favourite tool and deliver the original source plus a SVG version. Kind regards, Jürgen Purtz
On 2019-03-11 15:50, Tom Lane wrote: > Ideally, we'd treat them much as we do for bison output files: > we'll supply them in tarballs but you'd better have the relevant > tools if you want to build docs from a git pull. However, that > may be assuming too much about the portability of the tools ... The portability is not something I'm concerned about, but Ditaa requires Java, so that might annoy some people. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2019-03-11 15:50, Tom Lane wrote:
>> Ideally, we'd treat them much as we do for bison output files:
>> we'll supply them in tarballs but you'd better have the relevant
>> tools if you want to build docs from a git pull. However, that
>> may be assuming too much about the portability of the tools ...
> The portability is not something I'm concerned about, but Ditaa requires
> Java, so that might annoy some people.
Portability is something you *should* be concerned about. We want
all patch submitters to be able to build the docs, else we'll forever
be fighting silly markup errors. That's not a productive use of
anybody's time.
regards, tom lane
On 2019-03-14 14:10, Tom Lane wrote: >> The portability is not something I'm concerned about, but Ditaa requires >> Java, so that might annoy some people. > Portability is something you *should* be concerned about. We want > all patch submitters to be able to build the docs, else we'll forever > be fighting silly markup errors. That's not a productive use of > anybody's time. Let me rephrase: I'm agree that portability is important, and I'm confident that the tools in question are portable enough. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
This has been committed. The SVG images are committed as well, so no new tools are required. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, Mar 27, 2019 at 3:17 PM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > This has been committed. The SVG images are committed as well, so no > new tools are required. Apparently it's possible to run Ditaa over the web. Perhaps we'll figure out a way to have contributors validate their changes through a browser, rather than expecting them to install Java locally. I don't think that it's necessary to have something like that available immediately. It is an option, though. -- Peter Geoghegan
> This has been committed. The SVG images are committed as well, so no > new tools are required. Is it possible to generate figure indexes? Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> This has been committed. The SVG images are committed as well, so no
> new tools are required.
Buildfarm member alabio seems less than pleased.
regards, tom lane
On 28.03.19 00:41, Tatsuo Ishii wrote: > Is it possible to generate figure indexes? This is an additional topic and there was a brief discussion on 7 February (and in older conversations) regarding this. It concerns list of figures, tables, and examples. I intend to make a proposal around May 2019. Kind regards Jürgen Purtz
On 2019-03-28 01:50, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> This has been committed. The SVG images are committed as well, so no >> new tools are required. > > Buildfarm member alabio seems less than pleased. See <https://askubuntu.com/questions/695560/assistive-technology-not-found-awterror> for how to fix that build issue. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> This has been committed. The SVG images are committed as well, so no > new tools are required. What is the policy of adding graphics to PostgreSQL 12? Is it encouraged to add more graphics to 12 docs? Or do we want to prohibit it? Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
On 2019-03-28 09:03, Tatsuo Ishii wrote: >> This has been committed. The SVG images are committed as well, so no >> new tools are required. > > What is the policy of adding graphics to PostgreSQL 12? Is it > encouraged to add more graphics to 12 docs? Or do we want to prohibit > it? I have nothing against a few more, especially if they stay within the provided tooling. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Mar 28, 2019 at 8:50 AM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
On 2019-03-28 01:50, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> This has been committed. The SVG images are committed as well, so no
>> new tools are required.
>
> Buildfarm member alabio seems less than pleased.
See
<https://askubuntu.com/questions/695560/assistive-technology-not-found-awterror>
for how to fix that build issue.
Ugh. If I understand it right, that's something that will happen to anybody who tries to build the docs on a headless server, which is not exactly uncommon :/
Can we find a way to override it in the command? Or if not, we should probably at least document it in our docs?
I have done this on alabio now, let's see if it recovers.
On Thu, Mar 28, 2019 at 9:59 AM Magnus Hagander <magnus@hagander.net> wrote:
On Thu, Mar 28, 2019 at 8:50 AM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:On 2019-03-28 01:50, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> This has been committed. The SVG images are committed as well, so no
>> new tools are required.
>
> Buildfarm member alabio seems less than pleased.
See
<https://askubuntu.com/questions/695560/assistive-technology-not-found-awterror>
for how to fix that build issue.Ugh. If I understand it right, that's something that will happen to anybody who tries to build the docs on a headless server, which is not exactly uncommon :/Can we find a way to override it in the command? Or if not, we should probably at least document it in our docs?I have done this on alabio now, let's see if it recovers.
FYI, it did recover. Per above, I think this is something we should document.
On 28.03.19 09:52, Peter Eisentraut wrote: > On 2019-03-28 09:03, Tatsuo Ishii wrote: >>> This has been committed. The SVG images are committed as well, so no >>> new tools are required. >> What is the policy of adding graphics to PostgreSQL 12? Is it >> encouraged to add more graphics to 12 docs? Or do we want to prohibit >> it? > I have nothing against a few more, especially if they stay within the > provided tooling. > Because many of the prospective authors voted for Inkscape in the course of this discussion, there shall be at least one example in Inkscape format. There were reservations against the published Inkscape files because they didn't made use of any 'higher-level-concept'. Please find a new Inkscape version of the pg_dump which uses such concepts. It groups texts and paths together to logical units (disc with explanation). You can rearrange such units as a whole or align a set of them to left, top, ... with Inkscape (iconized) commands. Additionally those objects are linked together with connectors to rearrange their position by drag-and-drop. The resulting file in 'Optimized' version is also attached. Kind regards, Jürgen
Вложения
On 2019-03-28 11:04, Magnus Hagander wrote: > See > <https://askubuntu.com/questions/695560/assistive-technology-not-found-awterror> > for how to fix that build issue. > > > Ugh. If I understand it right, that's something that will happen to > anybody who tries to build the docs on a headless server, which is > not exactly uncommon :/ > > Can we find a way to override it in the command? Or if not, we > should probably at least document it in our docs? > > I have done this on alabio now, let's see if it recovers. > > > FYI, it did recover. Per above, I think this is something we should > document. It seems like this is a Debian/Ubuntu-specific packaging issue. We could document it, but I wonder if it's just a transient thing. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2019-03-28 12:24, Jürgen Purtz wrote: > Because many of the prospective authors voted for Inkscape in the course > of this discussion, there shall be at least one example in Inkscape format. Well, my vote is against doing anything with Inkscape, at least until other possibilities are exhausted. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Mar 28, 2019, at 1:08 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:On 2019-03-28 12:24, Jürgen Purtz wrote:Because many of the prospective authors voted for Inkscape in the course
of this discussion, there shall be at least one example in Inkscape format.
Well, my vote is against doing anything with Inkscape, at least until
other possibilities are exhausted.
Has anyone found an svg editor that works good on a Mac. I tried the MacPorts version of inkscape as recommended by the inkscape website and it won’t open a file so I’m not sure it works at all.
I did find another editor https://github.com/dsward2/macSVG and it seems to work, but have not used it much.
Neil
I think we should first exhaust all options to use the currently
supported formats, before adding a new controversial one. You can use
the {s} qualifier for a box in ditaa and it'll show a disk; this ascii
diagram produces a "similar enough" image to your diagram, for example:
+------------+ +---------+
| Original | pg_dump, other archive formats | Binary |
| Database |------------------------------->| File(s) |
| {s}| | {s} |
+------------+ +---------+
| |
| pg_dump, script format | pg_restore
| |
v v
+------------+ +----------+
| SQL INSERT | psql | Restored |
| commands |------------------------------>| Database |
| {s} | | {s}|
+------------+ +----------+
It takes more time to write this email than to get the diagram done.
(I say "controversial" about inkscape because it was initially claimed
that the output was going to be clean/readable/diffable, and that's what
got so many upvotes. After the admission that that's not so, I suspect
votes for inkscape have decreased somewhat.)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
