Re: Uh-oh: documentation PDF output no longer builds in HEAD - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Uh-oh: documentation PDF output no longer builds in HEAD
Date
Msg-id 22369.1447188944@sss.pgh.pa.us
Whole thread Raw
In response to Re: Uh-oh: documentation PDF output no longer builds in HEAD  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
> On Tue, Nov 10, 2015 at 6:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I don't know anything about jpdftweak, but if it's being used to get rid
>> of unreferenced hyperlink anchors, maybe we could dispense with that step
>> after this goes in.

> Yeah, that's what I was hoping.  You can see how it's used in the
> mk-release-pdfs script on borka.

Hmm ... building current HEAD in A4 format, I get
            HEAD        with my patch

initially generated PDF:    26.30MB        13.25MB
after jpdftweak:        7.24MB        7.24MB

Evidently, jpdftweak *is* removing unreferenced bookmarks --- the output
file sizes would not be so close to identical otherwise.  But it's
evidently doing more than that.  The initially generated PDFs are
fairly compressible by "gzip", while jpdftweak's outputs are not, so
I suppose that the additional savings come from applying compression.
jdftweak's help output indicates that the "-ocs" options are selecting
aggressive compression.

I tried removing the load/save bookmarks steps from mk-release-pdfs,
but what I get is files that are a little smaller yet and again almost the
same size for either starting point; that probably means that jpdftweak's
default behavior is to strip all bookmarks :-(.

Maybe we could look around for another tool that just does PDF compression
and not the other stuff ...
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: storage/buffer/README docs about buffer replacement are out of date
Next
From: Peter Geoghegan
Date:
Subject: Re: INSERT ... ON CONFLICT documentation clean-up patch