Hi Dag, Answering two posts in one since they are related, sorry if the quoting is wrong as a result.
[...] > > > 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. Once the ODT backend is in the wild the way the backend works is not going to be able to be arbitrarliy changed anyway, it will upset the XML stylists just as much if the backend no longer works with their XML files. So from release, changes to the generated entities and style names is going to have to be controlled and managed with "breaking" and "non-breaking " releases. You need to qualify your comment that end users don't want to fiddle with styles, they don't want to fiddle with *XML* styles, but as questions here show, they often still want to tweak their styles. [...] > > 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. > Only for your use-case :) > > >>>> 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) > You are understood :) , and as I said above, after release this needs to be managed in a professional manner for both ODT and XML styles, arbitary changes must be controlled. > > [...] > > 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. Just to repeat myself :) neither will a power users XML styles file, its not an ODT specific problem. So you are saying that the backend is not stable enough for anyone to use, especially corporate power users who are your target, so we need to sort that out first. > > 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. What problems are *specific* to OTT styles? > > 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, > ...) > Yes, tap any brains you can. > > >> >> 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. I'm not trying to divide users. I guess you are meaning making a package from the standard styles instead of an FODT? In which case you should have an OTT with those styles available as I said above, and then the normal a2x ODT options apply. In fact isn't that what the makefile is doing? 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. > Sorry don't, clearly we fundamentally disagree on that :) [...] > > Is it ? Why do I have a minimal-odf unzipped in Git ? Because checking in > the OTT makes absolutely no sense. > Because you have it in the makefile isn't a reason :) Can you provide some explanation why it does not make sense? [...] > > 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. > No it isn't see below. > > >> 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. No they are not, they are in Pictures directory and referenced from styles.xml. Maybe I confused the issue by calling them icons, I mean things like the images for list buttons, background images etc. all are referenced from styles.xml and need to be copied into the package being created. So we need to copy *all* of the OTT file to ensure we have all the resources that the styles use, or we have to parse the styles.xml file to find which ones to copy. Whilst Python has some good tools for parsing XML its still a lot more effort than just copying everything. And if we are copying everything (except content.xml) then it is the same as what I am doing at the moment. [...] > On Fri, 17 Feb 2012, Lex Trotman wrote: > > [...] > > 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. > > > Ok, let me explain the various facets of the ODF backend. > > - Styling in LibreOffice is a compelling reason for end-users compared to > LaTeX or DocBook > Yes > - Being able to collaborate on files (AsciiDoc) _and_ the ability to > generate DOC and PPT files is a compelling reason for a > lot of organizations, who cannot use LaTeX or DocBook (because it has > to produce DOC and PPT that are then used/edited by sales-organizations) > Yes > - Being able to collaborate on styles and improving styles in XML is not > an issues for large organizations, they have the skills and they *will* > prefer the possibilities of doing that on XML files. This is different > from XSLT btw, which is much harder than modifying a color, a > font-size, etc... I am talking here about IT companies, governments, > etc... ODF XML stylesheets can be compared to CSS stylesheets, rather > than XSLT. Hmmm, my experience is that the people capable of doing XML are not in the styling department, they are elsewhere doing other work so this si an additional load they usually don't want :) > > - BTW I foresee that some organizations will even modify the ODT backend > to make it do more advanced stuff that is impossible to do with ODF > styles/LibreOffice. > That is their choice. > Now considering that the ODT output is not finalized and might radically > change in the coming months, maybe even until 2013 depending on how this > project evolves, it will > break LibreOffice styled documents and XML styles. Yes *both* > For those people that do styles in XML it will be very easy to fix those > changes in the stylesheets. For people using the LibreOffice interface, not > so much. Once a style has been renamed, used in a different way, etc... You > have to start from scratch, even worse, you have no example style if you used > the old working style, the styles have disappeard. So you cannot simply edit > an existing style, and you cannot add a style that automatically applies to a > previous construct. It does not work like that. Clearly you have more trouble using LO styles than I do, if a style is renamed in the backend then the user just has to rename it in his existing ott file, not start from scratch. They will grumble, but so will the people furiously editing XML to keep up with us. As I said above radical changes are going to have to be professionally managed from release on to avoid annoying all types of users. > So the most important selling point (styling in LibreOffice) will not be > practically usable until the ODT output has been finalized and written into > stone. Again, *both* XML and ott will break. > But we won't finalize the ODT output if there is no compelling reason for me > to use it. And there won't be a compelling reason for me to use it, if it's > not immediately practical useful. And (again) ODT styles will not be > practically useful for a long time. And I (and others) can only work on this > if I can sell this solution to projects that see a benefit in using it. Only > if it is immediately useful, despite shortcomings (e.g. the ODT output might > change). By this argument their is no reason for Stuart or I to be doing anything on this backend. > So XML stylesheets is the only way I (and hopefully others) can work on this > during business hours, because it's the only practical solution while the ODT > output evolves. If I had known you were being paid to work on it I would have been *much* more demanding, you have been warned. :) It is good that the company is willing to do this as open source, but if they want support and assistance of the community they need to support the use-cases of *all* of the community, not just the ones they are interested in. Oracle is slowly finding this out. > In fact, once we have the most practical mapping from DocBook to ODT, someone > with XSLT skills will have a much easier time to recreate an XSLT that will > do just that. The docbook2odf project had multiple issues, and the most > important one was that there was no proper process to document the ODF > constructs. Where did mapping docbook to ODT come in? If thats the way you want to do it then you should be working on that and not wasting the time of Stuart, me and the asciidoc community integrating a backend you intend to replace? > 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). > Take the example README.txt and asciidoc-odt-test.txt, create a, fodt and an > odt, then open both and look at the difference. (You may first have to fix > the a2x backend, because it gives a backtrace with image) If you are getting a backtrace then file an issue including the backtrace and it might get fixed, it won't if I don't know about it. > Those are the issues we have to fix. > But to end this conversation: > Somehow in the whole discussion it appears that I am against using ODT > styles, and that is definitely _not_ the case. My point is simply that before > we have an acceptable solution that works for the intended use-case, we have > to make sure development can continue using XML stylesheets, and that the > workflow already works for basic documents so people can work on it during > business hours. As I said above, if you want support of the asciidoc community you also need to support their use-cases as well. Probably we should have discussed the process and intentions further at the beginning, my fault. Now that your use-case is clear and (I hope) the use case I am interested in is clear, we should be able to build a way forward that meets the needs of both. > And even with XML stylesheets, when talking to various people and showing off > the examples in the project (e.g. README.txt and asciidoc-odt-test.txt using > the hp theme, with proper fonts and hp cover-art) it's obvious people are > interested to start using it. We simply have to make sure we make it clear > that ODT stylesheets is not a short-term option. (And not just because the > current implementation fails) And if its not supported then it doesn't meet the use-case I am interested in. Cheers Lex -- 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.
