On Fri, 17 Feb 2012, Lex Trotman wrote:
This has me confused where you are heading, see comments below.
My guess is that very few users will want to deal with .fodt files
directly, preferring .odt files instead i.e. a2x will be used in preference
to asciidoc.
Correct, but it makes no sense to distribute themes as ODT files IMO. And
the most important reason for not doing styles as an ODT is that it sucks to
develop themes together with improving the backend.
I am not sure I understand this comment, users are not going to be
developing the backend.
Let's divide the future users in groups:
- those that create themes for an organisation
- those that use predefined themes in an organization
- those that modify ODF files to use as themes
My focus and priority is the first and second group now. The third group
is mostly end-users that want to tweak and don't care about messing with
the styles themselves. But I doubt we're going to target the third group
very soon because as long as we modify the different structures in ODF one
cannot depend on styles to still work.
So in my opinion, people can use ODF and ODT files including them on the
commandline, but asciidoc --theme falls back to XML stylesheets so that they
work for both flat XML ODF files as well as packaged ODF files.
And a2x falls back to ODF/ODT files, but can use XML stylesheets too.
I don't follow the argument either, if you use a2x with --backend odt
you will get a packaged file using an ODT? You don't need to use a2x
to get a flat file?
Again, for the first and second group of users, templates are of no
importance. But creating an ODT files using a theme (.styles) is what
(during development) is of essence.
Taking up Lex's point, I think the vast majority of users would want to
style with ott templates and not .styles files. The ability to style using
interactively generated ott files was the raison d'être for an ODF backend
in the first place.
Sure, but they will open and save modified files, and as such these are not
distributed themes. Any professional styler will prefer XML files over
packaged ODT files.
I would have to disagree, stylers are not good at XML, and XMLers are
*not* good at styling :-D.
And LibreOffice is not good at creating manageable styles. And as long as
the backend is changing, the ODT files are worth shit. (sorry for the
language, but I feel I am not being understood)
So why complicate things with .styles themes plugins? Instead ship any
built-in .styles files with the odt plugin and make an asciidoc '-a
odf-styles=path' attribute available for those users who want to use their
own .styles files.
Because at this point in time, working with ODT files does not work, will
Yes, we need to improve ODT file generation, but just because they
don't work today isn't a reason to decide to avoid them, FODTs didn't
work several months ago either :)
No, ODT files will never work well if the backend has not settled yet. And
we won't gain any satisfied users if we target the third group today. So
we have to focus and accomodate the first and second group today.
I'd like to have proper ODT generation to work with *both* .styles and OTT
files, but you have to trust me that OTT files do not work properly for
the foreseeing future. There are too many issues with the stuff the
backend generates that still need to be fixed.
And I hope to be able to discuss some of those on the ODF plugfest with
ODF experts that understand the benefits and consequences of some of the
elements we use today. (e.g. using <text:section> for admonitions work
great, except you cannot have borders, <text:para> does not allow nesting,
...)
not help get people involved and makes it a lot harder to style _and_
I think having ODT styling working will get *more* people involved
compared to yet another XML styled backend, for that you would be
better advised to use the more mature FOP.
Again, ODT styling is not something that will work tomorrow. In fact, if
it would work tomorrow, if will fail next week.
asciidoc cannot work with ODT files natively, it never will.
I also don't understand your argument, asciidoc doesn't natively work
with PDF files or epubs or many other final formats?
Sorry, I meant ODT and OTT files for styling purposes. So the moment you
do not allow a2x to work with XML stylesheets you are dividing asciidoc
users and a2x users. While the people creating proper styles for
organizations are going to do that by using a text editor, and not
LibreOffice. Trust me on that, or gain some experience to understand the
issues involved.
(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)
You can still version control the ODT file, and OO/LO can track
changes so you can see what you changed. No different to version
controlling files from GUI builders or any other such tool.
Is it ? Why do I have a minimal-odf unzipped in Git ? Because checking in
the OTT makes absolutely no sense.
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).
Not sure why we *have* to create them from scratch? You already have
a makefile that creates a minimal style doc using the fodt styles
file. Why repeat that code in the python code? It should not be a
problem doing it (hopefully), but I don't see why you want to?
Because you are not ending up with the cruft that LibreOffice generates
from the styles and you gain the ability to support XML stylesheets _and_
ODT/OTT style support. Doing it in the a2x backend really is _very_ basic.
Using an existing ODT as the base means that we don't have to scan the
styles for any resources they use (eg icons) to make sure we copy
them, all such requirements are already met. We only have to scan the
new contents and copy its resources (and it has convenient comments
telling us what to copy). Sure we could remove some more unwanted
stuff, but thats an ongoing development.
Icons are not referenced in the style, they are in the content.xml. One of
the limitations of ODF.
--
-- 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.
