+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