[jira] [Created] (FOP-2543) The avalon-framework-api-4.2.0 is broken and 4.3.1 is the current version
Ron Wheeler created FOP-2543: Summary: The avalon-framework-api-4.2.0 is broken and 4.3.1 is the current version Key: FOP-2543 URL: https://issues.apache.org/jira/browse/FOP-2543 Project: FOP Issue Type: Improvement Components: unqualified Affects Versions: 1.1 Environment: all Reporter: Ron Wheeler The 4.2.0 version is broken in Maven Central and 4.3.1 is current. Anyone using FOP (DITA-OT for instance) has to manually exclude 4.2.0 to get rid of build warnings. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
apache commons-io version
Can you upgrade your version of commons-io in FOP1.x. The current version is very old and causes a problem for the DITA-OT users since the DITA Maven plug-in uses the deleteQuietly method which appeared in version 1.4. The current version is 2.4 Have not checked 2.x but the same request could apply. Thanks Ron -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Why integrating DITA into XMLGraphics makes sense.
A good starting point: http://thecontentwrangler.com/2008/04/11/choosing_an_xml_schema_docbook_or_dita/ A good discussion about how DITA-OT uses XSL and XSL-FO to create PDF from DITA XML. http://www.scriptorium.com/whitepapers/ditaotpdf/DITA-PDF-tweaks.pdf I am trying to get the FOP side to be aware of the importance of DITA as a standard for documentation so the FOP developers will pay some attention to the needs for improved FOP features and perhaps give advice to the DITA-OT developers to use FOP in the best possible way. I am trying to get the DITA side to stop considering FOP to be a static thing that can not be changed and to start to contribute ideas and funding to make FOP do the things that it needs to do. I also want to encourage the DITA-OT team to enter into discussions with the FOP experts to make sure that DITA-OT uses FOP in the best possible way. This problem with the leading dots is a good example of the problem. When the problem was raised by a documentation author, one of the leading DITA experts proposed the solution to the problem was to stop trying to make FOP work since it is buggy and inconsistent rather than suggesting that the user ask the question in the FOP user forum. When I brought the problem here, an answer was provided that looks like a simple change to DITA-OT's FOP configuration that seemed to be a solution to this problem that is well understood here. Ron On 24/05/2014 9:22 PM, Glenn Adams wrote: I'm not familiar with DITA, but if a DITA product depends on FOP, then DITA as a group or its sponsors should consider funding the work they would like to see done in FOP. Simply asking the few developers in the FOP project to support DITA priorities won't guarantee any results. On Sun, May 25, 2014 at 5:38 AM, Ron Wheeler rwhee...@artifact-software.com mailto:rwhee...@artifact-software.com wrote: You are right , of course. However, this very large community ( one DITA LinkedIn group has 4,600 members, the Technical Doc group has over 14,000 members) does not see themselves as users of FOP but only as users of DITA-OT which in turn has a dependency on FOP. As far as I know DITA is the most popular XML language for constructing documents and it seems odd that there is almost no connection between the Apache efforts in XML and the biggest potential set of users and drivers of demand for the things that XMLGraphics is producing. I will pass on the information to the forum where the question was raised. Thanks On 23/05/2014 6:05 PM, Luis Bernardo wrote: I think this only shows that the person is not going to the source (i.e., the FOP user mailing list) to request help. The example shown can be greatly improved by using fo:leader width=100% leader-pattern=use-content./fo:leader instead of fo:leader leader-pattern=dots / The FOP implementation repeats 3 dots (...) when using the leader-pattern=dots which is not very intelligent since it can lead to misalignment many times. But by specifying the leader content as just one dot the result can be greatly improved, although I agree that there is room for improvement in this feature. On 5/23/14, 4:14 PM, Ron Wheeler wrote: The conversation below shows one of the reasons why I would like to see DITA become part of the XMLGraphics family. One of the most experienced and influential DITA practitioners is giving advice about the suitability of FOP for producing correct PDFs. Ron - This is an issue with the FOP XSL-FO engine (one of many). For top-qualify PDF output you really need to license Antenna House XSL Formatter or RenderX XEP, both of which produce excellent results. FOP simply has too many bugs and limitations to be generally useful for production PDF generation using XSL-FO, unfortunately. Cheers, XXX On 5/23/14, 9:54 AM, yyy [dita-users] dita-us...@yahoogroups.com mailto:dita-us...@yahoogroups.com wrote: [Attachment(s) #TopText from Mark Peters included below] Hi, Using DITA-OT 1.7 and the default org.dita.pdf2 plugin, I notice that some TOC entries are randomly misaligned slightly. The leader extends one or two extra dots. For example (not sure if the formatting will come through correctly. An image is also attached): Chapter 1: RTI4T System Overview...11 RTI System Diagram.12 System Components...12 RTI Network Diagram...15 Summary of RTI Setup Tasks...15 Like I said, the misalignment is random. It's not all H1s or H2s, for example, which would probably be relatively easy to fix. Even more puzzling, the XSL-FO attributes in the temp
Re: Why integrating DITA into XMLGraphics makes sense.
You are right , of course. However, this very large community ( one DITA LinkedIn group has 4,600 members, the Technical Doc group has over 14,000 members) does not see themselves as users of FOP but only as users of DITA-OT which in turn has a dependency on FOP. As far as I know DITA is the most popular XML language for constructing documents and it seems odd that there is almost no connection between the Apache efforts in XML and the biggest potential set of users and drivers of demand for the things that XMLGraphics is producing. I will pass on the information to the forum where the question was raised. Thanks On 23/05/2014 6:05 PM, Luis Bernardo wrote: I think this only shows that the person is not going to the source (i.e., the FOP user mailing list) to request help. The example shown can be greatly improved by using fo:leader width=100% leader-pattern=use-content./fo:leader instead of fo:leader leader-pattern=dots / The FOP implementation repeats 3 dots (...) when using the leader-pattern=dots which is not very intelligent since it can lead to misalignment many times. But by specifying the leader content as just one dot the result can be greatly improved, although I agree that there is room for improvement in this feature. On 5/23/14, 4:14 PM, Ron Wheeler wrote: The conversation below shows one of the reasons why I would like to see DITA become part of the XMLGraphics family. One of the most experienced and influential DITA practitioners is giving advice about the suitability of FOP for producing correct PDFs. Ron - This is an issue with the FOP XSL-FO engine (one of many). For top-qualify PDF output you really need to license Antenna House XSL Formatter or RenderX XEP, both of which produce excellent results. FOP simply has too many bugs and limitations to be generally useful for production PDF generation using XSL-FO, unfortunately. Cheers, XXX On 5/23/14, 9:54 AM, yyy [dita-users] dita-us...@yahoogroups.com wrote: [Attachment(s) #TopText from Mark Peters included below] Hi, Using DITA-OT 1.7 and the default org.dita.pdf2 plugin, I notice that some TOC entries are randomly misaligned slightly. The leader extends one or two extra dots. For example (not sure if the formatting will come through correctly. An image is also attached): Chapter 1: RTI4T System Overview...11 RTI System Diagram.12 System Components...12 RTI Network Diagram...15 Summary of RTI Setup Tasks...15 Like I said, the misalignment is random. It's not all H1s or H2s, for example, which would probably be relatively easy to fix. Even more puzzling, the XSL-FO attributes in the temp files are identical for nodes at the same level that have different alignments. For example, here are two H1-level nodes. The first node is slightly misaligned. But the indent values are identical for both nodes. fo:block start-indent=25pt + (1 * 30pt) + 14pt fo:block end-indent=22pt font-size=10pt font-weight=normal last-line-end-indent=-22pt text-align=justify text-align-last=justify text-indent=-14pt fo:basic-link internal-destination=_OPENTOPIC_TOC_PROCESSING_d70e1310 line-height=150% fo:inline end-indent=14ptRTI System Diagram/fo:inline fo:inline keep-together.within-line=always start-indent=-14pt fo:leader leader-pattern=dots/ fo:page-number-citation ref-id=_OPENTOPIC_TOC_PROCESSING_d70e1310/ /fo:inline /fo:basic-link /fo:block /fo:block fo:block start-indent=25pt + (1 * 30pt) + 14pt fo:block end-indent=22pt font-size=10pt font-weight=normal last-line-end-indent=-22pt text-align=justify text-align-last=justify text-indent=-14pt fo:basic-link internal-destination=_OPENTOPIC_TOC_PROCESSING_d70e1334 line-height=150% fo:inline end-indent=14pt System Components /fo:inline fo:inline keep-together.within-line=always start-indent=-14pt fo:leader leader-pattern=dots/ fo:page-number-citation ref-id=_OPENTOPIC_TOC_PROCESSING_d70e1334/ /fo:inline /fo:basic-link /fo:block /fo:block I'm viewing the PDFs in Abobe Reader, but that hasn't made a difference in the past. Any idea what's going on? Thanks for any insights. yyy -- Ron Wheeler President Artifact Software Inc email:rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 -- Ron Wheeler President Artifact
Why integrating DITA into XMLGraphics makes sense.
The conversation below shows one of the reasons why I would like to see DITA become part of the XMLGraphics family. One of the most experienced and influential DITA practitioners is giving advice about the suitability of FOP for producing correct PDFs. Ron - This is an issue with the FOP XSL-FO engine (one of many). For top-qualify PDF output you really need to license Antenna House XSL Formatter or RenderX XEP, both of which produce excellent results. FOP simply has too many bugs and limitations to be generally useful for production PDF generation using XSL-FO, unfortunately. Cheers, XXX On 5/23/14, 9:54 AM, yyy [dita-users] dita-us...@yahoogroups.com wrote: [Attachment(s) #TopText from Mark Peters included below] Hi, Using DITA-OT 1.7 and the default org.dita.pdf2 plugin, I notice that some TOC entries are randomly misaligned slightly. The leader extends one or two extra dots. For example (not sure if the formatting will come through correctly. An image is also attached): Chapter 1: RTI4T System Overview...11 RTI System Diagram.12 System Components...12 RTI Network Diagram...15 Summary of RTI Setup Tasks...15 Like I said, the misalignment is random. It's not all H1s or H2s, for example, which would probably be relatively easy to fix. Even more puzzling, the XSL-FO attributes in the temp files are identical for nodes at the same level that have different alignments. For example, here are two H1-level nodes. The first node is slightly misaligned. But the indent values are identical for both nodes. fo:block start-indent=25pt + (1 * 30pt) + 14pt fo:block end-indent=22pt font-size=10pt font-weight=normal last-line-end-indent=-22pt text-align=justify text-align-last=justify text-indent=-14pt fo:basic-link internal-destination=_OPENTOPIC_TOC_PROCESSING_d70e1310 line-height=150% fo:inline end-indent=14ptRTI System Diagram/fo:inline fo:inline keep-together.within-line=always start-indent=-14pt fo:leader leader-pattern=dots/ fo:page-number-citation ref-id=_OPENTOPIC_TOC_PROCESSING_d70e1310/ /fo:inline /fo:basic-link /fo:block /fo:block fo:block start-indent=25pt + (1 * 30pt) + 14pt fo:block end-indent=22pt font-size=10pt font-weight=normal last-line-end-indent=-22pt text-align=justify text-align-last=justify text-indent=-14pt fo:basic-link internal-destination=_OPENTOPIC_TOC_PROCESSING_d70e1334 line-height=150% fo:inline end-indent=14pt System Components /fo:inline fo:inline keep-together.within-line=always start-indent=-14pt fo:leader leader-pattern=dots/ fo:page-number-citation ref-id=_OPENTOPIC_TOC_PROCESSING_d70e1334/ /fo:inline /fo:basic-link /fo:block /fo:block I'm viewing the PDFs in Abobe Reader, but that hasn't made a difference in the past. Any idea what's going on? Thanks for any insights. yyy -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: DITA-OT and FOP
On 01/04/2014 1:33 PM, Jan Tosovsky wrote: On 2014-03-30 Ron Wheeler wrote: On 30/03/2014 5:19 PM, Jan Tosovsky wrote: I personally think it would be much easier to attract developers to create a completely new paged media CSS engine than to add several niche XSL-FO features into FOP. But when mentioning the new engine, I don't think it is a good idea. Sooner or later these CSS features will be adopted by major browsers and in that time it won't be necessary to produce PDFs at all :-) The supposes that paper documentation will disappear. There are regulatory issues, industry practices, etc. that need to change. There will still be face to face meetings where someone wants to hand a piece of paper to someone for the next few years. Slightly off-topic, but a short comment... I didn't mean paper-less way, but http://en.wikipedia.org/wiki/MHTML way, where all dependencies are embedded in a single file which you can open in a browser (it acts as PDF, but it is HTML/CSS based). Jan Good point. PDF is not the only form that moves nicely to paper. Issues like signatures and version control are still open issues for me. DITA is already ahead in this area with a single set of source documents being able to be processed into PDF, HTML and other output formats. My feeling is that bringing this standard XML source document format with its editing tools into XMLGraphics will accelerate the development of better processes for producing these new formats and put the XMLGraphics tools into the mainstream of document production in for organizations that want a process that is supported by standards and a strong technical open source organization such as Apache. Ron -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: DITA-OT and FOP
These are great ideas and I think that getting the DITA community which is skilled at document management and document authoring connected with the people here who are looking at these issues from a technical point of view could energize the modernization of document production. DITA provides an authoring language that is independent of the output format and media. The language is XML so the processing technology has to start with XML but could have the output in any form (currently HTML and PDF but there is no theoretical restrictions). More comments in-line. On 30/03/2014 5:19 PM, Jan Tosovsky wrote: On 2014-03-26 Ron Wheeler wrote: On 26/03/2014 2:59 PM, Jan Tosovsky wrote: On 2014-03-26 Christopher R. Maden wrote: Although I don’t get a vote, I completely agree with Glenn that DITA integration into FOP is completely inappropriate. +1 FOP consumes standardized XSL-FO. DITA-OT should produce standardized XSL-FO. Period ;-) It does but FOP does not support all PDF features so some of the things that people can express in DITA's XML can not produce the PDF output that people want/need. There are two possible interpretations: (1) user's intent cannot be achieved by XSL-FO (2) user's intent can be achieved by XSL-FO, but the given functionality is not supported by FOP Another possible reason (3) the DITA-OT developers have not been able how to build the XSLT to get the required XSL-FO. I think that it will take a collaboration between the DITA-OT developers and the developers of FOP to determine which features are blocked by each of these reasons. Anyway, it would be nice to collect these requests (wish list) and create a poll targetting DITA community to get real demand for them. If there is something FOP related, FOP devs could roughly estimate mandays (and thereof costs). The final part is to find sponsors or involve crowdfunding. But keep in mind that XSL-FO is loosing its attraction. Its standardization has been discontinued and no one can expect new features in the near future. I strongly suggest joining already mentioned W3C PPL group http://www.w3.org/community/ppl/ which is trying to move these things forward. I can not imagine that PDF will disappear in the intermediate term but mobile is likely to shift the emphasis on DITA-HTML and CSS. Standardization has moved primarily into the CSS. There are many proposals trying to enhance this standard with paged media related stuff. It is clear that this is considered as the future. Check also this article: http://alistapart.com/article/building-books-with-css3 I personally think it would be much easier to attract developers to create a completely new paged media CSS engine than to add several niche XSL-FO features into FOP. But when mentioning the new engine, I don't think it is a good idea. Sooner or later these CSS features will be adopted by major browsers and in that time it won't be necessary to produce PDFs at all :-) The supposes that paper documentation will disappear. There are regulatory issues, industry practices, etc. that need to change. There will still be face to face meetings where someone wants to hand a piece of paper to someone for the next few years. PDF engines (XSL-FO, CSS) will survive only if they offer any added value. I can think of an export into other formats (PS, AFP), a sophisticated index rendering (XSL-FO 1.1) or microtypography features http://en.wikipedia.org/wiki/Microtypography (not covered by standards yet). But AFAIK the latter would require major FOP redesign... Collaboration with the largest authoring community might help keep the XMLGraphics group at the forefront of these ideas. Jan -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: DITA-OT and FOP
On 27/03/2014 6:26 PM, Vincent Hennebert wrote: (CC-ing to general@ as it’s the place where I believe the conversation should take place.) I too would be in favour of welcoming DITA-OT as a sub-project of XML Graphics. I think it matches rather well the purpose of this project. A few comments: On 27/03/14 18:32, Ron Wheeler wrote: I think that you are right about being a sister project to FOP within XMLGraphics. The discussion from everyone has been very helpful even if the writer was negative to the idea. //I would be happy to see some interaction in a number of areas. a) Clearly, the DITA group should be pushing for the FOP features that are required to produce the documents that can be described in DITA. Pushing for having some features implemented is one thing; actually implementing them is another. Correct me if I’m wrong, but I don’t believe the skill sets of a DITA developer and a FOP developer intersect, do they? The DITA-OT uses XSLT to transform DITA xml to other forms so there is a certain amount of XSLT expertise. The DITA-OT includes a Maven plug-in and some Ant so there is expertise in this area. The biggest contribution might be at the specification stage and if you can get some DITA users interested in the other XMLGraphics actvities, you might get some help in documentation since most of the users are Technical Writers by profession. So IIUC the goal of this would be to attract sponsors who use the DITA-OT to fund specific developments? I think that there is pent-up demand for customization and improvements to FOP. Or are DITA developers willing to learn what is necessary to contribute new features to FOP? I can not speak to that since I do not know the developers that well to comment on the range of their abilities and interests nor do I know what is required to make any specific upgrade to FOP. I suspect that it will depend on the difficulty and the technology involved in the specific feature. They certainly can provide input on functional details and provide test suites to test the new features as incorporated into DITA-OT. It may also attract some of the companies that develop portals, CMSs and editors for DITA (proprietary and open source) that see the XMLGraphics group as a place to acquire big chunks of functionality for their projects. They may have an interest in participating in the XMLGraphics development efforts in order to get features that they need or to contribute functionality that they have developed to existing projects. They may also want to draw on the expertise here to find better ways to process XML in their products. b)I think that the current Apache members could make positive suggestions about the processing and structure of the DITA toolkit. Again, because of the different skill sets you might have put your hopes a bit high I’m afraid. I have a lot of respect for the Apache processes and products and have used FOP for quite a few years in a very minor way. I suspect that there are people here that are very good at XSLT and software architecture in general. c) The DITA language specification is constantly undergoing updates and there are likely things that current FOP users could suggest as additions to allow them to use a standard language to author documents. FWIW you might want to become involved in the W3C Print ang Page Layout Community Group: http://www.w3.org/community/ppl/ d) The users of the DITA tool kit need some customization of FOP configuration to produce nice looking documents and there is likely a lot of experts here that could be engaged to do these projects. We can certainly increase the collaboration between the two projects, although I don’t think becoming part of XML Graphics is a requirement for that. Just out of curiosity, what are your reasons for wanting to become part of Apache? This is a bit of a personal exploration and anything that I find needs to go back to the DITA-OT group as a suggestion for further investigation by the key people. I am a minor user of DITA (2 small projects - one internal software manual and one to create a study for a client on modernizing their Learning and Development processes). Apache software is an integral part of everything that we develop. I see a lot of frustration in the DITA group about the limitations of DITA production caused by features missing from FOP (perhaps some are just misunderstandings about how to output XSL-FO in a way that will get the job done). DITA has a huge community of writers and documentation managers who are committed to producing reusable documentation using XML. It seems to me that putting these two communities together on the technical side would have a lot of mutual advantages. The document writers and front-end people who are using FOP directly might find that the DITA community has a lot of the answers for their document management questions and the DITA community would benefit from
Re: DITA-OT and FOP
I think that you are right about being a sister project to FOP within XMLGraphics. The discussion from everyone has been very helpful even if the writer was negative to the idea. //I would be happy to see some interaction in a number of areas. a) Clearly, the DITA group should be pushing for the FOP features that are required to produce the documents that can be described in DITA. b)I think that the current Apache members could make positive suggestions about the processing and structure of the DITA toolkit. c) The DITA language specification is constantly undergoing updates and there are likely things that current FOP users could suggest as additions to allow them to use a standard language to author documents. d) The users of the DITA tool kit need some customization of FOP configuration to produce nice looking documents and there is likely a lot of experts here that could be engaged to do these projects. Ron On 27/03/2014 12:18 PM, Chris Bowditch wrote: Hi Ron, Thanks for your e-mail. I can certainly see why joining the 2 communities seems like a good idea to help improve funding for FOP, and deliver the features DITA requires. I'd certainly be interested in seeing what the list of missing XSL-FO features are from a DITA perspective. The challenge with joining multiple communities together is that it makes the merged project too complex and it scares users/developers away. This is a problem faced by FOP already. The codebase is so vast and complex, many people struggle to get to grips with it. I would be against DITA and FOP merging for this reason, plus the separation of concerns already stated by others. That said, if DITA wanted to join Apache, adding DITA as a sub project of XMLGraphics would seem like a logical place for the DITA community. That way there would be some links between the 2 projects and an oversight of both from a common committee. This should help to improve interoperability a little although perhaps not to the extent you had hoped for. Thanks, Chris On 26/03/2014 14:42, Ron Wheeler wrote: The DITA-OT (DITA Open Toolkit) (http://www.ditaopentoolkit.org/) is an open source project that depends on FOP. It takes DITA (http://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture) XML input and produces a number of different document types. One of the main output types is PDF and it uses FOP to do this. It takes DITA input (xml) and produces an intermediate set of files that are processed by FOP to produce a PDF. It can also produce HTML There is a Maven plug-in to control the production in an IDE environment. It calls all the bits and pieces required to take the raw DITA XML files and output a document in PDF in the target folder. There is some interest in adding DITA-OT to the Apache family and in my opinion, the XMLGraphics group seems like a natural home and the FOP sub-project might be a good place for DITA-OT to reside. DITA-OT is a large community of users but a small community of developers. There are also a few enhancement ideas that would require FOP enhancements to complete. In addition, my own belief is that the FOP community could add some technical advice to the DITA-OT community that would be helpful. http://sourceforge.net/projects/dita-ot/ is the download page. DITA-OT is currently distributed under the Apache License V2.0. I am not one of the main players in the group but have taken on the task of seeing if there is a possibility of opening the discussion with the FOP group. Would there be any interest in considering adding front-end XML processing to the FOP production project? Ron -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
DITA-OT and FOP
The DITA-OT (DITA Open Toolkit) (http://www.ditaopentoolkit.org/) is an open source project that depends on FOP. It takes DITA (http://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture) XML input and produces a number of different document types. One of the main output types is PDF and it uses FOP to do this. It takes DITA input (xml) and produces an intermediate set of files that are processed by FOP to produce a PDF. It can also produce HTML There is a Maven plug-in to control the production in an IDE environment. It calls all the bits and pieces required to take the raw DITA XML files and output a document in PDF in the target folder. There is some interest in adding DITA-OT to the Apache family and in my opinion, the XMLGraphics group seems like a natural home and the FOP sub-project might be a good place for DITA-OT to reside. DITA-OT is a large community of users but a small community of developers. There are also a few enhancement ideas that would require FOP enhancements to complete. In addition, my own belief is that the FOP community could add some technical advice to the DITA-OT community that would be helpful. http://sourceforge.net/projects/dita-ot/ is the download page. DITA-OT is currently distributed under the Apache License V2.0. I am not one of the main players in the group but have taken on the task of seeing if there is a possibility of opening the discussion with the FOP group. Would there be any interest in considering adding front-end XML processing to the FOP production project? Ron -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: DITA-OT and FOP
On 26/03/2014 11:46 AM, Glenn Adams wrote: On Wed, Mar 26, 2014 at 8:42 AM, Ron Wheeler rwhee...@artifact-software.com mailto:rwhee...@artifact-software.com wrote: The DITA-OT (DITA Open Toolkit) (http://www.ditaopentoolkit.org/) is an open source project that depends on FOP. It takes DITA (http://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture) XML input and produces a number of different document types. One of the main output types is PDF and it uses FOP to do this. It takes DITA input (xml) and produces an intermediate set of files that are processed by FOP to produce a PDF. It can also produce HTML There is a Maven plug-in to control the production in an IDE environment. It calls all the bits and pieces required to take the raw DITA XML files and output a document in PDF in the target folder. There is some interest in adding DITA-OT to the Apache family and in my opinion, the XMLGraphics group seems like a natural home and the FOP sub-project might be a good place for DITA-OT to reside. DITA-OT is a large community of users but a small community of developers. There are also a few enhancement ideas that would require FOP enhancements to complete. In addition, my own belief is that the FOP community could add some technical advice to the DITA-OT community that would be helpful. http://sourceforge.net/projects/dita-ot/ is the download page. DITA-OT is currently distributed under the Apache License V2.0. I am not one of the main players in the group but have taken on the task of seeing if there is a possibility of opening the discussion with the FOP group. Would there be any interest in considering adding front-end XML processing to the FOP production project? FOP already has a front-end XML processor. It's called XSLT. It is provided solely as a convenience function. Some of us have doubts about whether that was a good idea or not, since it tends to generate a lot of traffic unrelated to FOP's core function. Why do you want *more* front end processing and why isn't XSLT sufficient? More means a set of XSLT stylesheets that validates a standard language called DITA (Docbook supported as well) and transforms it to FOP input (or HTML). You do raise a good point about the user group traffic and splitting the conversation between FOP concerns and the more diverse discussions about how to get FOP input from the various sources of text and graphics. The addition of the DITA group to the project might relieve(or redirect) some of that traffic. It will, at least, add quite a few people to the project who are used to dealing with the front-end requirements of creating the original DITA XML with editors, converting non-XML source text to XML and writing XSLT stylesheets, who can respond to questions that are more about documentation management than document construction. Ron -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: DITA-OT and FOP
On 26/03/2014 12:25 PM, Glenn Adams wrote: On Wed, Mar 26, 2014 at 10:14 AM, Ron Wheeler rwhee...@artifact-software.com mailto:rwhee...@artifact-software.com wrote: On 26/03/2014 11:46 AM, Glenn Adams wrote: On Wed, Mar 26, 2014 at 8:42 AM, Ron Wheeler rwhee...@artifact-software.com mailto:rwhee...@artifact-software.com wrote: The DITA-OT (DITA Open Toolkit) (http://www.ditaopentoolkit.org/) is an open source project that depends on FOP. It takes DITA (http://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture) XML input and produces a number of different document types. One of the main output types is PDF and it uses FOP to do this. It takes DITA input (xml) and produces an intermediate set of files that are processed by FOP to produce a PDF. It can also produce HTML There is a Maven plug-in to control the production in an IDE environment. It calls all the bits and pieces required to take the raw DITA XML files and output a document in PDF in the target folder. There is some interest in adding DITA-OT to the Apache family and in my opinion, the XMLGraphics group seems like a natural home and the FOP sub-project might be a good place for DITA-OT to reside. DITA-OT is a large community of users but a small community of developers. There are also a few enhancement ideas that would require FOP enhancements to complete. In addition, my own belief is that the FOP community could add some technical advice to the DITA-OT community that would be helpful. http://sourceforge.net/projects/dita-ot/ is the download page. DITA-OT is currently distributed under the Apache License V2.0. I am not one of the main players in the group but have taken on the task of seeing if there is a possibility of opening the discussion with the FOP group. Would there be any interest in considering adding front-end XML processing to the FOP production project? FOP already has a front-end XML processor. It's called XSLT. It is provided solely as a convenience function. Some of us have doubts about whether that was a good idea or not, since it tends to generate a lot of traffic unrelated to FOP's core function. Why do you want *more* front end processing and why isn't XSLT sufficient? More means a set of XSLT stylesheets that validates a standard language called DITA (Docbook supported as well) and transforms it to FOP input (or HTML). IMO, FOP should remain neutral to pre-FOP input formats. I'm one of those who would like to remove the XSLT front-end functions from FOP entirely, whereas you propose to take it further towards the pre-transformation XML domain. So, I would vote against such a proposal. You do raise a good point about the user group traffic and splitting the conversation between FOP concerns and the more diverse discussions about how to get FOP input from the various sources of text and graphics. The addition of the DITA group to the project might relieve(or redirect) some of that traffic. It will, at least, add quite a few people to the project who are used to dealing with the front-end requirements of creating the original DITA XML with editors, converting non-XML source text to XML and writing XSLT stylesheets, who can respond to questions that are more about documentation management than document construction. Ron I can certainly understand your concern about supporting the front-end activities but without a way to get FOP input, FOP is a niche product for software developers (my company's initial use for which we are grateful for the work that the FOP team has done). Can you suggest a solution that would integrate the current front-end support with the DITA group while still tightening the link between FOP and DITA? I think that the DITA-OT community is the largest user group for FOP. If you look at LinkedIn, the DITA awareness group has 552,722 members, the DITA for Small Teams has 64,551 members, DITA Metrics has 74,388. There are country-specific DITA groups with 15-20,000 members. The Tools for Change for Publishing has 3,175,059 members. DITA Machine Industry for technical docs for automotive and and machinery has 18,463 members. DITA-OT including FOP has been downloaded 344 times this week and over 4,100 times in the last 12 months. How does this compare to the direct downloads of FOP from the Apache mirrors? This represents a lot of opportunity to get support for FOP functionality improvements as well as consulting work for people who can configure/customize FOP to meet specific needs of corporate and government clients for internal and external documentation. It might be worth the pain
Re: DITA-OT and FOP
On 26/03/2014 2:14 PM, Christopher R. Maden wrote: Although I don’t get a vote, I completely agree with Glenn that DITA integration into FOP is completely inappropriate. Thanks for taking the time to comment. I appreciate the input - voting or not. I also challenge Ron’s assertion that DITA users are the biggest users of FOP; DocBook is way up there too, along with an uncountable number of other document types. You certainly have reason to challenge my assertion! I could not determine the number of downloads of FOP from Apache last week but FOP was downloaded 344 times last week as part of DITA-OT. There could be other ways to measure biggest user of FOP but I could not find any way to determine these. Is there some data from FOP about usage? DITA-OT does DocBook as well but I am not sure how many DITA-OT users are still working with DocBook. If the DITA team wants to turn ownership over to the Apache Foundation, I think that this would be the result and the current license is Apache V2. that’s one thing; there are several projects that coöperate with FOP (and some on which FOP depends), but they are not and should not be *part* of FOP. Part of the issue that I think needs to be addressed is the difficulty in using DITA-OT caused by missing FOP functionality. These are not getting fixed or even addressed for a number of reasons that relate to communication and probably resources where users of DITA-OT need FOP support but the people supporting DITA-OT don't have a connection to the FOP team and the end-user with the financial resources does not see the connection between FOP and DITA-OT. They just get told that DITA-OT can't do X because FOP can't support it - end of story. The lack of FOP consultants in the DITA-OT community also makes it difficult to get customization/configuration of FOP done. This makes it difficult to get nice looking output or dynamic creation of documentation on demand. “Tightening the link between FOP and DITA” is a bad thing. Separation of concerns makes semantic markup work and makes Free/Open Source Software work. DITA (and other good XML vocabularies) are all about describing information in a presentation-independent kind of way, and then applying one or more presentation specifications to produce output. The presentation layer should be separate. While many (most?) DITA users depend on FOP, not all do,[*] and there are certainly many FOP users who do not need to be saddled with DITA (or DocBook, or CALS, or TEI, or ...). I would not suggest that the code be integrated but it would be nice to have a single group that can say. if you want to support X in DITA-OT for PDF output, then you to add Y to DITA-OT and Z to FOP and these can be done through the release of FOP version zzz and version yyy of DITA-OT. One alternative would be to fork FOP and do the extensions of FOP in the DITA-OT group but that is not anyone's preference There are alternatives to processing DITA. FOP is not used in DITA-OT for HTML or OOxml or rtf output. I am not sure how many of the alternative DITA processors have forked the Apache FOP base and integrated it into the programs. It certainly would give one a head start on building a proprietary DITA to PDF process and would likely have a lot of bits and pieces that one could use for other XML output. I think that there is a lot of expertise in the XMLGraphics group that could make a big difference in the usefulness and functionality of DITA-OT just by commenting on the internal processes and reviewing the enhancement plans. ~Chris [*] My entire experience with DITA has been around an MS-Word-centric publication system, going into and out of Office Open XML, with no XSL in sight. -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: DITA-OT and FOP
On 26/03/2014 2:59 PM, Jan Tosovsky wrote: On 2014-03-26 Christopher R. Maden wrote: Although I don’t get a vote, I completely agree with Glenn that DITA integration into FOP is completely inappropriate. +1 FOP consumes standardized XSL-FO. DITA-OT should produce standardized XSL-FO. Period ;-) It does but FOP does not support all PDF features so some of the things that people can express in DITA's XML can not produce the PDF output that people want/need. From my POV it has nothing to do with FOP, it is rather XSLT (or whatever) part. But I agree FOP could be enhanced to be more conformant to the standard. It requires engaging developers and sponsors. I would hope that engaging the DITA community that has the need and the resources will get the support for these features. The separation into tool-making and document making communities makes it harder for the tool guys to get funded or staffed. The document makers don't have the knowhow to fix the tools. There is a lot of potential locked up in the current situation. Some ideas appear in this mailing list from time to time. The DITA community has not been very good at pestering the FOP team to get things fixed. They have tended to accept that FOP is static and can not respond to the needs of the document makers. Jan -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
