Thread: Blanks in the first line before the first word in the code boxes
Hi,
is it only me who sees blanks before the first word in the first line of the code boxes, e.g. here:
For the devel documentation it is fine:
Tested in Firefox and Chrome.
Regards
Daniel
On 3/23/18 08:56, Daniel Westermann wrote: > is it only me who sees blanks before the first word in the first line of > the code boxes, e.g. here: > > https://www.postgresql.org/docs/9.6/static/sql-createtable.html > https://www.postgresql.org/docs/10/static/sql-createtable.html > > For the devel documentation it is fine: > https://www.postgresql.org/docs/devel/static/sql-createtable.html > > Tested in Firefox and Chrome. Yeah, that looks weird. I'll look into it. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 3/28/18 21:30, Peter Eisentraut wrote: > On 3/23/18 08:56, Daniel Westermann wrote: >> is it only me who sees blanks before the first word in the first line of >> the code boxes, e.g. here: >> >> https://www.postgresql.org/docs/9.6/static/sql-createtable.html >> https://www.postgresql.org/docs/10/static/sql-createtable.html >> >> For the devel documentation it is fine: >> https://www.postgresql.org/docs/devel/static/sql-createtable.html >> >> Tested in Firefox and Chrome. > > Yeah, that looks weird. I'll look into it. Just looking at a nearby thread ... something is quite whacky with the web site stylesheet. It didn't use to look like this. Check this out: https://www.postgresql.org/docs/10/static/pgcrypto.html#id-1.11.7.35.5 -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Mar 28, 2018, at 9:32 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:On 3/28/18 21:30, Peter Eisentraut wrote:On 3/23/18 08:56, Daniel Westermann wrote:is it only me who sees blanks before the first word in the first line of
the code boxes, e.g. here:
https://www.postgresql.org/docs/9.6/static/sql-createtable.html
https://www.postgresql.org/docs/10/static/sql-createtable.html
For the devel documentation it is fine:
https://www.postgresql.org/docs/devel/static/sql-createtable.html
Tested in Firefox and Chrome.
Yeah, that looks weird. I'll look into it.
Just looking at a nearby thread ... something is quite whacky with the
web site stylesheet. It didn't use to look like this. Check this out:
https://www.postgresql.org/docs/10/static/pgcrypto.html#id-1.11.7.35.5
Something is adding spaces - it’s within the “<pre>” tag, which causes browsers
to interpret each space literally.
For the case of the “digest” function, the outputted HTML shows the first digest
function indented, the second one at the start of the new line.
Jonathan
On 3/28/18 21:36, Jonathan S. Katz wrote: > >> On Mar 28, 2018, at 9:32 PM, Peter Eisentraut >> <peter.eisentraut@2ndquadrant.com >> <mailto:peter.eisentraut@2ndquadrant.com>> wrote: >>> Yeah, that looks weird. I'll look into it. >> >> Just looking at a nearby thread ... something is quite whacky with the >> web site stylesheet. It didn't use to look like this. Check this out: >> https://www.postgresql.org/docs/10/static/pgcrypto.html#id-1.11.7.35.5 > > Something is adding spaces - it’s within the “<pre>” tag, which causes > browsers > to interpret each space literally. > > For the case of the “digest” function, the outputted HTML shows the > first digest > function indented, the second one at the start of the new line. Yeah, the spaces are in the source, so it's not a CSS issue. But it doesn't come out like that if you build the docs locally. So it's something in the web site code. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> On Mar 28, 2018, at 9:47 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > > On 3/28/18 21:36, Jonathan S. Katz wrote: >> >>> On Mar 28, 2018, at 9:32 PM, Peter Eisentraut >>> <peter.eisentraut@2ndquadrant.com >>> <mailto:peter.eisentraut@2ndquadrant.com>> wrote: >>>> Yeah, that looks weird. I'll look into it. >>> >>> Just looking at a nearby thread ... something is quite whacky with the >>> web site stylesheet. It didn't use to look like this. Check this out: >>> https://www.postgresql.org/docs/10/static/pgcrypto.html#id-1.11.7.35.5 >> >> Something is adding spaces - it’s within the “<pre>” tag, which causes >> browsers >> to interpret each space literally. >> >> For the case of the “digest” function, the outputted HTML shows the >> first digest >> function indented, the second one at the start of the new line. > > Yeah, the spaces are in the source, so it's not a CSS issue. But it > doesn't come out like that if you build the docs locally. So it's > something in the web site code. If I traced the code correctly, the line I suspect is such: s = tidy.parseString(contents.encode('utf-8'), **tidyopts) I know that the web infrastructure recently updated to the Django 1.11 series, I’m not sure if libtidy or the like were also updated with that. I’ll defer to Magnus on that. Jonathan
On Thu, Mar 29, 2018 at 4:02 AM, Jonathan S. Katz <jkatz@postgresql.org> wrote:
> On Mar 28, 2018, at 9:47 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
>
> On 3/28/18 21:36, Jonathan S. Katz wrote:
>>
>>> On Mar 28, 2018, at 9:32 PM, Peter Eisentraut
>>> <peter.eisentraut@2ndquadrant.com
>>> <mailto:peter.eisentraut@2ndquadrant.com>> wrote:
>>>> Yeah, that looks weird. I'll look into it.
>>>
>>> Just looking at a nearby thread ... something is quite whacky with the
>>> web site stylesheet. It didn't use to look like this. Check this out:
>>> https://www.postgresql.org/docs/10/static/pgcrypto.html# id-1.11.7.35.5
>>
>> Something is adding spaces - it’s within the “<pre>” tag, which causes
>> browsers
>> to interpret each space literally.
>>
>> For the case of the “digest” function, the outputted HTML shows the
>> first digest
>> function indented, the second one at the start of the new line.
>
> Yeah, the spaces are in the source, so it's not a CSS issue. But it
> doesn't come out like that if you build the docs locally. So it's
> something in the web site code.
If I traced the code correctly, the line I suspect is such:
s = tidy.parseString(contents.encode('utf-8'), **tidyopts)
I know that the web infrastructure recently updated to the Django 1.11
series, I’m not sure if libtidy or the like were also updated with that. I’ll
defer to Magnus on that.
This would not change with the change to Django 1.11 -- the actual script that loads the docs runs outside of Django.
Now, the entire machine was upgraded to a new Debian meaning new python, new tidy etc some time ago. But this was done the first week of February.
Is it possible that this issue actually showed up around 4-5 February, but just has gone unnoticed since?
Magnus Hagander <magnus@hagander.net> writes:
> Is it possible that this issue actually showed up around 4-5 February, but
> just has gone unnoticed since?
It's been there a few weeks, anyway --- I remember somebody complaining
before this particular thread started. I wouldn't be a bit surprised
if it broke then.
regards, tom lane
Magnus Hagander <magnus@hagander.net> writes:
> Is it possible that this issue actually showed up around 4-5 February, but
> just has gone unnoticed since?
It's been there a few weeks, anyway --- I remember somebody complaining
before this particular thread started. I wouldn't be a bit surprised
if it broke then.
First report that both Tom and I responded to, Tom by cc'ing www, was on the Feb 26th,
David J.
On Thu, Mar 29, 2018 at 3:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
> Is it possible that this issue actually showed up around 4-5 February, but
> just has gone unnoticed since?
It's been there a few weeks, anyway --- I remember somebody complaining
before this particular thread started. I wouldn't be a bit surprised
if it broke then.
Yeah, it's quite likely that it got broken by the OS upgrade and nobody picked up on it before then. This can probably be because the backbranch documentation is only updated when we make actual releases.
However, why does devel work fine when the others are broken. It's the exact same code that's run to load the docs. The *input* to the loader must also be different at some point.
Magnus Hagander <magnus@hagander.net> writes:
> However, why does devel work fine when the others are broken. It's the
> exact same code that's run to load the docs. The *input* to the loader must
> also be different at some point.
HEAD is the only branch building the docs via XML, so it's hardly
unlikely that the input is different.
regards, tom lane
On 4/1/18 11:55, Magnus Hagander wrote: > However, why does devel work fine when the others are broken. It's the > exact same code that's run to load the docs. The *input* to the loader > must also be different at some point. In devel, the raw HTML output looks like ... <pre class="synopsis"> ALTER FOREIGN TABLE [ IF EXISTS ] [ ONLY ] ... (with a line break) but before it looks like ... <pre class="synopsis">ALTER FOREIGN TABLE [ IF EXISTS ] [ ONLY ] ... (without a line break). So maybe some part of the processing code thinks it should do some kind of "indentation" here. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Mon, Apr 2, 2018 at 5:59 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
On 4/1/18 11:55, Magnus Hagander wrote:
> However, why does devel work fine when the others are broken. It's the
> exact same code that's run to load the docs. The *input* to the loader
> must also be different at some point.
In devel, the raw HTML output looks like
... <pre class="synopsis">
ALTER FOREIGN TABLE [ IF EXISTS ] [ ONLY ] ...
(with a line break)
but before it looks like
... <pre class="synopsis">ALTER FOREIGN TABLE [ IF EXISTS ] [ ONLY ] ...
(without a line break).
So maybe some part of the processing code thinks it should do some kind
of "indentation" here.
I think I found the problem, and pushed a fix for it. Basically it turns off indentation completely on pre-11 versions., I elected to keep indention on dev because it works there, and it makes debugging any of the formatting a lot easier.
I've pushed the fix and reloaded the 10 docs. I have not reloaded earlier branches yet, but I'd be interested in some people reviewing a bunch of pages in the 10 docs mainly to see if (1) it fixes all the cases, and (2) it actually breaks some *other* cases.
On 4/3/18 09:12, Magnus Hagander wrote: > I've pushed the fix and reloaded the 10 docs. I have not reloaded > earlier branches yet, but I'd be interested in some people reviewing a > bunch of pages in the 10 docs mainly to see if (1) it fixes all the > cases, and (2) it actually breaks some *other* cases. It looks correct now. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Apr 3, 2018, at 10:55 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:On 4/3/18 09:12, Magnus Hagander wrote:I've pushed the fix and reloaded the 10 docs. I have not reloaded
earlier branches yet, but I'd be interested in some people reviewing a
bunch of pages in the 10 docs mainly to see if (1) it fixes all the
cases, and (2) it actually breaks some *other* cases.
It looks correct now.
+1
Did a spot check on known broken pages and chose some others at
random. Viewed the 9.6, 10, and devel versions. 10 and devel both
looked correct, and the 9.6 was broken where expected.
The only thing I saw (and this may be something to look at the SGML
source) was some blocks that looked overly indented, but it was consistent
across all versions. On
If you search for "WITH RECURSIVE search_graph(id, link, data, depth)”
the expression in the CTE is much more indented than similar CTEs above
it.
IMV I would not let this stop us from reloading the earlier versions as that
indentation is consistent across all versions (including 9.6, where it has the
initial indentation as well).
Jonathan
On Wed, Apr 4, 2018 at 3:21 PM, Jonathan S. Katz <jkatz@postgresql.org> wrote:
On Apr 3, 2018, at 10:55 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: On 4/3/18 09:12, Magnus Hagander wrote:I've pushed the fix and reloaded the 10 docs. I have not reloaded
earlier branches yet, but I'd be interested in some people reviewing a
bunch of pages in the 10 docs mainly to see if (1) it fixes all the
cases, and (2) it actually breaks some *other* cases.
It looks correct now.+1Did a spot check on known broken pages and chose some others atrandom. Viewed the 9.6, 10, and devel versions. 10 and devel bothlooked correct, and the 9.6 was broken where expected.The only thing I saw (and this may be something to look at the SGMLsource) was some blocks that looked overly indented, but it was consistentacross all versions. OnIf you search for "WITH RECURSIVE search_graph(id, link, data, depth)”the expression in the CTE is much more indented than similar CTEs aboveit.IMV I would not let this stop us from reloading the earlier versions as thatindentation is consistent across all versions (including 9.6, where it has theinitial indentation as well).
I've reloaded docs back to 9.3.
On 4/4/18 09:21, Jonathan S. Katz wrote: > The only thing I saw (and this may be something to look at the SGML > source) was some blocks that looked overly indented, but it was consistent > across all versions. On > > https://www.postgresql.org/docs/current/static/queries-with.html > > If you search for "WITH RECURSIVE search_graph(id, link, data, depth)” > the expression in the CTE is much more indented than similar CTEs above > it. This was that way in the source. Probably originally 8-space tabs. I've fixed it now. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> On Apr 4, 2018, at 8:59 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > > On 4/4/18 09:21, Jonathan S. Katz wrote: >> The only thing I saw (and this may be something to look at the SGML >> source) was some blocks that looked overly indented, but it was consistent >> across all versions. On >> >> https://www.postgresql.org/docs/current/static/queries-with.html >> >> If you search for "WITH RECURSIVE search_graph(id, link, data, depth)” >> the expression in the CTE is much more indented than similar CTEs above >> it. > > This was that way in the source. Probably originally 8-space tabs. That was my hunch, but wanted to be triple-sure. > I've fixed it now. Awesome. Thanks! Jonathan