[...] Hi Dag,
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. > > 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? > > > >> 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. > > > >> 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 :) > 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. > 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? > > (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. > > 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? 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. Cheers Lex > > Kind regards, > > -- > -- 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. > -- 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.
