[...]
>>
>> Because at this point in time, working with ODT files does not work,
>
>
> Why? I thought this was the big win that you got with ODF.
>

Due to circumstances, generating ODT hasn't had the work that FODT has
(and Dag should be highly commended for that) but I am not sure that
it plain "does not work".  If thats the case please let me know (with
examples).

>
>
>> will not
>> help get people involved and makes it a lot harder to style _and_ asciidoc
>> cannot work with ODT files natively, it never will.
>
>
> No, but it's a moot point -- apart from the ODF plugin developers, my guess
> is that virtually no one will use asciidoc directly for ODF they'll use a2x
> because:
>
> 1. .odt are prefered over .fodt
> 2. Users will prefer styling interactively using Libre/Open Office.
>
>
>
>>
>> (Modifying styles in LibreOffice rewrites the whole file, moves stuff
>> around,
>> adds stuff that's not needed, etc... While it's should work fine for
>> simple
>> stuff, for professional use, eg. themes, this is not a proper solution.
>> You
>> cannot track changes, and not only because it is inside a ZIP file)
>>
>> So it's very very simple:
>>
>> asciidoc --theme <name> uses XML styles, <name>.odt.styles
>> a2x --theme <name> uses XML styles, <name>.odt.styles
>> a2x --style-doc <file.odt> uses ODT/OTT styles, <file.odt>
>>
>> Apart from that we need to learn a2x to create its own ODT files from
>> scratch
>> (we know now what is needed) and to merge it with an existing ODT/OTT (has
>> issues now too).
>
>
> I need some time to think this stuff through. Actually I was thinking of
> dog-fooding this whole extended backend plugins thing by separating epub
> into a backend plugin.

I think things that are specific to particular backends should not be
hardwired into a2x (eg style-doc).  Unfortunately there is no way
(that I know of [1] ) that a backend can add extra options to a2x
since a2x has to have already parsed the options to find the -b to get
the backend.  So these options need to be "backend-opts" options.  Its
a clumsy syntax I know, but comparable with "xslt-opts" etc.

Themes is however an interesting one to combine with different
backends, since different backends can use different mechanisms (and
even different toolchains for the same docbook), it looks like the
themes directories might have to be sub divided in some way.  Note
that there is actually no reason why users who have made a nice OTT
file would not want to distribute it as a theme, but that gives the
odt backend two mechanisms, like the docbook one I guess (dblatex and
fop).

Which as you say gives one to think a bit regarding a simple elegant
flexible solution.

Cheers
Lex

>
> The ODF progress to date is impressive, I'm just keen not to create any
> millstones, unnecessary complexity or evolutionary dead ends.
>

[1] that is I don't know of any method using optparse, argparse has
several ways it could be done, but its a Python 2.7 and up module (and
I for one am still using 2.6)
>
> Cheers, Stuart
>
>
>>
>> Kind regards,
>
>
> --
> 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.
>

-- 
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.

Reply via email to