Re: [xsl] XSLT workflow: ODF <-> XPP

Subject: Re: [xsl] XSLT workflow: ODF <-> XPP
From: Martynas Jusevicius <martynas.jusevicius@xxxxxxxxx>
Date: Thu, 28 May 2009 02:42:51 +0200
Hey Matthew,

Unfortunately it is. XPP is their main publishing software, its use
predating XML itself.
They need advanced publishing features and high-quality PDF output, so
changing that is almost certainly out of the question.
Even though I would like to use something like Prince XML instead...

P.S. Familiar sounding Lithuanian last name :)


On Thu, May 28, 2009 at 2:27 AM, Matthew L. Avizinis <mla@xxxxxxxxx> wrote:
> Hello Martynas,
> I may be going out on a limb to ask this, but is it necessary to have
> XPP in the process at all?
> For instance, since the source is ODF why not use the OpenOffice pdf
> print functions or the PDFCreator printer driver to create pdf files?
> Then you wouldn't need XSLT at all and save a few steps.  It's difficult
> to say without knowing more about the whole process.  At any rate, I've
> used ODF as source material and used the OpenOffice internal xslt
> processor to transform documents into other xml formats than those
> already available as OOo output formats.
> Peace,
> Matthew Avizinis
> Gleim Publications, Inc.
> Martynas Jusevicius wrote:
>> Hey list,
>> this is more of a general question about XSLT workflow than a specific
>> task or technique.
>> I'm helping out with XML at one publishing house. They are using ODF
>> (OpenDocument) as a manuscript source format (received from customers)
>> and XPP (XML Professional Publisher) as their internal format, on
>> which they later add some specific XPP markup to style books (and
>> later produce PDFs).
>> The problem is, that the two formats are not interchangeable, and this
>> breaks the whole workflow. They have a filter to import ODF to XPP
>> (the easy part). They also have another to convert back from XPP to
>> ODF, but it discards XPP processing instructions that were added while
>> styling. That means a roundtrip is not possible, because the existing
>> inline XPP styling would be lost.
>> However both file formats are necessary, because they are using ODF to
>> transform to XHTML and ePub, and XPP to produce PDF.
>> The files also need to be up-to-date and synchronized, which currently
>> is not the case. If the customer wants to make changes to the
>> manuscript, it cannot be reimported. On the other hand, corrections
>> can also be made in XPP.
>> The transformations are currently done using Perl, but I'm thinking
>> about converting the whole workflow to XSLT.
>> I see XPP as the source of the problem, because of its inline styling
>> and use of processing instructions. I don't know the system so well,
>> but maybe it would be possible to somehow separate content from
>> presentation there, in a similar fashion as with XHTML and CSS. Then
>> it might be possible to do ODF-XPP-ODF conversions on the content
>> only, while the styling would remain in XPP. But that would also mean
>> changing the way they style, and would need to base it more on IDs and
>> classes, which I'm not sure if it is possible to retain (and prevent
>> from removing) in OpenOffice.
>> And taking it one step further, if that would be solved, the customer
>> and the publisher would still need to work on the same ODF file
>> sometimes. Maybe some version control could help? Or is it crazy to
>> think about manuscripts as source code?
>> Any experience/advice with something like that? Appreciated in advanced.
>> Martynas

Current Thread