You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Daniel Kulp <dk...@apache.org> on 2013/06/26 17:37:24 UTC
Camel manual in pdf....
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
Re: Camel manual in pdf....
Posted by Jon Anstey <ja...@gmail.com>.
+1 #5 but would like to keep html manual.
On Thu, Jun 27, 2013 at 11:37 AM, Claus Ibsen <cl...@gmail.com> wrote:
> I vote for #5
>
> It will just keep haunting us in the future. With new problems etc.
>
> Its 2013 and people read online docs / google / stackoverflow / watch
> videos / etc.
> The camel pdf manual is not a good manual but just a big dump of the
> web site, thats not readable, and I dont see any people use it.
>
> And in the last 2.11.0 release we had the manual 2 times, eg with
> 2.11.0 and 2.11-SNAPSHOT as version. But nobody noticed during the
> testing phase etc. Also a little hint that the manual is not really
> used from our releases.
>
>
>
> On Wed, Jun 26, 2013 at 5:37 PM, Daniel Kulp <dk...@apache.org> wrote:
> >
> > 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
> >
>
>
>
> --
> Claus Ibsen
> -----------------
> www.camelone.org: The open source integration conference.
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Email: cibsen@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
--
Cheers,
Jon
---------------
Red Hat, Inc.
Email: janstey@redhat.com
Web: http://redhat.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen
Re: Camel manual in pdf....
Posted by Hadrian Zbarcea <hz...@gmail.com>.
#5 +1 agree
Hadrian
On 06/27/2013 10:07 AM, Claus Ibsen wrote:
> I vote for #5
>
> It will just keep haunting us in the future. With new problems etc.
>
> Its 2013 and people read online docs / google / stackoverflow / watch
> videos / etc.
> The camel pdf manual is not a good manual but just a big dump of the
> web site, thats not readable, and I dont see any people use it.
>
> And in the last 2.11.0 release we had the manual 2 times, eg with
> 2.11.0 and 2.11-SNAPSHOT as version. But nobody noticed during the
> testing phase etc. Also a little hint that the manual is not really
> used from our releases.
>
>
>
> On Wed, Jun 26, 2013 at 5:37 PM, Daniel Kulp <dk...@apache.org> wrote:
>>
>> 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
>>
>
>
>
Re: Camel manual in pdf....
Posted by Claus Ibsen <cl...@gmail.com>.
I vote for #5
It will just keep haunting us in the future. With new problems etc.
Its 2013 and people read online docs / google / stackoverflow / watch
videos / etc.
The camel pdf manual is not a good manual but just a big dump of the
web site, thats not readable, and I dont see any people use it.
And in the last 2.11.0 release we had the manual 2 times, eg with
2.11.0 and 2.11-SNAPSHOT as version. But nobody noticed during the
testing phase etc. Also a little hint that the manual is not really
used from our releases.
On Wed, Jun 26, 2013 at 5:37 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> 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
>
--
Claus Ibsen
-----------------
www.camelone.org: The open source integration conference.
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: Camel manual in pdf....
Posted by Daniel Kulp <dk...@apache.org>.
On Jun 26, 2013, at 12:28 PM, Maruan Sahyoun <sa...@fileaffairs.de> wrote:
> you can give wkhtmltopdf a try. Uses Webkit and is fine with JavaScript.
I did try it. (the 0.9.9 since that's what they have downloadable for the Mac) It generates a 15MB manual (the prince generated one is 3.7MB) and is poorly formatted. The code blocks ARE highlighted, but it doesn't remove the CDATA wrappers so you get something like:
<![CDATA[
// we need to normalize two types of incoming messages
from("direct:start") .choice()
.when().xpath("/employee").to("bean:normalizer?method=employeeToPerson")
.when().xpath("/customer").to("bean:normalizer?method=customerToPerson") .end()
.to("mock:result");
]]>
If you want to look at what it produced:
http://dankulp.com/camel-manual.pdf
Some of the formatting issues might be fixable by adjusting some of the very wide tables and code blocks. Not really sure.
Dan
>
> BR
>
> Maruan Sahyoun
>
> Am 26.06.2013 um 17:37 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
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Camel manual in pdf....
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
you can give wkhtmltopdf a try. Uses Webkit and is fine with JavaScript.
BR
Maruan Sahyoun
Am 26.06.2013 um 17:37 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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
Re: Camel manual in pdf....
Posted by Willem jiang <wi...@gmail.com>.
+1 for the 5.
I don't think there are lots of people are using the pdf to lookup the document of camel.
--
Willem Jiang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Wednesday, June 26, 2013 at 11:37 PM, Daniel Kulp wrote:
>
> 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
Re: Camel manual in pdf....
Posted by Daniel Kulp <dk...@apache.org>.
On Jun 27, 2013, at 1:16 PM, Hadrian Zbarcea <hz...@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
>>> dkulp@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>>>
>>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Camel manual in pdf....
Posted by Łukasz Dywicki <lu...@code-house.org>.
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.
Cheers,
Lukasz
Wiadomość napisana przez Hadrian Zbarcea <hz...@gmail.com> 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" <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
>>> dkulp@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>>>
>>
Re: Camel manual in pdf....
Posted by Hadrian Zbarcea <hz...@gmail.com>.
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" <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
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>
Re: Camel manual in pdf....
Posted by Christian Müller <ch...@gmail.com>.
+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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>