Thread: Re: [pgsql-www] [HACKERS] Small issue in online devel documentation build

On 2/16/17 15:35, Fabien COELHO wrote:
> After some random digging, it seems that the documentation files are 
> loaded from provided tarballs by a script: "tools/docs/docload.py" 
> maintained in "pgweb.git". Maybe this is run from some cron.
> 
> AFAICS from the script, the provided tarballs contains the generated html 
> that someone/something has already generated and put somewhere. I have 
> found no clear clue about who, where and when. However I would bet that 
> "Magnus Hagander" and "Dave Page" know, given that they commits suggest 
> that they are maintaining the site:-)
> 
> The load script passes the doc through "tidy" with some options, and 
> registers the pages into a database probably for django. I doubt this 
> would change the ul class.

Can someone from the web site team look into this?

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Hello Magnus,

> The toolchain used previously (9.6) generates this code:
> <UL
> > <LI
> > <P
> > <TT
>    CLASS="LITERAL"
> > simple</TT
> > : use simple query protocol.</P
> [...]
>
> (yes, including all the horrible newlines in the middle of tags and
> whatnot, but there's nothing new about that)

Yes this is the "old" html generation with jade, which has been replaced 
by some xsltproc-based html generation. Why not.

> The toolchain used for dev (10) generates this code:
>
> <p>        Protocol to use for submitting queries to the server:
>          </p><div class="itemizedlist"><ul class="itemizedlist"
> style="list-style-type: disc; "><li class="listitem"><p><code
> [...]

Yes, that the output I also have, which is somehow fine although verbose. 
In particular, there is no "c2" class involved in "ul" above...

> So the HTML generated is completely different. The old one didn't even use
> unnumbered lists.

??? AFAICS there is a <UL> in the first 9.6 extract above... the 
difference is about the added class, style & div... but the structure 
seems to be basically the same.

> I for one did not realize the new toolchain created completely different
> structure HTML. I know we applied a41a4cc74be8c34f7f8f1c4ec03b5dc01db06c17
> to handle changes from the new toolchain, but that won't cover cases where
> the whole structure is different.

I'm not sure it is that different, but there seems to be side effect at 
some stages when the doc files are integrated into the web site.

> In this particular case, the boldness comes from the c2 class as indicated
> earlier. But that class has always been bold.

Probably. The question is rather why is the ul in this class on the 
website, while it is not in the raw generated file? What adds it?

> Might it just be that somebody has to actually go over the new structure of
> the docs and provide the appropriate CSS rules? Or is something wrong with
> the actual building of them as they give a completely different structure?

I'm unsure about "completely different", see above.

> As for the reproduction - the snapshot tarballs are built by the buildfarm
> animal guaibasaurus, which is on Debian Jessie. Could the inability to
> reproduce be because of platform differences in the docs tools?

I regenerated the 10 doc on a jessie host with the new xsltproc-based 
toolchain and got the same result as what you outline above, in particular 
no mention of "c2".

So my guess is that it would be enough not to add this c2 class to ul to 
avoid boldness.

Now the actual web pages is clearly a reprocessing of the generated xml, 
so this c2 get added between the raw xhtml documentation that one can 
reproduce and the web-page xml where there are specific headers for 
navigation, as well as some heavy reindentation.

The script on pgweb.git suggest that a "tidy" thing is called on the xml 
which is probably responsible for the reindentation, but maybe there are 
other xslt or misc tools involved which are not accessible and contribute
to the final result?

-- 
Fabien.

Hello Magnus,


> It turns out the "c2" class is added by tidy. The reason is this:
> http://api.html-tidy.org/tidy/quickref_5.0.0.html#clean

> I've removed the flag for the devel docs build for now (or - for any XML
> based docs build). I've also forced another docs load, so the results can
> be checked.

Indeed, thanks, now it looks great... under firefox at least.


Another issue in the new HTML documentation, this time not related to the 
web site. Under chrome there are some strange font size effects on 
options, for instance with this HTML in "app-psql.html":
 <span class="term">   <code class="option">-f     <em class="replaceable"><code>filename</code></em>   </code>   <br>
</span>

For previous versions, the following html was generated:
  <tt class="OPTION">-f <tt class="REPLACEABLE c2">filename</tt></tt>


The filename in the newer html appears much larger under chrome, seemingly 
because of the <code> within a <code>. Maybe a bug in chrome CSS 
interpretation, because CSS on code seems to indicate "font-size: 1.3em", 
but it seems to do 1.3**2 instead for "filename"... However it does not do 
that elsewhere so it may not be that simple...


