camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: Camel manual in pdf....
Date Thu, 27 Jun 2013 17:16:39 GMT
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" <dkulp@apache.org>:
>
>>
>> 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
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>

Mime
View raw message