OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [docbook-apps] DocBook and InDesign

Hi all

As a newb to DocBook (I run a small publishing house looking into moving over to DocBook) one of the services I'd like to be able to offer our customers (who are mainly academic researchers), is the possibility of putting together collections of articles / chapters from any of our content (via a simple search and drag and drop web app) and having it auto-typeset, and transformed for consumption on a variety of mobile devices, as well as the possibility of ordering a print version of the user-defined collection - the Expresso book printer makes this possibility realizable.  In order to build this service I recognize that the formatting would have to be standardized to some extent, and would undoubtedly not be 'perfect'.  The current XSL-FO transformation probably has sufficient complexity to enable me to build this service and for the resulting products to be 'good enough'.  However, at the same time, we have used InDesign since the inception of my publishing company (Emergent Publications), and so having even a limited roundtripping capability between InDesign and DocBook would enable us to utilize our existing InDesign knowledge and investment.  We are not into producing glossy magazines or very complex textbook-like presentations, so our formatting requirements are likely far more lax than many other publishers... but it is the flexibility I want t offer to our customers, and if the cost of that is sub-optimal formatting, then fine.

Kind regards, Kurt

On 6/16/2010 2:55 PM, Giuseppe Bonelli wrote:
AANLkTiknRwTEGwjk2NNq42Cb0opMVpeCsycdewUSHg2-@mail.gmail.com" type="cite">
in the user cases some of us need to address, the tweaks applied in
InDesign get lost when/if you go back to docbook.

The idea is to use InDesign just as the composition engine to leverage
its strengths (interactivity, very precise typography and widespread
adoption in some environments). We may need to come back to docbook,
right after the pdf are ready to be printed, but just to update the
content that may have changed (due to text copy fitted to the layout,
for example).

In an ideal scenario, those tweaks would be purely paper-presentation
oriented and, as such, they do not have home in the docbook sources.
As a matter of fact, they do not have home in the ICML files either,
as all the formatting information is contained in a separate inDesign
native template file.

It seems to me that this scenario is not very different from the one
we are used to when we batch-compose our pages with FO: if we need to
compose again a pdf, we need the docbook files *and* the XSLT used to
generate the fo output (and, by the way, the formatter and the XSLT
engine used to compose the pdf in the first place, just to be

I agree with you that this scenario is far from perfect (and probably
Keith is right when raising general concerns on the whole idea of
rountripping), but  it seems to me that a DB-InDesign roundripping
solution, less than perfect as it might be, could be very useful in
fostering the adoption of docbook based production workflows in
environment where the use of interactive composition engines is the
norm since many years, but, at the same time, the need of cross media
publishing is raising day after day.

My experience, admittedly with medium and small traditional publisher,
is that we have to have an evolutionary approach in introducing new
processes rather than a revolutionary one. For many organizations, the
switch towards a batch-composition paradigm would be a *big*
revolution indeed.

Please, don't be afraid to point out any weak point you may see the
blueprint we are trying to sketch!

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]