Camel manual in pdf....

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Camel manual in pdf....

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
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: Camel manual in pdf....

Maruan Sahyoun
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 <[hidden email]>:

>
> 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
> [hidden email] - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
Reply | Threaded
Open this post in threaded view
|

Re: Camel manual in pdf....

dkulp@apache.org

On Jun 26, 2013, at 12:28 PM, Maruan Sahyoun <[hidden email]> 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 <[hidden email]>:
>
>>
>> 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
>> [hidden email] - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>

--
Daniel Kulp
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: Camel manual in pdf....

Claus Ibsen-2
In reply to this post by dkulp@apache.org
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 <[hidden email]> 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
> [hidden email] - 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: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Reply | Threaded
Open this post in threaded view
|

Re: Camel manual in pdf....

hadrian
#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 <[hidden email]> 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
>> [hidden email] - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Camel manual in pdf....

Willem.Jiang
Administrator
In reply to this post by dkulp@apache.org
+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
> [hidden email] - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com



Reply | Threaded
Open this post in threaded view
|

Re: Camel manual in pdf....

Jon Anstey
In reply to this post by Claus Ibsen-2
+1 #5 but would like to keep html manual.


On Thu, Jun 27, 2013 at 11:37 AM, Claus Ibsen <[hidden email]> 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 <[hidden email]> 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
> > [hidden email] - 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: [hidden email]
> 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: [hidden email]
Web: http://redhat.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen
Reply | Threaded
Open this post in threaded view
|

Re: Camel manual in pdf....

Christian Mueller
Administrator
In reply to this post by dkulp@apache.org
+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" <[hidden email]>:

>
> 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
> [hidden email] - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Camel manual in pdf....

hadrian
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" <[hidden email]>:
>
>>
>> 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
>> [hidden email] - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Camel manual in pdf....

Łukasz Dywicki
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 <[hidden email]> 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" <[hidden email]>:
>>
>>>
>>> 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
>>> [hidden email] - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Camel manual in pdf....

dkulp@apache.org
In reply to this post by hadrian

On Jun 27, 2013, at 1:16 PM, Hadrian Zbarcea <[hidden email]> 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" <[hidden email]>:
>>
>>>
>>> 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
>>> [hidden email] - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>>>
>>

--
Daniel Kulp
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com