camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Dywicki <>
Subject Re: Camel manual in pdf....
Date Thu, 27 Jun 2013 18:11:50 GMT
Hey guys,
Can't you use scalate for manual generation? We use it in Karaf and it does a job. :) It's
little forgotten by owners but still usable!

Listings are made by princexml or something like this.


Wiadomość napisana przez Hadrian Zbarcea <> w dniu 27 cze 2013,
o godz. 19:16:

> Give the fact that it uses precious compile time, I would drop the html manual too. It's
not as well formated as the PDF one and equally useless.
> Just my $0.02,
> Hadrian
> On 06/27/2013 12:30 PM, Christian Müller wrote:
>> +1 for #5 but would like to keep html manual.
>> Best,
>> Christian
>> Sent from a mobile device
>> Am 26.06.2013 17:38 schrieb "Daniel Kulp" <>:
>>> With the latest confluence (and also once they actually update to 5.1.x),
>>> the Camel manual is no longer producible.   The main problem is the
>>> javascript that is used to format all the {code} and {snippet} macros.
>>> The old version of confluence rendered them into static HTML which prince
>>> handled fine.   The new versions require some javascript to render it.
>>> I tried updating the html for the manual to add the javascript into it and
>>> pass the --javascript flag to prince.   With the 8.1r3 version of prince I
>>> had, it would segfault.   Updating to 8.1r5 (latest from prince) goes into
>>> an infinite loop.    Thus, there are a few options:
>>> 1) When converting from book-in-one-page.html to the manual.html, we can
>>> try and adjust the <script>  tags that confluence now generates to convert
>>> them to something prince can render.   There may be a different javascript
>>> based highlighter that prince can handle.   Not really sure, would require
>>> a bit of investigation and experimentation.
>>> 2) Similar to (1), I could try updating the CXF site-exporter to use a
>>> different syntax highlighter.  I currently just use the same one as
>>> confluence to make sure it works.
>>> 3) Experiment with different HTML -> PDF renderers.  There are several out
>>> there, not sure if any of them can handle the javascript any better.
>>> 4) Report issues to prince and hope for a new version of prince that can
>>> handle it.
>>> 5) Drop the PDF manual entirely.  We can keep the html manual if we really
>>> want it.
>>> I did try the Confluence "Export to PDF" option and that didn't render the
>>> code blocks either.   So no help there.
>>> 1-3 would require a bit of work and I really don't want to go down those
>>> routes if #5 is the "best" option for us.    I don't recommend #4.    I'm
>>> personally in favor of #5 as I really don't see much "value" in the PDF
>>> manual at this point.
>>> Thoughts?
>>> --
>>> Daniel Kulp
>>> -
>>> Talend Community Coder -

View raw message