Basically it looks ok under chrome if in the initial sgml file there is:
  <term><option>-s</option> <replaceable>scale_factor</></term>

(replaceable is out of option)

But bad on:
  <term><option>--tablespace=<replaceable>tablespace</replaceable></option></term>

(replaceable is in the option), because the size change is somehow applied 
twice.

The docbook doc says that "replaceable" is a children of "option", which 
seems to suggest that this nested usage is legit... but it may be buggy as 
well.


This may be fixed/worked around in several places:
 1. html generation could be clever enough not to nest "code" tags?    or generate tt tags instead as was done before?
    I have not found where this transformation is defined, probably    somewhere within "docbook"...
 2. avoid replaceable within option in initial sgml files    => many changes, will reappear if someone forgets.
 3. some more post-processing tidying could be done    hmmm:-(
 4. chrome should be repaired if there is indeed a bug...

-- 
Fabien.

Web team, any thoughts on the CSS details?

On 3/4/17 02:00, Fabien COELHO wrote:
> 
> Hello Peter,
> 
>> I think what you are looking at is the web site stylesheet.
> 
> Yep.
> 
>> The whole thing looks fine to me using the default stylesheet.  On the 
>> web site, it looks wrong to me too.  I don't know what the rationale for 
>> using 1.3em for <code> is, but apparently it's not working correctly.
> 
> Indeed. The idea of relative size is to be able to adjust the size for the 
> whole page and have everything scale accordingly... however this mostly 
> works well with text, but not with images. It seems that the trend is now 
> to specify absolute size, and to let the browser do whole page scaling as 
> required by the user.
> 
>> We could perhaps consider which markup style is better, but the problem
>> is that it's hard to enforce either way going forward.  So we need to
>> find the root of the problem.
> 
> The root of the problem is the combination of relative size & nesting, so 
> one or the other has to be removed:
> 
>   (1) don't nest in the input (patch I sent)
>   (2) don't use relative sizes (update the web site CSS)
> 
> Otherwise there are workarounds:
> 
>   (3) CSS work around "code code { font-size: 100% !important; }"
>   (4) unnest code in the output by some postprocessing or some more
>       clever transformation.
> 


-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Fri, Mar 10, 2017 at 11:21:33AM -0500, Peter Eisentraut wrote:
> Web team, any thoughts on the CSS details?

I think I did some CSS long ago to adjust font sizes for certain font
types on our website.  Should I find that?

--  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 +

Hello Bruce,

> On Fri, Mar 10, 2017 at 11:21:33AM -0500, Peter Eisentraut wrote:
>> Web team, any thoughts on the CSS details?
>
> I think I did some CSS long ago to adjust font sizes for certain font
> types on our website.  Should I find that?

Dunno. Maybe?

The issue is the 1.3em associated to code, because when code is used 
within code, the 1.3 multiplier accumulates and things get bigger and 
bigger.

Now the font size fixing is a good thing because courrier like fonts are 
somehow too small, it just must not accumulate, hence the suggested
solutions, one of which should be applied.

-- 
Fabien.

On Sat, Mar 11, 2017 at 07:04:06AM +0100, Fabien COELHO wrote:
> 
> Hello Bruce,
> 
> >On Fri, Mar 10, 2017 at 11:21:33AM -0500, Peter Eisentraut wrote:
> >>Web team, any thoughts on the CSS details?
> >
> >I think I did some CSS long ago to adjust font sizes for certain font
> >types on our website.  Should I find that?
> 
> Dunno. Maybe?
> 
> The issue is the 1.3em associated to code, because when code is used within
> code, the 1.3 multiplier accumulates and things get bigger and bigger.
> 
> Now the font size fixing is a good thing because courrier like fonts are
> somehow too small, it just must not accumulate, hence the suggested
> solutions, one of which should be applied.

OK, it was Javascript, not CSS.  Here is what I think I did to fix the
fonts:
https://github.com/postgres/pgweb/blob/master/media/js/monospacefix.js

--  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 +

>> Now the font size fixing is a good thing because courrier like fonts are
>> somehow too small, it just must not accumulate, hence the suggested
>> solutions, one of which should be applied.
>
> OK, it was Javascript, not CSS.  Here is what I think I did to fix the
> fonts:
>
>     https://github.com/postgres/pgweb/blob/master/media/js/monospacefix.js

Indeed, this javascript does generates the faulty display based on a 
dynamic evaluation of relative font sizes. That's fun.

Maybe just generate a fixed size instead so as to avoid accumulation on 
nesting?

-- 
Fabien.

On Fri, Mar 24, 2017 at 07:01:46AM +0100, Fabien COELHO wrote:
> 
> Hello Peter,
> 
> >I think the fix belongs into the web site CSS, so there is nothing to
> >commit into PostgreSQL here.
> 
> Indeed, the changes were only for the "remove nesting" solution.
> 
> >I will close the commit fest entry, but I have added a section to the open
> >items list so we keep track of it.
(https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items#Documentation_tool_chain)
> 
> I put forward that the quick workaround a colleague of mine suggested (aka
> something like code code { font-size: 100%; important! }) could also be
> applied to the web site CSS while waiting for a more definite answer which
> might take some pretty unknown time close to never?

Sorry I am just getting back to this.  Below I am going to cover only
the problem with the font size of nested <code> tags, and I am going to
confirm what most people already figured out.

The basic problem was already posted by Fabien, with an image example. 
The cause of the fonts being too large on Chrome is an interaction of
Chrome's default font size for different blocks, the JavaScript that is
meant to fix such mismatches, and the new nested code blocks in the PG
10 docs.

First, the JavaScript:

    https://github.com/postgres/pgweb/blob/master/media/js/monospacefix.js

There is no git history for this file except for its initial checkin in
2011, but I am pretty sure I wrote it.  What it does is to create <pre>
and <p> blocks, find the font point size, and compute a ratio.  If the
ratio is not 1, <pre>, <tt>, and <code> blocks are adjusted in size to
match <p>.  The complex part is that the JavaScript conditionally
injects CSS into the web-page to accomplish this.

The reason the PG 10 docs look fine on Linux Firefox is because the font
points sizes match so no CSS is injected.  They don't match on Chrome,
so the CSS is injected.  When the CSS hits double-embedded code blocks,
<code> <code>, it makes the font too large because it double-adjusts.

The fix, as Fabien identified, is to conditionally inject additional CSS
to be _more_ specific than the first CSS and set the font-size to a
simple '1em' so the first CSS is not called twice.  I don't think
'important!' is necessary but it would be good to test this.

Attached is a patch that can be applied to pgweb which should fix all of
this.

-- 
  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 +

-- 
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

> The fix, as Fabien identified, is to conditionally inject additional CSS
> to be _more_ specific than the first CSS and set the font-size to a
> simple '1em' so the first CSS is not called twice.  I don't think
> 'important!' is necessary but it would be good to test this.

I did not wrote the fix, a JS-guru colleague of mine did, and he argued 
that it was useful to fix priorities between competing and contradicting 
CSS rules. Now maybe in this particular case it might work without it.

> Attached is a patch that can be applied to pgweb which should fix all of
> this.

Great, the devel doc looks ok now.

-- 
Fabien.

On Sat, Apr  8, 2017 at 07:33:15PM +0900, Fabien COELHO wrote:
> 
> >The fix, as Fabien identified, is to conditionally inject additional CSS
> >to be _more_ specific than the first CSS and set the font-size to a
> >simple '1em' so the first CSS is not called twice.  I don't think
> >'important!' is necessary but it would be good to test this.
> 
> I did not wrote the fix, a JS-guru colleague of mine did, and he argued that
> it was useful to fix priorities between competing and contradicting CSS
> rules. Now maybe in this particular case it might work without it.

It would be needed for his version because he wasn't matching the exact
tags of the CSS that the JavaScript generated.

> >Attached is a patch that can be applied to pgweb which should fix all of
> >this.
> 
> Great, the devel doc looks ok now.

Great.

What other problems do we have with pgweb that I can work on?

--  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 Sat, Apr 8, 2017 at 6:39 AM, Bruce Momjian <bruce@momjian.us> wrote:
> What other problems do we have with pgweb that I can work on?

Well, the 10devel documentation doesn't believe in orange.  Compare:

https://www.postgresql.org/docs/devel/static/sql-createtable.html
https://www.postgresql.org/docs/9.6/static/sql-createtable.html

I think that needs to be fixed.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Sat, Apr  8, 2017 at 12:50:19PM -0400, Robert Haas wrote:
> On Sat, Apr 8, 2017 at 6:39 AM, Bruce Momjian <bruce@momjian.us> wrote:
> > What other problems do we have with pgweb that I can work on?
> 
> Well, the 10devel documentation doesn't believe in orange.  Compare:
> 
> https://www.postgresql.org/docs/devel/static/sql-createtable.html
> https://www.postgresql.org/docs/9.6/static/sql-createtable.html
> 
> I think that needs to be fixed.

The attached CSS patch will fix that specific issue, but I am unclear if
there are more places that need color.

-- 
  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 +

-- 
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

On Sun, Apr  9, 2017 at 07:00:38PM +0200, Magnus Hagander wrote:
> 
> 
> On Sun, Apr 9, 2017 at 2:32 AM, Bruce Momjian <bruce@momjian.us> wrote:
> 
>     On Sat, Apr  8, 2017 at 12:50:19PM -0400, Robert Haas wrote:
>     > On Sat, Apr 8, 2017 at 6:39 AM, Bruce Momjian <bruce@momjian.us> wrote:
>     > > What other problems do we have with pgweb that I can work on?
>     >
>     > Well, the 10devel documentation doesn't believe in orange.  Compare:
>     >
>     > https://www.postgresql.org/docs/devel/static/sql-createtable.html
>     > https://www.postgresql.org/docs/9.6/static/sql-createtable.html
>     >
>     > I think that needs to be fixed.
> 
>     The attached CSS patch will fix that specific issue, but I am unclear if
>     there are more places that need color.
> 
> 
> 
> Does this not also affect existing versions of the docs? AFAICT it would hit
> any and all <h2> tags, and we certainly have those in earlier versions?

It would hit any class of .refentrytitle inside of an <h2> block.  I
didn't that that happened in the old docs, but I can use an href filter
to do it only for docs of versions starting with '1' or saying 'devel'.

> And it also modifies a global stylesheet for *all* pages. So what about the
> <h2> on all the non-docs pages?

Again, we can restrict to only certain href patterns.

--  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 Sun, Apr  9, 2017 at 06:59:09PM +0200, Magnus Hagander wrote:
> On Sat, Apr 8, 2017 at 3:52 AM, Bruce Momjian <bruce@momjian.us> wrote:
>     Attached is a patch that can be applied to pgweb which should fix all of
>     this.
>
> Is there any chance we can find a way to do this with actual CSS selectors and
> not use javascript? I realize there might not be, but have we explored the
> option properly on the way the site layout looks now and with reasonably modern
> browsers?

I realize that using JavaScript to insert CSS styles into an HTML
document is complex, but I know of no other way to scale a font style to
match another font style.  CSS doesn't give you that control.  You can
use CSS to prevent the display of certain font styles, but that hardly
seems like a win.  There is probably a way to do the entire thing only
in JavaScript, but again, that doesn't seem any better.

--  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, Apr 10, 2017 at 10:17:26AM +0200, Magnus Hagander wrote:
>     didn't that that happened in the old docs, but I can use an href filter
>     to do it only for docs of versions starting with '1' or saying 'devel'.
> 
> That said, doing something like this would probably be cleaner. However, I
> think doing it based on href is a bad idea -- we're bound to silently break
> that somehow.
> 
> What if we changed the <div id="docContent"> tag to be something like <div id=
> "docContent" class="post-10"> 
> 
> Please suggest a better name -- but the idea being we add a class do it,
> conditionally for the docs of v10 and newer (which would include devel). That
> way that logic stays where it belongs, and the CSS just uses the information to
> style on.

While we could trigger on some special tag, it is best to trigger on
something the build system does anyway so that if someone builds pre-10
docs with the new build system, they get the same output.  The attached
patch uses:

    div.refnamediv h2 .refentrytitle

and "div.refnamediv" is only generated in the new build system.

-- 
  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 +

-- 
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

On 4/8/17 12:50, Robert Haas wrote:
> On Sat, Apr 8, 2017 at 6:39 AM, Bruce Momjian <bruce@momjian.us> wrote:
>> What other problems do we have with pgweb that I can work on?
> 
> Well, the 10devel documentation doesn't believe in orange.  Compare:
> 
> https://www.postgresql.org/docs/devel/static/sql-createtable.html
> https://www.postgresql.org/docs/9.6/static/sql-createtable.html
> 
> I think that needs to be fixed.

Patch for that attached.

Also patch for improved note/warning/etc. formatting.

Another issue I saw is that tables no longer get the fancy style, e.g.,
https://www.postgresql.org/docs/devel/static/sql-syntax-lexical.html.
The style selector is table.table, which is what the build produces, but
somehow the class attribute no longer shows up on the web site.

Along with the nested <code> issue, which is already being discussed,
these are all the issues I'm aware of.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-- 
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

On 4/11/17 08:49, Magnus Hagander wrote:
> At the risk of being proven wrong again, won't this affect <h2> tags in
> the old documentation as well? And if so, is that something we actually
> want?

Right.  New patch with more refined selectors attached.

> It does? The output on my laptop for that produces <table
> summary="Backslash Escape Sequences" border="1"> (for example). It's
> wrapped in a div with class=table. But the old code had <table
> border="1" class="CALSTABLE">. And AFAICT, it's the CALSTABLE that the
> css is actually matching on?
> 
> Could this be a toolchain version thing? I'm using jessie on my laptop,
> which is the same one that the website is built with.

Seems so.  Patch for that attached as well.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-- 
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

On Wed, Apr 12, 2017 at 01:31:51PM +0200, Magnus Hagander wrote:
> I think that only leaves the change to the javascript code that Bruce sent.
> Let's see if we can figure out a way to do that one without requiring
> javascript, but after that we have covered all listed issues I think?

Well, we have been using JavaScript for years, so my patch only fixes
the JavaScript we already have.  Seems applying the fix now makes sense
and then we can ponder other methods.

--  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 4/12/17 07:31, Magnus Hagander wrote:
> Once difference I notice is that for example the "note boxes" are no
> longer centered, but they do now get the new formatting.

I have committed something for that.  The issue was that the generated
HTML contained hard-coded style attributes.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 4/12/17 15:43, Peter Eisentraut wrote:
> On 4/12/17 07:31, Magnus Hagander wrote:
>> Once difference I notice is that for example the "note boxes" are no
>> longer centered, but they do now get the new formatting.
> 
> I have committed something for that.  The issue was that the generated
> HTML contained hard-coded style attributes.

This appears to have been successful.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 4/12/17 09:50, Bruce Momjian wrote:
> On Wed, Apr 12, 2017 at 01:31:51PM +0200, Magnus Hagander wrote:
>> I think that only leaves the change to the javascript code that Bruce sent.
>> Let's see if we can figure out a way to do that one without requiring
>> javascript, but after that we have covered all listed issues I think?
> 
> Well, we have been using JavaScript for years, so my patch only fixes
> the JavaScript we already have.  Seems applying the fix now makes sense
> and then we can ponder other methods.

I have googled a bit.  These two articles describe what I think is the
issue we are trying to address:

http://code.stephenmorley.org/html-and-css/fixing-browsers-broken-monospace-font-handling/

http://meyerweb.com/eric/thoughts/2010/02/12/fixed-monospace-sizing/

The recipe in the first one seems to work somewhat, but not quite as
well as the current javascript.  (The recipe in the second article is
ultimately equivalent but more verbose.)

I tend to agree with Bruce that we could just fix this within the
current framework.  But if we want to make a change, there is the
information.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 4/7/17 21:52, Bruce Momjian wrote:
> The fix, as Fabien identified, is to conditionally inject additional CSS
> to be _more_ specific than the first CSS and set the font-size to a
> simple '1em' so the first CSS is not called twice.  I don't think
> 'important!' is necessary but it would be good to test this.
> 
> Attached is a patch that can be applied to pgweb which should fix all of
> this.

IMO, this patch is correct and the best way to fix this.  Please proceed.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 4/14/17 14:45, Magnus Hagander wrote:
>     Attached is a patch that can be applied to pgweb which should fix all of
>     this.
> 
> 
> 
> Applied, thanks. 

Oops, one </style> too many.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Fri, Apr 14, 2017 at 09:38:32PM +0200, Magnus Hagander wrote:
> On Fri, Apr 14, 2017 at 9:36 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
> > On 4/14/17 14:45, Magnus Hagander wrote:
> > >     Attached is a patch that can be applied to pgweb which should fix all of
> > >     this.

> Indeed. Fix pushed.

I see <replaceable> formats as italic, instead of the bold-italic seen in the
9.6 docs.  (This is visible in the CREATE TABLE page, linked upthread.)  Is it
worth restoring the former formatting thereof?

Noah Misch wrote:
> On Fri, Apr 14, 2017 at 09:38:32PM +0200, Magnus Hagander wrote:
> > On Fri, Apr 14, 2017 at 9:36 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
> > > On 4/14/17 14:45, Magnus Hagander wrote:
> > > >     Attached is a patch that can be applied to pgweb which should fix all of
> > > >     this.
> 
> > Indeed. Fix pushed.
> 
> I see <replaceable> formats as italic, instead of the bold-italic seen in the
> 9.6 docs.  (This is visible in the CREATE TABLE page, linked upthread.)  Is it
> worth restoring the former formatting thereof?

I think the bold in the original looks terrible.  Regular italic looks
much nicer to me, so I'd keep it as is.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services