On Jun 27, 2013, at 1:16 PM, Hadrian Zbarcea <hzbar...@gmail.com> wrote:
> 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.
Well, it takes about 12 seconds to build, and most of that time is downloading
the thing. Considering how long the Camel build is, 12 seconds is not a big
deal.
That said, the HTML still requires an internet connection to get the code
stylers and css and such. Doesn't solve any sort of "offline" problem.
Anyway, it's all committed to master. Feel free to check it out. If it's OK,
we can merge it to the other branches.
Dan
>
> 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" <dk...@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
>>> dk...@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>>>
>>
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
