[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 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! |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]