Tom Browder wrote: > That's why I'm immersed in DB--dual output. I've tried ConTeXt but > decided not to go that route for my current project. And I certainly > agree, in general, I shouldn't be making local design decisions, but > sometimes, when under time pressure, it's the only way to go (I know, > I know the downside, too).
Unfortunately, the design philosophy of DocBook is at odds with local design decisions. It is kind of like trying to use an assembly line to create a single custom part; theoretically possible, but difficult. Even to enable local formatting overrides is a much bigger question than may be initially evident. DocBook predates XSL, and has outlived many previous formatting tools as well. So how should formatting overrides work? Should DocBook have its own formatting vocabulary? Or should the DocBook tool chains favor specific formatting languages? In your case, it seems like adding support for XSL-specific processing instructions might be the way to go: <para><?tb:fo text-indent="0pt"?>This paragraph doesn’t indent.</para> You could extend DocBook to allow global attributes from XSL, too: <para fo:text-indent="0pt">This paragraph doesn’t indent.</para> and pass those through. But I would really object to building that functionality into the core DocBook stylesheets. ~Chris -- Chris Maden, text nerd <URL: http://crism.maden.org/ > “I like being free, and that makes me an idiot, I suppose.” — Stan Rogers, “The Idiot” GnuPG Fingerprint: C6E4 E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319 --------------------------------------------------------------------- To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-h...@lists.oasis-open.org
