The key is building a workflow... have writers work on their own chapters and make a test build before uploading their changes. Those writers do not even need the final stylesheets to test their content, but just enough to verify that the content is valid. If they use something like Sublime Text then the test build can be just a key click away. Leave someone else focus on the output formats. If you want multiple chapters with a nice table of contents, bibliography, index and glossary, DocBook is the way to go. You can also make good PDF output ready for self-publishing.
Customizations for DocBook are well documented but check out http://www.sagehill.net/docbookxsl/ for some great examples and guides. I've put an example set of everything I use to output various formats at https://github.com/shawngiese/mydocs . There are also some PDF customizations that I have found useful. On Thursday, March 27, 2014 2:08:11 AM UTC+1, Olivier Bilodeau wrote: > > I would like to chime in to say that I also find it a bit sad that the > default docbook (through fop) looks detached from the html output generated > by asciidoc. External links don't even look the same. With URL in brackets > after the text and no underline. > > Also a saddening fact for people who would like to publish in multiple > format is that customizing docbook is very hard in itself even after all > the effort they did to allow it to be configurable/extensible. The learning > curve is steep. > > I've been through this before with PacketFence[1]. Custom frontpage (and > building its xsl from xml), custom fonts, overriding standard docbook xsl > and configuring several of docbook's standard parameters. A lot of time was > spent on this only to have a decent looking but far from perfect PDF. If > there could be a CSS for docbook (and a one-pass javascript to style the > xml maybe?) it would be joy. The fact that there is no solution that I'm > aware of to do code listing syntax highlighting in fop+docbook shows how > hard that would be to do in XSLT. > > At my new $work, I've convinced people to use asciidoc+git for its > plaintext/use-your-editor/nicely-looking-html features but the last stretch > to the PDF is done by a designer with proprietary software. It comes with > all the copy and paste errors and forgot to re-apply style errors you can > imagine. For long documents the proof-reading is really a burden. > > The fact that asciidoc is "only the first-pass" means that everyone is > duplicating effort on their end trying to make things look good and, I'm > betting, often failing at it. What is O'Reilly doing? What are professional > publishers doing? What is RedHat doing (their Java business is probably > full of asciidoc)? > > Even if the answer is they finish their last pass with a designer with > proprietary software, my question would be: How do you get the basic markup > through (bold, italics, fixed-width, code blocks, non-breaking characters, > etc.) into that last step? > > I LOVE asciidoc (do everything in it) but I would like to see a better PDF > publishing story to it. > > Cheers > > [1]: https://github.com/inverse-inc/packetfence/tree/stable/docs > -- You received this message because you are subscribed to the Google Groups "asciidoc" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/asciidoc. For more options, visit https://groups.google.com/d/optout.
