Jeff King venit, vidit, dixit 08.10.2012 00:52:
> On Sun, Oct 07, 2012 at 10:14:28AM +0200, Thomas Ackermann wrote:
>> There are "patched QT" and "unpatched QT" versions of wkhtmltopdf
>> (see I am using V0.9.9 for Windows
>> which is "patched QT".
> That's a definite compatibility question for taking your patches into
> upstream git.
>> There is one drawback with wkhtmltopdf: At least on my Netbook (Win7 64bit,
>> Pentium 1.5GHz) it is very slow. It takes more than 3 hrs to create 
>> git-doc.pdf.
>> If you want to have a quick look on the resulting pdf just clone 
>> This repo contains
>> a current version of user.manual.pdf and git-doc.pdf 
> It does look better than the output generated by the "man -Tdvi" loop I
> posted. It retains more styling from the HTML and it has a nice table of
> contents. But 3 hours? Yeesh. Mine took 11 seconds.
> I wonder if a more sane route is to drop HTML entirely, convert the
> asciidoc to docbook (which we already do for manpages), and then create
> a docbook document that is a collection of all elements, which can then

Hmm, I think the html output often looks better than the man output
(tables and such), and it is a formatted, reflowable, interlinked format
fit for many puposes.

> be converted to pdf, epub, or whatever. I would not be surprised if
> somebody has solved this problem before (but it is not really my itch,
> so I did not look very far).

I'd rather ditch docbook and have one toolchain (asciidoc, unless we
want to switch to something else) only... We've been hunting asciidoc as
well as docbook compatibility (between versions) and interoperability
(between them) issues again and again.

In fact, if I remember correctly, that's what has been keeping us from
using *real* tables in the doc (but hasn't kept us from using tables ;) ).

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to