+1 #5 but would like to keep html manual.
On Thu, Jun 27, 2013 at 11:37 AM, Claus Ibsen <claus.ib...@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
> > 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
>
--
Cheers,
Jon
---------------
Red Hat, Inc.
Email: jans...@redhat.com
Web: http://redhat.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen
