Corey Huinker writes:
> On Mon, Apr 13, 2020 at 12:28 PM Tom Lane wrote:
>> I'm not really buying into that as a requirement. For one thing, the
>> anchor name will be 100% predictable.
> The anchor name is deterministic (or I intend it to be) but
> the existence of the link is not predictable.
On Mon, Apr 13, 2020 at 12:28 PM Tom Lane wrote:
> Corey Huinker writes:
> > I was thinking that there were references that included parameters, but
> I'm
> > not finding any with actual parameter values, so at most we'd lose the
> "()"
> > of a reference.
>
> We could possibly stick the parens
Corey Huinker writes:
> I was thinking that there were references that included parameters, but I'm
> not finding any with actual parameter values, so at most we'd lose the "()"
> of a reference.
We could possibly stick the parens into the indexterm text. Arguably
that's an improvement on its ow
>
>
> 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).
I did, actually, get excited for a second.
> The runtime difference for building the HTML docs
> seems to be under 1%, and negligible f
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.
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
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
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 w
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
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
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
On Sat, Apr 11, 2020 at 6:41 PM Tom Lane wrote:
> Corey Huinker writes:
> > If it's ok to work on doc patches during the feature freeze, and if we're
> > already tweaking function documentation, would it be possible to add in
> > anchor ids to function definitions so that we could reference spec
Corey Huinker writes:
> If it's ok to work on doc patches during the feature freeze, and if we're
> already tweaking function documentation, would it be possible to add in
> anchor ids to function definitions so that we could reference specific
> functions (or rather the family of functions that s
On Sat, Apr 11, 2020 at 4:51 PM Tom Lane wrote:
> I set this idea aside during the final v13 commitfest, but I figure that
> it's fine to work on documentation improvements during feature freeze,
> so I'm going to try to push it forward over the next few weeks.
If it's ok to work on doc patches
I set this idea aside during the final v13 commitfest, but I figure that
it's fine to work on documentation improvements during feature freeze,
so I'm going to try to push it forward over the next few weeks.
Barring objections, I want to commit more or less what I posted at [1],
verify that it loo
17.02.2020 00:21, Alexander Lakhin wrote:
> Hello Tom,
>> 16.02.2020 23:07, Tom Lane wrote:
>>
>>
>> I poked at this a little bit, and found that I could get a pretty
>> decent-looking result if I hacked the .fo file to contain
>> "→" rather than a bare
>> right arrow. (See attached screenshot, wh
Hello Tom,
> 16.02.2020 23:07, Tom Lane wrote:
>
>
> I poked at this a little bit, and found that I could get a pretty
> decent-looking result if I hacked the .fo file to contain
> "→" rather than a bare
> right arrow. (See attached screenshot, wherein the last rightarrow
> was fixed this way but
I wrote:
> One problem with the rightarrow idea is that it's not rendering quite
> right for me: it looks great in HTML, but in PDF it comes out flush
> with the baseline, as you can see in the screenshot. Hopefully
> there's a way to fix that that we can hide in the custom entity ...
> but I have
Alvaro Herrera writes:
> On 2020-Feb-13, Alexander Lakhin wrote:
>> Third (minor) issue is with translation - when I will see some break in
>> the English source, e.g. "split_part('abc~@~def&zwsp;~@~ghi', '~@~',
>> 2)", should I leave the break in the same place, or it's better to move
>> it becau
Hello Alvaro,
14.02.2020 23:16, Alvaro Herrera wrote:
> On 2020-Feb-13, Alexander Lakhin wrote:
>
>> Yes, I was starting with manual &zwsp; insertions into the translation,
>> but later I reduced such insertions just to several dozens. (For
>> example, we still have "3.1415926535&zwsp;8979323846" i
On 2020-Feb-13, Alexander Lakhin wrote:
> Yes, I was starting with manual &zwsp; insertions into the translation,
> but later I reduced such insertions just to several dozens. (For
> example, we still have "3.1415926535&zwsp;8979323846" in the translation.)
> The main issue of the manual approach
12.02.2020 23:58, Tom Lane wrote:
> Alexander Lakhin writes:
>> Please look at a less invasive approach that we use at Postgres Pro for
>> some time (mainly for improving the translated documentation, but it
>> works for the original one too). The idea is to add zero-width spaces
>> after/before s
On 2020-Feb-12, Tom Lane wrote:
> With a separate argument-types cell it'd likely be
> better to just leave the cell empty, but do we want to write
> just "→ rettype" in a signature cell?
Yeah, it'd look very odd, and certainly the no-parens case makes it
worse. I like this end result:
> so bei
Alvaro Herrera writes:
> On 2020-Feb-12, Tom Lane wrote:
>> I also attached a screenshot of a segment of Table 9-31, to show
>> what that layout proposal looks like. It's a little busier, but
>> it does have the advantage that it's clearer how to apply that
>> format to operator tables. The "ret
On 2020-Feb-12, Tom Lane wrote:
> For amusement's sake, attached is a screenshot of what Table 9-33
> looks like in A4 format, with my one-row-per-example patch of
> yesterday plus a few manually-added zero-width spaces to break up
> the examples. This is the first PDF rendering of that table tha
Hello Tom,
12.02.2020 00:51, Tom Lane wrote:
> The crummy formatting of our tables of functions and operators has
> been an issue for a long time. To my mind, there are several things
> that need to be addressed:
>
> * The layout is completely unfriendly to function descriptions that
> run to more
The crummy formatting of our tables of functions and operators has
been an issue for a long time. To my mind, there are several things
that need to be addressed:
* The layout is completely unfriendly to function descriptions that
run to more than a few words.
* It's not very practical to have mo
27 matches
Mail list logo
