[oXygen XML Editor Blog] - Possibilities to obtain PDF from DITA
oXygen XML Editor Blog /////////////////////////////////////////// Possibilities to obtain PDF from DITA Posted: 16 Nov 2015 01:07 PM PST http://feedproxy.google.com/~r/AboutOxygenXmlEditor/~3/sXZMCVP56Pc/possibilities-to-obtain-pdf-from-dita.html?utm_source=feedburner&utm_medium=email Lately while attending Tekom 2015 and DITA OT Day 2015 I happened to come across two more DITA to PDF solutions that I did not know about so I tried to compile below a list of all DITA to PDF possibilities that I know of, along with some details: Legacy DITA to PDF editing solution. It is no longer distribute with DITA OT 2.x and is probably not compatible anymore with it. Default DITA to PDF solution embedded in the DITA Open Toolkit distribution. Besides Apache FOP you can also use RenderX XEP or Antenna House for publishing. It's customization can be done either via a plugin or via a PDF customization folder: https://www.oxygenxml.com/doc/versions/17.1/ug-editor/index.html#topics/dita.... DITA to PDF using CSS. This open source DITA OT plugin was developed by Oxygen as an alternative to the default PDF publishing. It allows styling the DITA content using CSS and publishing to PDF using either Prince XML or Antenna House. Antenna House DITA OT plugin for producing PDF from DITA using Antenna House. There is also a DITA specialization plugin which allows you to set specific formatting attributes directly to DITA elements. The TopLeaf XML Publisher commercial product allows you to produce various outputs like PDF and EPUB from XML content. The application also has a visual PDF layout formatter, it comes also with a DITA OT plugin and has installation instructions for Oxygen:http://www.turnkey.com.au/tksweb/xmtp/webhelp_out/oxygen/install.html. Miramo, again a commercial solution which recently started developing support for DITA using a DITA OT plugin. Possibly user based DITA to PDF publishing will be free and server based production will require buying a license. Like TopLeaf, it also has a visual PDF layout designer. Adobe FrameMaker can also publish to PDF using its own solution. Now the question would be, why there are so many solutions available? In my opinion all these solutions are available because the default DITA to PDF output still requires quite a lot of XSLT skills in order to customize. Jarno Elovirta's PDF plugin generator covers some of the mainstream possible customizations but not all. What do you think? -- You are subscribed to email updates from "oXygen XML Editor Blog." To stop receiving these emails, you may unsubscribe now: https://feedburner.google.com/fb/a/mailunsubscribe?k=y_tRXtumvTurKTedh51JnlY... Email delivery powered by Google. Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States
On 17/11/2015 4:30 pm, oXygen XML Editor Blog wrote:
oXygen XML Editor Blog
/////////////////////////////////////////// Possibilities to obtain PDF from DITA
Posted: 16 Nov 2015 01:07 PM PST http://feedproxy.google.com/~r/AboutOxygenXmlEditor/~3/sXZMCVP56Pc/possibilities-to-obtain-pdf-from-dita.html?utm_source=feedburner&utm_medium=email
[Note: this began as a comment on the blog, but Blogger hates me and may have eaten it, so here it is.] Another reason is that Apache's FOP suffers all sorts of bugs (as we've discussed before) and clearly the timeframe on resolving these hasn't been good enough for the companies that need it, so the market responded. From the looks of things a lot of the solutions are built on .NET, so there's still room for more entrants in the market if they can meet the needs of the non-Microsoft market. Also, there are other methods to get what people want (and no one really cares what the method is if it works and can be entirely automated). DITA to [X]HTML + CSS then generate the PDF using wkhtmltopdf. The advantage is it just works. The disadvantage is that the webkit based solution Google used is built on Qt 4.8 and, like many browsers, it does not render the text-justify style in CSS. If you want justified text in print, you'll need another solution. Since LibreOffice can utilise XSL files and take instructions via the command line, it may be quite possible to use that in conjunction with any OpenDocument template (.ott files), though I haven't tried it yet. It's use of XSL files require them being loaded through the GUI first. Alternatively there may be an avenue to ignore PDF entirely by implementing Microsoft's Open XML Paper Specification (.oxps files), but it probably requires implementing vast swathes of the .NET framework in order to provide XAML support in a platform independent way (a shame since OpenXPS looked interesting and having seen what PDF really is underneath an alternative is always appealing). Another option once existing transformations to HTML or DOCX are included is to tap pandoc again and use its PDF generation. That utilises LaTeX, however, and looks quite different to most other PDFs. Controlling that layout requires a detailed understanding of LaTeX's syntax. I have yet to see any solution which utilises Apple's Quartz Core framework on which OS X is built. Which is kind of odd given how extensive XML is in OS X configuration and that PDF is one of the true essential foundations of Quartz. It's quite possible that everything is already in place, but Apple just hasn't told anyone because that's their secret. They can be a bit weird sometimes. I haven't been too worried about PDF or print so far, but if that changes and spending thousands of dollars isn't an option (and it isn't). I suspect I'd end up finding the best way to feed documents back to LibreOffice and let it print them or produce the PDF, depending on which path required more fiddling. It might even be possible to get LibreOffice to process the output of the com.oxygenxml.pdf.css plugin. If that works then you've got a free framework that runs on OS X, Linux, Windows, Solaris, BSD and other bits and pieces. Admittedly it's a 660MB framework, but that's still smaller than a full LaTeX installation. ... oh damn, now I'm curious ... [at this point some time passed] ... Okay, the quickest and easiest method is to use LibreOffice with the built-in DITA Map to ODF plugin and then use this command on the generated file: [/path/to/]soffice --headless --convert-to pdf filename.odt Change the path to the soffice binary to whatever is relevant for your platform. For OS X users that should be: /Applications/LibreOffice.app/Contents/MacOS/soffice --headless --convert-to pdf filename.odt It may be preferable to adjust the OpenDocument template used with the generated file first and assuming the DITA-OT plugin is already using an ODF template it shouldn't be too difficult to make a duplicate scenario allowing alternative templates to be specified. If that is the case, that's everything. Some quick grepping, however, indicates that the default ODF output is entirely XSL driven, so chances are modifications will involve adjusting the ./xsl/xslodt/dita2odtstyles.xsl file in the plugin. This may be an issue if, for example, you think using Courier for footnotes is just annoying when all the rest of the text uses a variable width sans serif font. If XSL editing is to be avoided at all costs then convert to DOCX, Docbook or a single page HTML file (if you leave them separate you will have a lot of typing to do) and use that with pandoc as pandoc can accept an ODF template on the command line with the --reference option. Using this will completely override existing formatting so if you just want to adjust the current template's chosen fonts in the DITA-OT plugin via the Pandoc method, use LibreOffice to create a new template based on the style of a document generated with the DITA-OT plugin (it's possible within LO to import styles from any file, whether it's a template or not, which can be used to make a new template based on it - which means if you want to nick the style used in the LibreOffice documentation then you can). Since LibreOffice can't use an ODF template via the headless command (very annoying, but can't be helped yet) the prize here goes to the first person or group who converts the existing DITA Map to ODF plugin to utilise an ODF template or, more likely, to create an ODF to DITA transformation which includes an option to generate XSL files to turn replace the current style XSL files (so ODF to XSL via an XSLT) since there's no real difference between an ODT and an OTT other than how the office suite(s) treat them. The pandoc variant will extend this to work with DOCX and its template files too, but I only use DOCX as a stepping stone between various formats (it appears to be the "gateway drug" for all file formats, at least until DITA can cover everything). Anyway, the important point is that it does work and will work on any system with either LibreOffice or OpenOffice.org and possibly with Abiword (I haven't used that one, so can't confirm). For my part I'm trying to avoid PDF where possible (in part because I started reading the spec earlier this year for reasons better left to the mists of time, so I'd just go for the quick and easy convert to ODT and then adjust the styles before printing or exporting to PDF. Either that or spend a day or two fiddling to get the builtin plugin to use better fonts and then leave it as is. It probably needs some tweaking anyway, though since it didn't include things like a page break between the cover page and the copyright page which was a little surprising, no doubt the more time spent on it the less suckage it will spout (to a limited extent with PDF as the end point). Regards, Ben P.S. You can cheat by generating an ePub and then converting that to PDF with the consumer's choice for file conversion: Calibre. Just don't rely on it because there are zero guarantees, it was never intended for anything other than managing personal ebook collections and shifting between devices (which is why I turned up in the first place, well due to that and Sigil breaking ePub 3.0 files). I'd use it to test drafts and the like, but never in production.
Another reason is that Apache's FOP suffers all sorts of bugs (as we've discussed before) and clearly the timeframe on resolving these hasn't been good enough for the companies that need it, so the market responded. From the looks of things a lot of the solutions are built on .NET, so there's still room for more entrants in the market if they can meet the needs of the non-Microsoft market. At the same time it might work for most projects. It may also depend on
Hi Ben, I'm not sure about the blog post, just logging in Google and posting a comment should have been enough. the level of customization you want to bring it to. I would consider a PDF printing solution complete if: 1) It generates a table of contents. 2) It generates an index page. 3) It properly generates links between pages. 4) It presents images. 5) It allows for extra customization. 6) Ideally it is multi platform.
DITA to [X]HTML + CSS then generate the PDF using wkhtmltopdf.
The advantage is it just works. The disadvantage is that the webkit based solution Google used is built on Qt 4.8 and, like many browsers, it does not render the text-justify style in CSS. If you want justified text in print, you'll need another solution. Yes, so XHTML to PDF would be a solution. Not sure how it would handle (1), (2) from the list above.
Since LibreOffice can utilise XSL files and take instructions via the command line, it may be quite possible to use that in conjunction with any OpenDocument template (.ott files), though I haven't tried it yet. It's use of XSL files require them being loaded through the GUI first. This might also work, also haven't tried this myself.
Alternatively there may be an avenue to ignore PDF entirely by implementing Microsoft's Open XML Paper Specification (.oxps files), but it probably requires implementing vast swathes of the .NET framework in order to provide XAML support in a platform independent way (a shame since OpenXPS looked interesting and having seen what PDF really is underneath an alternative is always appealing). People want the PDFs not only for print but also for web. PDF has become ubiquitous in tech docs although I doubt most of our end users actually use that to search for information. But most companies want to obtain it possibly in some (most) cases because of inertia Another option once existing transformations to HTML or DOCX are included is to tap pandoc again and use its PDF generation. That utilises LaTeX, however, and looks quite different to most other PDFs. Controlling that layout requires a detailed understanding of LaTeX's syntax. One of our German uses had the idea of developing a plugin for converting DITA to Latex. Maybe this is also a path which would need to be investigated.
I have yet to see any solution which utilises Apple's Quartz Core framework on which OS X is built. Which is kind of odd given how extensive XML is in OS X configuration and that PDF is one of the true essential foundations of Quartz. It's quite possible that everything is already in place, but Apple just hasn't told anyone because that's their secret. They can be a bit weird sometimes. Not multi platform :)
I haven't been too worried about PDF or print so far, but if that changes and spending thousands of dollars isn't an option (and it isn't). I suspect I'd end up finding the best way to feed documents back to LibreOffice and let it print them or produce the PDF, depending on which path required more fiddling. It might even be possible to get LibreOffice to process the output of the com.oxygenxml.pdf.css plugin. If that works then you've got a free framework that runs on OS X, Linux, Windows, Solaris, BSD and other bits and pieces. Admittedly it's a 660MB framework, but that's still smaller than a full LaTeX installation. One problem with ODT is that I do not know how much this support will be continually kept and improved in the DITA OT output. I'm not sure if many people are interested in this format. The main DITA OT developers are not. From the discussions at the DITA OT Day, it might be possible that at some point in the future some plugins (excepting XHTML and PDF outputs) will be extracted to separate GitHub projects. But of course the DITA OT is open source and anybody can contribute.
Regards, Radu Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 18/11/15 05:14, Ben McGinnes wrote:
On 17/11/2015 4:30 pm, oXygen XML Editor Blog wrote:
oXygen XML Editor Blog
/////////////////////////////////////////// Possibilities to obtain PDF from DITA
Posted: 16 Nov 2015 01:07 PM PST http://feedproxy.google.com/~r/AboutOxygenXmlEditor/~3/sXZMCVP56Pc/possibilities-to-obtain-pdf-from-dita.html?utm_source=feedburner&utm_medium=email [Note: this began as a comment on the blog, but Blogger hates me and may have eaten it, so here it is.]
Another reason is that Apache's FOP suffers all sorts of bugs (as we've discussed before) and clearly the timeframe on resolving these hasn't been good enough for the companies that need it, so the market responded. From the looks of things a lot of the solutions are built on .NET, so there's still room for more entrants in the market if they can meet the needs of the non-Microsoft market.
Also, there are other methods to get what people want (and no one really cares what the method is if it works and can be entirely automated).
DITA to [X]HTML + CSS then generate the PDF using wkhtmltopdf.
The advantage is it just works. The disadvantage is that the webkit based solution Google used is built on Qt 4.8 and, like many browsers, it does not render the text-justify style in CSS. If you want justified text in print, you'll need another solution.
Since LibreOffice can utilise XSL files and take instructions via the command line, it may be quite possible to use that in conjunction with any OpenDocument template (.ott files), though I haven't tried it yet. It's use of XSL files require them being loaded through the GUI first.
Alternatively there may be an avenue to ignore PDF entirely by implementing Microsoft's Open XML Paper Specification (.oxps files), but it probably requires implementing vast swathes of the .NET framework in order to provide XAML support in a platform independent way (a shame since OpenXPS looked interesting and having seen what PDF really is underneath an alternative is always appealing).
Another option once existing transformations to HTML or DOCX are included is to tap pandoc again and use its PDF generation. That utilises LaTeX, however, and looks quite different to most other PDFs. Controlling that layout requires a detailed understanding of LaTeX's syntax.
I have yet to see any solution which utilises Apple's Quartz Core framework on which OS X is built. Which is kind of odd given how extensive XML is in OS X configuration and that PDF is one of the true essential foundations of Quartz. It's quite possible that everything is already in place, but Apple just hasn't told anyone because that's their secret. They can be a bit weird sometimes.
I haven't been too worried about PDF or print so far, but if that changes and spending thousands of dollars isn't an option (and it isn't). I suspect I'd end up finding the best way to feed documents back to LibreOffice and let it print them or produce the PDF, depending on which path required more fiddling. It might even be possible to get LibreOffice to process the output of the com.oxygenxml.pdf.css plugin. If that works then you've got a free framework that runs on OS X, Linux, Windows, Solaris, BSD and other bits and pieces. Admittedly it's a 660MB framework, but that's still smaller than a full LaTeX installation.
... oh damn, now I'm curious ... [at this point some time passed] ...
Okay, the quickest and easiest method is to use LibreOffice with the built-in DITA Map to ODF plugin and then use this command on the generated file:
[/path/to/]soffice --headless --convert-to pdf filename.odt
Change the path to the soffice binary to whatever is relevant for your platform. For OS X users that should be:
/Applications/LibreOffice.app/Contents/MacOS/soffice --headless --convert-to pdf filename.odt
It may be preferable to adjust the OpenDocument template used with the generated file first and assuming the DITA-OT plugin is already using an ODF template it shouldn't be too difficult to make a duplicate scenario allowing alternative templates to be specified. If that is the case, that's everything.
Some quick grepping, however, indicates that the default ODF output is entirely XSL driven, so chances are modifications will involve adjusting the ./xsl/xslodt/dita2odtstyles.xsl file in the plugin. This may be an issue if, for example, you think using Courier for footnotes is just annoying when all the rest of the text uses a variable width sans serif font.
If XSL editing is to be avoided at all costs then convert to DOCX, Docbook or a single page HTML file (if you leave them separate you will have a lot of typing to do) and use that with pandoc as pandoc can accept an ODF template on the command line with the --reference option. Using this will completely override existing formatting so if you just want to adjust the current template's chosen fonts in the DITA-OT plugin via the Pandoc method, use LibreOffice to create a new template based on the style of a document generated with the DITA-OT plugin (it's possible within LO to import styles from any file, whether it's a template or not, which can be used to make a new template based on it - which means if you want to nick the style used in the LibreOffice documentation then you can).
Since LibreOffice can't use an ODF template via the headless command (very annoying, but can't be helped yet) the prize here goes to the first person or group who converts the existing DITA Map to ODF plugin to utilise an ODF template or, more likely, to create an ODF to DITA transformation which includes an option to generate XSL files to turn replace the current style XSL files (so ODF to XSL via an XSLT) since there's no real difference between an ODT and an OTT other than how the office suite(s) treat them.
The pandoc variant will extend this to work with DOCX and its template files too, but I only use DOCX as a stepping stone between various formats (it appears to be the "gateway drug" for all file formats, at least until DITA can cover everything).
Anyway, the important point is that it does work and will work on any system with either LibreOffice or OpenOffice.org and possibly with Abiword (I haven't used that one, so can't confirm). For my part I'm trying to avoid PDF where possible (in part because I started reading the spec earlier this year for reasons better left to the mists of time, so I'd just go for the quick and easy convert to ODT and then adjust the styles before printing or exporting to PDF. Either that or spend a day or two fiddling to get the builtin plugin to use better fonts and then leave it as is. It probably needs some tweaking anyway, though since it didn't include things like a page break between the cover page and the copyright page which was a little surprising, no doubt the more time spent on it the less suckage it will spout (to a limited extent with PDF as the end point).
Regards, Ben
P.S. You can cheat by generating an ePub and then converting that to PDF with the consumer's choice for file conversion: Calibre. Just don't rely on it because there are zero guarantees, it was never intended for anything other than managing personal ebook collections and shifting between devices (which is why I turned up in the first place, well due to that and Sigil breaking ePub 3.0 files). I'd use it to test drafts and the like, but never in production.
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com https://www.oxygenxml.com/mailman/listinfo/oxygen-user
--
Hi, I have no idea on what DITA is, but to generate PDF from XHTML+CSS 2.1, xhtmlrenderer (aka Flying Saucer) works perfectly. The project is quite inactive, as all 2.1 CSS fonctionnalities were implemented, and no bug was found since, but it is still reliable. It relies on iText to produce PDF. In Java, it is very easy to chain XSL transformation(s) and PDF creation. So a Dita-to-xhtml CSS will do the job... Project's home is here : https://code.google.com/p/flying-saucer/ but code is hosted at github for long. Hope this helps... Christophe Le 2015-11-18 08:30, Radu Coravu a écrit :
Hi Ben,
I'm not sure about the blog post, just logging in Google and posting a comment should have been enough.
Another reason is that Apache's FOP suffers all sorts of bugs (as we've discussed before) and clearly the timeframe on resolving these hasn't been good enough for the companies that need it, so the market responded. From the looks of things a lot of the solutions are built on .NET, so there's still room for more entrants in the market if they can meet the needs of the non-Microsoft market. At the same time it might work for most projects. It may also depend on the level of customization you want to bring it to. I would consider a PDF printing solution complete if:
1) It generates a table of contents. 2) It generates an index page. 3) It properly generates links between pages. 4) It presents images. 5) It allows for extra customization. 6) Ideally it is multi platform.
DITA to [X]HTML + CSS then generate the PDF using wkhtmltopdf.
The advantage is it just works. The disadvantage is that the webkit based solution Google used is built on Qt 4.8 and, like many browsers, it does not render the text-justify style in CSS. If you want justified text in print, you'll need another solution. Yes, so XHTML to PDF would be a solution. Not sure how it would handle (1), (2) from the list above.
Since LibreOffice can utilise XSL files and take instructions via the command line, it may be quite possible to use that in conjunction with any OpenDocument template (.ott files), though I haven't tried it yet. It's use of XSL files require them being loaded through the GUI first. This might also work, also haven't tried this myself.
Alternatively there may be an avenue to ignore PDF entirely by implementing Microsoft's Open XML Paper Specification (.oxps files), but it probably requires implementing vast swathes of the .NET framework in order to provide XAML support in a platform independent way (a shame since OpenXPS looked interesting and having seen what PDF really is underneath an alternative is always appealing). People want the PDFs not only for print but also for web. PDF has become ubiquitous in tech docs although I doubt most of our end users actually use that to search for information. But most companies want to obtain it possibly in some (most) cases because of inertia
Another option once existing transformations to HTML or DOCX are included is to tap pandoc again and use its PDF generation. That utilises LaTeX, however, and looks quite different to most other PDFs. Controlling that layout requires a detailed understanding of LaTeX's syntax. One of our German uses had the idea of developing a plugin for converting DITA to Latex. Maybe this is also a path which would need to be investigated.
I have yet to see any solution which utilises Apple's Quartz Core framework on which OS X is built. Which is kind of odd given how extensive XML is in OS X configuration and that PDF is one of the true essential foundations of Quartz. It's quite possible that everything is already in place, but Apple just hasn't told anyone because that's their secret. They can be a bit weird sometimes. Not multi platform :)
I haven't been too worried about PDF or print so far, but if that changes and spending thousands of dollars isn't an option (and it isn't). I suspect I'd end up finding the best way to feed documents back to LibreOffice and let it print them or produce the PDF, depending on which path required more fiddling. It might even be possible to get LibreOffice to process the output of the com.oxygenxml.pdf.css plugin. If that works then you've got a free framework that runs on OS X, Linux, Windows, Solaris, BSD and other bits and pieces. Admittedly it's a 660MB framework, but that's still smaller than a full LaTeX installation. One problem with ODT is that I do not know how much this support will be continually kept and improved in the DITA OT output. I'm not sure if many people are interested in this format. The main DITA OT developers are not. From the discussions at the DITA OT Day, it might be possible that at some point in the future some plugins (excepting XHTML and PDF outputs) will be extracted to separate GitHub projects. But of course the DITA OT is open source and anybody can contribute.
Regards, Radu
Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
On 18/11/15 05:14, Ben McGinnes wrote:
On 17/11/2015 4:30 pm, oXygen XML Editor Blog wrote:
oXygen XML Editor Blog
/////////////////////////////////////////// Possibilities to obtain PDF from DITA
Posted: 16 Nov 2015 01:07 PM PST http://feedproxy.google.com/~r/AboutOxygenXmlEditor/~3/sXZMCVP56Pc/possibilities-to-obtain-pdf-from-dita.html?utm_source=feedburner&utm_medium=email
[Note: this began as a comment on the blog, but Blogger hates me and may have eaten it, so here it is.]
Another reason is that Apache's FOP suffers all sorts of bugs (as we've discussed before) and clearly the timeframe on resolving these hasn't been good enough for the companies that need it, so the market responded. From the looks of things a lot of the solutions are built on .NET, so there's still room for more entrants in the market if they can meet the needs of the non-Microsoft market.
Also, there are other methods to get what people want (and no one really cares what the method is if it works and can be entirely automated).
DITA to [X]HTML + CSS then generate the PDF using wkhtmltopdf.
The advantage is it just works. The disadvantage is that the webkit based solution Google used is built on Qt 4.8 and, like many browsers, it does not render the text-justify style in CSS. If you want justified text in print, you'll need another solution.
Since LibreOffice can utilise XSL files and take instructions via the command line, it may be quite possible to use that in conjunction with any OpenDocument template (.ott files), though I haven't tried it yet. It's use of XSL files require them being loaded through the GUI first.
Alternatively there may be an avenue to ignore PDF entirely by implementing Microsoft's Open XML Paper Specification (.oxps files), but it probably requires implementing vast swathes of the .NET framework in order to provide XAML support in a platform independent way (a shame since OpenXPS looked interesting and having seen what PDF really is underneath an alternative is always appealing).
Another option once existing transformations to HTML or DOCX are included is to tap pandoc again and use its PDF generation. That utilises LaTeX, however, and looks quite different to most other PDFs. Controlling that layout requires a detailed understanding of LaTeX's syntax.
I have yet to see any solution which utilises Apple's Quartz Core framework on which OS X is built. Which is kind of odd given how extensive XML is in OS X configuration and that PDF is one of the true essential foundations of Quartz. It's quite possible that everything is already in place, but Apple just hasn't told anyone because that's their secret. They can be a bit weird sometimes.
I haven't been too worried about PDF or print so far, but if that changes and spending thousands of dollars isn't an option (and it isn't). I suspect I'd end up finding the best way to feed documents back to LibreOffice and let it print them or produce the PDF, depending on which path required more fiddling. It might even be possible to get LibreOffice to process the output of the com.oxygenxml.pdf.css plugin. If that works then you've got a free framework that runs on OS X, Linux, Windows, Solaris, BSD and other bits and pieces. Admittedly it's a 660MB framework, but that's still smaller than a full LaTeX installation.
... oh damn, now I'm curious ... [at this point some time passed] ...
Okay, the quickest and easiest method is to use LibreOffice with the built-in DITA Map to ODF plugin and then use this command on the generated file:
[/path/to/]soffice --headless --convert-to pdf filename.odt
Change the path to the soffice binary to whatever is relevant for your platform. For OS X users that should be:
/Applications/LibreOffice.app/Contents/MacOS/soffice --headless --convert-to pdf filename.odt
It may be preferable to adjust the OpenDocument template used with the generated file first and assuming the DITA-OT plugin is already using an ODF template it shouldn't be too difficult to make a duplicate scenario allowing alternative templates to be specified. If that is the case, that's everything.
Some quick grepping, however, indicates that the default ODF output is entirely XSL driven, so chances are modifications will involve adjusting the ./xsl/xslodt/dita2odtstyles.xsl file in the plugin. This may be an issue if, for example, you think using Courier for footnotes is just annoying when all the rest of the text uses a variable width sans serif font.
If XSL editing is to be avoided at all costs then convert to DOCX, Docbook or a single page HTML file (if you leave them separate you will have a lot of typing to do) and use that with pandoc as pandoc can accept an ODF template on the command line with the --reference option. Using this will completely override existing formatting so if you just want to adjust the current template's chosen fonts in the DITA-OT plugin via the Pandoc method, use LibreOffice to create a new template based on the style of a document generated with the DITA-OT plugin (it's possible within LO to import styles from any file, whether it's a template or not, which can be used to make a new template based on it - which means if you want to nick the style used in the LibreOffice documentation then you can).
Since LibreOffice can't use an ODF template via the headless command (very annoying, but can't be helped yet) the prize here goes to the first person or group who converts the existing DITA Map to ODF plugin to utilise an ODF template or, more likely, to create an ODF to DITA transformation which includes an option to generate XSL files to turn replace the current style XSL files (so ODF to XSL via an XSLT) since there's no real difference between an ODT and an OTT other than how the office suite(s) treat them.
The pandoc variant will extend this to work with DOCX and its template files too, but I only use DOCX as a stepping stone between various formats (it appears to be the "gateway drug" for all file formats, at least until DITA can cover everything).
Anyway, the important point is that it does work and will work on any system with either LibreOffice or OpenOffice.org and possibly with Abiword (I haven't used that one, so can't confirm). For my part I'm trying to avoid PDF where possible (in part because I started reading the spec earlier this year for reasons better left to the mists of time, so I'd just go for the quick and easy convert to ODT and then adjust the styles before printing or exporting to PDF. Either that or spend a day or two fiddling to get the builtin plugin to use better fonts and then leave it as is. It probably needs some tweaking anyway, though since it didn't include things like a page break between the cover page and the copyright page which was a little surprising, no doubt the more time spent on it the less suckage it will spout (to a limited extent with PDF as the end point).
Regards, Ben
P.S. You can cheat by generating an ePub and then converting that to PDF with the consumer's choice for file conversion: Calibre. Just don't rely on it because there are zero guarantees, it was never intended for anything other than managing personal ebook collections and shifting between devices (which is why I turned up in the first place, well due to that and Sigil breaking ePub 3.0 files). I'd use it to test drafts and the like, but never in production.
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com https://www.oxygenxml.com/mailman/listinfo/oxygen-user
-- _______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com https://www.oxygenxml.com/mailman/listinfo/oxygen-user
participants (4)
-
Ben McGinnes -
cmarchand＠oxiane.com -
oXygen XML Editor Blog -
Radu Coravu