Re: fixing bookindex.html bloat

From: Andres Freund <andres(at)anarazel(dot)de>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: fixing bookindex.html bloat
Date: 2022-02-14 17:51:04
Message-ID: 20220214175104.cni4penhxeph4qqd@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2022-02-14 18:31:25 +0100, Peter Eisentraut wrote:
> > The reason that we end up with so many more xmlns:xlink is just that without
> > our customization there ends up being a single
> > <div xmlns:xlink="http://www.w3.org/1999/xlink" class="index">
> > and then everything below that doesn't need the xmlns:xlink anymore. But
> > because stylesheet-html-common.xsl emits the div, the xmlns:xlink is emitted
> > for each element that autoidx.xsl has "control" over.
> >
> > Waiting for docbook to fix this seems a bit futile, I eventually found a
> > bugreport about this, from 2016: https://sourceforge.net/p/docbook/bugs/1384/
> >
> > But we can easily reduce the "impact" of the issue, by just adding a single
> > xmlns:xlink to <div class="index">, which is sufficient to convince xsltproc
> > to not repeat it.
>
> I haven't fully wrapped my head around this. I tried adding xlink to our
> own exclude-result-prefixes, but that didn't seem to have the right effect.

It can't, because it's not one of our stylesheets that causes the xlink: stuff
to be included. It's autoidx.xls - just adding xlink to autoidx's
exclude-result-prefixes fixes the problem "properly", but we can't really
modify it.

The reason adding xmlns:xlink to our div (or even higher up) helps is that
then nodes below it don't need to include it again (when output by autoidx),
which drastically reduces the number of xmlns:xlink. So it's just a somewhat
ugly workaround, but for >100kB it seems better than the alternative.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-02-14 17:54:47 Re: Mark all GUC variable as PGDLLIMPORT
Previous Message Robert Haas 2022-02-14 17:47:44 Re: bailing out in tap tests nearly always a bad idea