On 26/03/2014 12:25 PM, Glenn Adams wrote:
On Wed, Mar 26, 2014 at 10:14 AM, Ron Wheeler
<[email protected]
<mailto:[email protected]>> wrote:
On 26/03/2014 11:46 AM, Glenn Adams wrote:
On Wed, Mar 26, 2014 at 8:42 AM, Ron Wheeler
<[email protected]
<mailto:[email protected]>> 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 to build a closer relationship with the major
end-user community of FOP.
Ron
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
