Re: Getting our tables to render better in PDF output
Corey Huinker writes: > On Sat, Apr 11, 2020 at 6:41 PM Tom Lane wrote: >> Don't have a strong opinion about that, but it'd sure be a lot of new >> anchors. > So I can't speak to any scalability issues for adding a bunch of refs, I did a quick check by adding id tags to all 700-or-so s in func.sgml (don't get excited, it was a perl one-liner that just added random id strings). The runtime difference for building the HTML docs seems to be under 1%, and negligible for PDF output. So it looks like we don't have to worry about scalability of tagging all the functions. regards, tom lane
Re: Getting our tables to render better in PDF output
On Sun, Apr 12, 2020 at 8:38 PM Tom Lane wrote: > Corey Huinker writes: > > On Sat, Apr 11, 2020 at 6:41 PM Tom Lane wrote: > >> Is that going to be a problem for the docs toolchain? If > >> the anchors are attached to individual function names rather than > >> sections or paragraphs, do they actually work well as link references? > >> (I'm particularly wondering how an would render.) > > > So I can't speak to any scalability issues for adding a bunch of refs, > but > > I did try this out for justify_days() (diff attached) and here's what I > > found: > > * justify_days > >This made a link, in the same font as any other link ref. > > * > >This made a link that looks exactly like the previous one, with the > text > > "justify_days", so if we're fine with the font change, we could use that > > * > linkend="function-justify-days">justify_days > >This made the link we want in the function font. > > Hm. Attaching the link ID to an is an interesting hack. > it worked for glossterms, I figured an indexterm is just another 'term. > My inclination is to standardize on using for references and > just accept the lack of a special font. It's not worth the notational > pain to use both and , especially not in HTML output > where links will probably get rendered specially anyway. We > previously made the same tradeoff with respect to GUC variables, > and I've not seen many complaints. (I experimented with putting > into the indexterm text, but that did not help.) > > I'd be a bit inclined to shorten the ID prefix to "func-", just > in the interests of carpal tunnel avoidance. > xref it is. I'll take a shot and scripting the necessary changes.
Re: Improve This Sentence?
On Fri, Apr 10, 2020 at 06:32:05PM +, PG Doc comments form wrote: > On Linux and POSIX platforms checkpoint_flush_after allows to force the OS > that pages written by the checkpoint should be flushed to disk after a > configurable number of bytes. > > I think I have an idea what it says, but saw some discussion to this very > issue. Can it be re-written? How would you suggest to rewrite it? -- Michael signature.asc Description: PGP signature
Re: Getting our tables to render better in PDF output
Corey Huinker writes: > On Sat, Apr 11, 2020 at 6:41 PM Tom Lane wrote: >> Is that going to be a problem for the docs toolchain? If >> the anchors are attached to individual function names rather than >> sections or paragraphs, do they actually work well as link references? >> (I'm particularly wondering how an would render.) > So I can't speak to any scalability issues for adding a bunch of refs, but > I did try this out for justify_days() (diff attached) and here's what I > found: > * justify_days >This made a link, in the same font as any other link ref. > * >This made a link that looks exactly like the previous one, with the text > "justify_days", so if we're fine with the font change, we could use that > * linkend="function-justify-days">justify_days >This made the link we want in the function font. Hm. Attaching the link ID to an is an interesting hack. It makes me nervous, because it's not immediately obvious that that won't cause links to lead to someplace in the index. Still, it does seem to work the way we want in both HTML and PDF output, so maybe we can get away with it. We've previously found that attaching an ID to a does *not* work, at least not in PDF --- see the existing attempts for function-encode and function-decode, which give rise to PDF build warnings and no functioning links. I checked just now and attaching the ID to the acts the same, so it seems it's or nothing. My inclination is to standardize on using for references and just accept the lack of a special font. It's not worth the notational pain to use both and , especially not in HTML output where links will probably get rendered specially anyway. We previously made the same tradeoff with respect to GUC variables, and I've not seen many complaints. (I experimented with putting into the indexterm text, but that did not help.) I'd be a bit inclined to shorten the ID prefix to "func-", just in the interests of carpal tunnel avoidance. regards, tom lane
Re: Getting our tables to render better in PDF output
Alexander Lakhin writes: > 12.04.2020 20:33, Tom Lane wrote: >> I educated myself a teensy bit about XSL, and unless I'm missing >> something, this is really pretty darn trivial; the attached seems >> to do the trick. > I've come to almost the same solution simultaneously. I think this > should work for us. Thanks for looking at it! I did some more polishing on the first batch of tables and pushed it --- see what you think. regards, tom lane
Re: Getting our tables to render better in PDF output
Hello Tom, 12.04.2020 20:33, Tom Lane wrote: > I wrote: >> So if we can get to both insert a right arrow and switch the >> font to match 's choice, this would work more or less decently, and >> it's probably cleaner than the bare-entity-reference approach I posted >> before. I don't have the XSL skills to get that to work though. >> Anyone want to help out? > I educated myself a teensy bit about XSL, and unless I'm missing > something, this is really pretty darn trivial; the attached seems > to do the trick. I've come to almost the same solution simultaneously. I think this should work for us. Best regards, Alexander
Re: Getting our tables to render better in PDF output
I wrote: > So if we can get to both insert a right arrow and switch the > font to match 's choice, this would work more or less decently, and > it's probably cleaner than the bare-entity-reference approach I posted > before. I don't have the XSL skills to get that to work though. > Anyone want to help out? I educated myself a teensy bit about XSL, and unless I'm missing something, this is really pretty darn trivial; the attached seems to do the trick. I experimented with the markup from and decided that I didn't like their choice of a smaller font size in this context; it looks better to me to leave the arrow full-size. The important thing to learn from that precedent seems to be that we have to specify the font correctly, as indeed is mentioned in the docbook documentation. So it seems to work well to just use (The extra space seems to be necessary, else the arrow ends up adjacent to the type name.) So I'm pretty happy with this implementation and will push forward. regards, tom lane diff --git a/doc/src/sgml/stylesheet-common.xsl b/doc/src/sgml/stylesheet-common.xsl index e148c90..5936d9a 100644 --- a/doc/src/sgml/stylesheet-common.xsl +++ b/doc/src/sgml/stylesheet-common.xsl @@ -49,6 +49,11 @@ + + + + + diff --git a/doc/src/sgml/stylesheet-fo.xsl b/doc/src/sgml/stylesheet-fo.xsl index ea75408..a3b6463 100644 --- a/doc/src/sgml/stylesheet-fo.xsl +++ b/doc/src/sgml/stylesheet-fo.xsl @@ -63,6 +63,12 @@ + + + + + +
Re: pre-requiste for installation
On 4/12/20 8:21 AM, Ankush Chawla wrote: > hi > > what is the pre-requiste packages for Postgres Installation on SUSE Linux > > I have already transferred .run file > > What would be pre-requiste package, hardware or software requirements , > any readme available? I believe these are listed on this page: https://zypp.postgresql.org/howtozypp.php which is linked to from the SuSE downloads page: https://www.postgresql.org/download/linux/suse/ In general, it's better to ask these types of questions on the pgsql-gene...@lists.postgresql.org mailing list[1] as this mailing list is geared towards the maintenance of the PostgreSQL documentation. Hope this helps, Jonathan [1] https://www.postgresql.org/support/ signature.asc Description: OpenPGP digital signature
pre-requiste for installation
hi what is the pre-requiste packages for Postgres Installation on SUSE Linux I have already transferred .run file What would be pre-requiste package, hardware or software requirements , any readme available? -- Best Regards, Ankush Chawla
Improve This Sentence?
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/wal-configuration.html Description: In the WAL configuration chapter, one finds this sentence: On Linux and POSIX platforms checkpoint_flush_after allows to force the OS that pages written by the checkpoint should be flushed to disk after a configurable number of bytes. I think I have an idea what it says, but saw some discussion to this very issue. Can it be re-written? Otherwise, an amazing, fantastic read, to this point. Job very well done!
Re: Getting our tables to render better in PDF output
On 11.04.20 22:51, Tom Lane wrote: Yet another possibility is to use the docbook tags: func() int. Then we can define the desired formatting for such markup (similar to ..). I looked into this. It appears that is fairly tightly tied to C function declaration syntax, plus it sounds like it might get deprecated in future docbook versions. funcsynopsis, funcdef, function, ... keeps valid in Docbook 5, see: https://tdg.docbook.org/tdg/5.1/funcsynopsis.html . There is even an option to distinguish between K and ANSI style during rendering: Kind regards, Jürgen Purtz
