Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jSlHS-00036b-RN for pgsql-hackers@arkaria.postgresql.org; Sun, 26 Apr 2020 17:41:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jSlHR-0006Vk-Nx for pgsql-hackers@arkaria.postgresql.org; Sun, 26 Apr 2020 17:41:25 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jSlHR-0006Vc-1h for pgsql-hackers@lists.postgresql.org; Sun, 26 Apr 2020 17:41:25 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jSlHG-0004Hu-Gd for pgsql-hackers@lists.postgresql.org; Sun, 26 Apr 2020 17:41:24 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id 03QHes7K005562; Sun, 26 Apr 2020 13:40:54 -0400 From: Tom Lane To: Peter Eisentraut cc: "Jonathan S. Katz" , Bruce Momjian , Alvaro Herrera , Robert Haas , Steven Pousty , Pavel Stehule , Isaac Morland , Pierre Giraud , PostgreSQL Developers Subject: Re: Poll: are people okay with function/operator table redesign? In-reply-to: <19233.1587665407@sss.pgh.pa.us> References: <20200423174343.GA16996@alvherre.pgsql> <19233.1587665407@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Thu, 23 Apr 2020 14:10:07 -0400" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <5432.1587922682.0@sss.pgh.pa.us> Date: Sun, 26 Apr 2020 13:40:54 -0400 Message-ID: <5561.1587922854@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5432.1587922682.1@sss.pgh.pa.us> I wrote: > Alvaro Herrera writes: >> If we're doing nicer markup+CSS for this, then it might make sense to >> find a better solution for this kind of entry with multiple signatures >> (which was already an issue in the previous version): > Yeah, agreed. I would like to be able to have multiple signature blocks > in one table cell, which the current hack can't handle. There aren't > quite enough cases to make this mandatory, but it would be nicer. > It seems do-able if we explicitly mark signature blocks with their > own role, say ... Hearing no comments, I went ahead and experimented with that. Attached is a POC patch that changes just the header and first few entries in table 9.9, just to see what it'd look like. This does nicely reproduce the existing visual appearance. (With the margin parameters I used, there is a teensy bit more vertical space, but I think it looks better this way. That could be adjusted either way of course.) There is a small problem with getting this to work in the webstyle HTML: somebody decided it would be a great idea to have a global override on paragraph margin-bottom settings. For the purposes of this test I just deleted that from main.css, but I suppose we want some more-nuanced solution in reality. One thing I couldn't help noticing while fooling with this is what seems to be a bug in the PDF toolchain: any place you try to put an , you get extra whitespace. Not a lot, but once you see it, you can't un-see it. It's particularly obvious if one of two adjacent lines has the extra indentation and the other doesn't. In the attached, I added an to one of the signature entries for "text || anynonarray", and you can see what I'm unhappy about in the PDF screenshot. The problem already exists in our previous markup, at least in places where people put indexterms inside function-table entries, but it'll be more obvious anyplace we choose to have two signature entries in one table cell. I tried putting the s outside the elements, but that makes it worse not better: instead of a little bit of extra horizontal whitespace, you get a lot of extra vertical whitespace. The only "fix" I've found is to place the at the end of the signature instead of the beginning. That's not included in the attached but it does hide the existence of the extra space quite effectively. I'm not sure though whether it might result in odd behavior of cross-reference links to the function entry. In any case it feels like a hack. It seems to me that this way is better than the markup I've been using --- one thing I've observed is that Emacs' sgml mode is a bit confused by the hacks, and it's happier with this. But it's not clear to me whether this is sufficient to resolve Peter's unhappiness. regards, tom lane ------- =_aaaaaaaaaa0 Content-Type: text/x-diff; name="markup-revision-test.patch"; charset="us-ascii" Content-ID: <5432.1587922682.2@sss.pgh.pa.us> Content-Description: markup-revision-test.patch Content-Transfer-Encoding: quoted-printable diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index b0afaeb..ffcb0ae 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -2067,48 +2067,64 @@ repeat('Pg', 4) PgPgPgPg - - Function/OperatorDescriptionExample(s) - + + Function/Operator + + + Description + + + Example(s) + = - + character string concatenation text || text text - + + Concatenates the two strings. - + + 'Post' || 'greSQL' PostgreSQL - + = - + + + character string test + text || anynonarray - or anynonarray || text text - + + + anynonarray || text + text + + Converts the non-string input to text, then concatenates the two strings. (The non-string input cannot be of an array type, becau= se that would create ambiguity with the array || operators. If you want to concatenate an array's text equivalent= , cast it to text explicitly.) - + + 'Value: ' || 42 Value: 42 - + = - + normalized @@ -2117,7 +2133,8 @@ repeat('Pg', 4) PgPgPgPg text IS NOT form NORMALIZED boolean - + + Checks whether the string is in the specified Unicode normalizati= on form. The optional form key word specifie= s the form: NFC (the default), NFD, @@ -2125,10 +2142,11 @@ repeat('Pg', 4) PgPgPgPg only be used when the server encoding is UTF8.= Note that checking for normalization using this expression is often fa= ster than normalizing possibly already normalized strings. - + + U&'\0061\0308bc' IS NFD NORMALIZED t - + = diff --git a/doc/src/sgml/stylesheet-fo.xsl b/doc/src/sgml/stylesheet-fo.x= sl index 6797e06..e923b00 100644 --- a/doc/src/sgml/stylesheet-fo.xsl +++ b/doc/src/sgml/stylesheet-fo.xsl @@ -89,6 +89,16 @@ = + + + + + -3.5em + + + + +