On Sat, 10 Dec 2011, Stuart Rackham wrote:
On 10/12/11 05:17, Dag Wieers wrote:
Hi,
It's clear that ODF support will not be part of AsciiDoc. Which, if you
had told
me from the start, would probably have not motivated me to write the ODF
backend, but I am at a point of no return now... Well played ;-)
There was no intention to mislead, my desire to keep new filters (and by
extension backends) out of the AsciiDoc distribution was no secret, but maybe
I should have been more explicit:
http://groups.google.com/group/asciidoc/browse_thread/thread/40c64cd33ee1905c/578e9469fbaf5
The primary motivation for the plugin architecture was to enable filters and
backends to be implemented as plugins. The idea is to decouple the AsciiDoc
core from backends and filters.
The HTML and DocBook backends (and successors) will stay in the core
distribution but I envisage that all new backends will be implemented as
plugins. From a maintenance standpoint it's the only sane way forward.
The ODF backend is a great use-case for the plugin architecture -- if we can
get it working as a plugin then almost any XML/SGML backend should be
possible.
But I am concerned that an output backend may never become really popular
(or
even known) if it is not mentioned in the User Guide as prominently as the
other
output backends (eg. in the list of attributes each backend supports
etc...).
And I wouldn't be the author if I wasn't convinced about the potential the
ODF
backend brings to AsciiDoc.
So is there something we can do to promote backends more/better in a
future
release ?
You've got a point, section 4 of the manual needs to draw the readers
attention to the plugins webpage
(http://www.methods.co.nz/asciidoc/plugins.html) and any other locations in
the manual and website that discuss backends.
Personally I'd like to push the slidy and wordpress plugins along with all
filters (with the exception of the source filter) out of the core, but that
would probably raise a backward incompatibility hue and cry.
I'm not sure that popularity is all it's cracked up to be, one of the nice
things about AsciiDoc is that it flies under the radar -- users are generally
motivated discerning types that know what they're looking for, consequently
the mailing list is relatively low noise.
Also, I plan to release the ODF backend (as-is) when the next AsciiDoc
version
is ready. Even if not everything works exactly as I want, I hope a wider
availability might bring more people to this project to help adding more
themes
or finish the backend.
With your permission I'll cite the ODF backend prominently in the next
release announcement. All that's holding back the next AsciiDoc release are:
any ODF show-stoppers; finalizing and implementing the comment/annotation
syntax; the documentation changes discussed above;
and I need to read the 'Sections with multiple columns' thread.
Too late ! Already implemented ;-) But your advise is very welcome
nevertheless...
Currently I do it like this:
[columns,2]
====
body
====
Which works for the intended purpose, and the stylesheet is more simple
than my example. You don't have to specify the weight of each column if
you want them to be proportional (and honestly, who wouldn't want that
anyway). But the stylesheet allows any customization nevertheless.
Now I am going to start implementing the new comment/annotation proposal.
Using a comment-block instead of a listingblock !
--
-- dag wieers, [email protected], http://dag.wieers.com/
-- dagit linux solutions, [email protected], http://dagit.net/
[Any errors in spelling, tact or fact are transmission errors]
--
You received this message because you are subscribed to the Google Groups
"asciidoc" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/asciidoc?hl=en.
