Community
Participate
Working Groups
PDF as an output format, implemented as a DocumentBuilder. The feature would include * a menu contribution *WikiText -> Generate PDF* * an ant task *wikitext-to-pdf* The PDF implementation would likely require one or more bundles from orbit.
Good idea, but I would think that the e.g. DITA tools will also generate PDF? Actually, I do not use DITA so far, but we plan to use it as a replacement for the curent OpenOffice documents.
(In reply to comment #1) > Good idea, but I would think that the e.g. DITA tools will also generate PDF? Yes, actually both DITA and DocBook can produce PDF. So a toolchain involving WikiText and DocBook XSL would be a viable alternative. The idea here is to eliminate the complexity of a multi-process conversion, and enable transforms from within the Eclipse UI.
David, we'll need to submit a CQ for Mylyn (even if Batik has already been approved for other projects and is available in Orbit). Let me know once you need it and we can go through the process.
(In reply to comment #3) > David, we'll need to submit a CQ for Mylyn (even if Batik has already been > approved for other projects and is available in Orbit). Let me know once you > need it and we can go through the process. Steffen, let's get it started. What do you need from me?
1. Determine the CQs of all required Orbit bundles. It's usually easiest to get the from here: http://download.eclipse.org/tools/orbit/downloads/drops/I20090320075422/ . 2. File a request for reuse from https://dev.eclipse.org/portal/myfoundation/portal/portal.php for each CQ. 3. Document approved CQs in the Mylyn IP log and at http://wiki.eclipse.org/index.php/Mylyn/Libraries. 4. Add the Orbit bundles to map file in the releng project (there is a script that does that).
(In reply to comment #2) > Yes, actually both DITA and DocBook can produce PDF. So a toolchain involving > WikiText and DocBook XSL would be a viable alternative. The idea here is to > eliminate the complexity of a multi-process conversion, and enable transforms > from within the Eclipse UI. Yes, it is definitely a good idea, looking forward to the implementation.
Created attachment 130720 [details] initial cut of FO builder created a rough draft of an XSL-FO document builder. XSL-FO is the logical starting point when producing PDF output. Also it has no dependencies on 3rd party libraries, so could conceivably be used without FOP or Batik.
Created attachment 130721 [details] mylyn/context/zip
Created attachment 130790 [details] implementation refined new implementation can handle images and spans and blocks of various types, links, etc.
Created attachment 130791 [details] sample of generated output
outstanding items: * configurability (fonts, hyperlink colors, etc.) * spacing for list items * title page * header/footer * CSS support * page numbering
looking over bug 258349 (add Batik 1.7 PDF transcoder) and the existing orbit bundles there appear to be some issues that need resolving: # org.apache.batik bundles in orbit (1.7) don't include the PDF transcoder # the CQ for adding the PDF transcoder has lost its backing from the requesting project(s) for Galileo # the CQ only covers the FOP portions that are included in the FOP jar that is distributed with batik, which doesn't include all of FOP # Batik 1.7 is listed as a 'normal' dependency of FOP To me it appears as if to use FOP we need Batik. The existing Batik CQ doesn't cover enough of FOP for it to be useful for us. Thus we have a couple of choices that I see: # try to convince the existing CQs to expand to cover all of FOP ## provide project backing to those CQs to be brought forward # create new orbit CQs to cover all of FOP/Batik # create a CQ for Mylyn to use Batik and FOP outside of Orbit It looks to me as though this is all too late for Galileo due to the IP cut-off.
Until the IP issues can be resolved PDF capability can be found on the "Textile-J project site":https://textile-j.dev.java.net/builds/wikitext/
David: Good compromise for the time being. Fyi, CDT ends up needing to make similar add-ons for things that have not passed review or are unable to pass review (e.g., GPL).
(In reply to comment #14) > David: Good compromise for the time being. Fyi, CDT ends up needing to make > similar add-ons for things that have not passed review or are unable to pass > review (e.g., GPL). Thanks for the feedback. I agree: it gives people immediate access to the feature, providing opportunities for use and feedback while we're blocked elsewhere.
closing due to lack of demand. PDF can be produced using the following technique: http://greensopinion.blogspot.ca/2009/04/mylyn-wikitext-produces-pdf.html
