+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



Reply via email to