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:
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
sure...).
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!
