On 10/12/11 11:50, Lex Trotman wrote:
On Sat, Dec 10, 2011 at 3:17 AM, Dag Wieers<[email protected]> 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 ;-)
I think you give too much credit for pre-planning :)
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.
As asciidoc only just supports plugin backends (and a2x plugins next
release) its not surprising that the documentation doesn't say much
about them. Especially as there are no mature full service plugin
backends yet (all so far are for specialised uses).
If there are places where the documentation should better address
plugin backends then changes should be proposed to Stuart. But
expanding the manual to cover each backend that goes on the plugins
page just isn't viable. Each plugin should have its own manual
addressing the differences from asciidoc/a2x
For ODT, the only documentation available is the readme file.
So is there something we can do to promote backends more/better in a future
release ?
Well if you think it is mature enough then it should be proposed to
Stuart that it be added to the plugins page on the website, even if
marked as in-development. But it needs a proper manual, see the slidy
backend for example.
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.
Putting it on the website should get more bugs to fix :) I don't know
about more help. To quote some bloke who knows a thing or two about
open source software (Linus Torvolds) "when you release open source
software you have to assume you will be doing all the work yourself,
and be prepared for that". Only in the longer term will you get more
contributors. (maybe I souldn't have pointed that out :)
Great quote, certainly echoes my experience.
It should be clear however that format style (names), attributes and
constructs may still change when we improve the functionality. (eg. the book
doctype currently hardcodes a lot of how the cover looks, which we might
influence through attributes instead)
Well, such comments mark the backend as immature and discourage users,
so it won't get tested so much.
So you need to decide on backward compatibility or other means to
support users' existing documents. Adding extra capabilities like
adjustable cover pages is fine, but it should still support any
existing files.
As the asciidoc project is not supporting the ODT backend it is better
from a purely practiacal point of view for it to remain a separate
entity (on github, or wherever) so that it can be accessed by us,
especially whilst still in heavy development.
For something like the ODT backend to be included in the standard
asciidoc distribution it needs to be far more mature than it is now,
it needs to be properly documented and it needs to have a sufficient
user base that Stuart is convinced it is worth it.
The available maintainer effort for asciidoc is small, so the project
taking on an immature backend is going to use all those resources,
preventing work on other parts of asciidoc. Thats why I am
emphasising maturity, there should not be big changes and lots of bugs
if it is to be considered to be included as part of the asciidoc
project.
As no popular "full service" backend plugin exists, the possibility of
packaging such plugins with the asciidoc distribution has not been
considered yet.
That stage is a long way away IMHO, making comments that "it will
never be part of asciidoc" is way premature at the moment.
I agree with all this Lex.
I'm not saying that non-HTML and DocBook will never be in the core, just that
this is the current position.
I guess the problem is how to ensure backend plugins are prominently visible and
are not seen as second class citizens. As well as raising user awareness in the
documentation they also have to be painless to install and uninstall -- maybe
the backend option should accept a URL as well as a file name e.g.
asciidoc --backend install
https://github.com/downloads/srackham/asciidoc-fossil-backend/fossil.zip
Cheers, Stuart
Cheers
Lex
PS the comments above are my own and have not been discussed or
endorsed by Stuart.
--
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.
