+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 > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com