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
> dk...@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: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
