[...] > > Agreed. Once we considered a stable release ! At the moment, with so many > uncertainties I don't want to have such a release-process in place. We > should have the flexibility to modify what exists. > > I should make an important remark on the website for this ! >
Yes, it should clearly state that it is in development and you are *only* looking for development help. [...] > > I hope I am not going to be solitary for too long... > Maybe, but if we tell the truth in the notice above you probably rule out many corporate users at this point, can't win :) > > [...] >> 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. > > > Agreed. > > But the difference between XSLT (programming in XML, yuck) and XML styles > (much more like css) is an important difference too. I wanted to get away > from XSLT, not necessarily "CSS" when I started the ODF backend. > Its all XMhell to me :) > > > >> [...] >> 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. > > > Indeed, and I lack the proper ODF knowledge to make good decisions. I have But you are learning :) > been changing some of the constructs a few times without confidence :-/ In > many cases there is no perfect implementation, so it's essential that we > define what we deem important and document what limitations we have. > Yes, agree, the limitations should be documented and which areas are (slightly) more stable. This is of course more important now in early stages than it (hopefully) will be later. > For example, if we implement admonitions using ODF sections, we have a > working implement that can be styled (almost completely) from styles (1 or 2 > columns), but we can not have borders as sections do not provide border > styles. If we use tables, it is impossible to style the admonition from XML > styles and the icon-width is fixed inside the ODT backend. etc... > > Maybe the documentation should be part of the backend so decisions are > documented, I don't know. > Maybe add a HACKING file and have a "design approaches" there, including things that *didn't* work so people don't try them again unless they think we did it wrong. [...] >> What problems are *specific* to OTT styles? > > > The lack of metadata, the mismatch of styles, the fact that we have to have Ok, as I said, if we wrap the metadata in a comment for packaged ODF it can be extracted and written to meta.xml. You're the styles expert, why are they different? I presume if you open an FODT and save it as a package the styles are preserved, so what is different about the OTT made by the makefile? Since the Python won't do anything different it can be debugged as is. > one generated in the distribution (for the default case) and the fact that As I said doing the same as the makefile in Python isn't hard, but won't work any better than the makefile does. > the current implementation fails for an obscure (to me) reason :) > And I'm still waiting for an issue to be raised that includes the backtrace, error message or symptoms of that failure so I can look at it (unless I have missed such an issue, in which case call me blind, but tell me the number :) [...] > > Yes, but I don't want to depend on the Makefile for a default stylesheet. I > know that your prefered use-case is to use (modified) OTT files, but my > prefered use-case is to use XML styles (and themes currently are XML > stylesheets). So a2x should be able to create a packaged ODT file from > scratch (using the default XML stylesheet, or an XML theme). > > That's my use-case ! Ok, that can be added, just make the styles work :) > > > >>> 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 :) > > > Time will tell. > > Just the fact that table styles are impossible to define inside LibreOffice > or OpenOffice (there is simply no GUI for it), while they can be done in ODF > makes LibreOffice useless for table styles (unless you go for one of the > built-in styles). > Thats because they (LO at least) don't use table styles, they apply styles to each cell. Thats how they support those colourful tables with different backgrounds in each row and column. Does it use them on import? I would have thought that odt.conf needs to generate the same per cell styles? > > >> [...] >>> >>> >>> 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 for every modification, Git will have to store a whole new binary. > So there's basically no versioning. It's like checking in a Word document, > sure you can store different versions, but you cannot track changes, and it > consumes a hell of a lot of space. > An empty ott is only a few kilobytes. > That's why working on XML stylesheets within a company makes more sense, > than modifying ODT files and sharing them in Github. > I guess we agree to disagree again :) > > >>>> 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. > > > But if your OTT file has other images included, which are no longer > referenced in your new document, you will copy them with you. So imagine you > have 10 iterations of your document and you pipe them through LibreOffice to > modify the styles. If some of these moderations have images added and > removed, the resulting ODT/OTT will have the sum of all images included. That will only happen if you use documents with content as OTT files. If you have a style with an image, the image is deleted if you delete it from the style. If you don't delete it (or the style) then it is still needed and so must be copied. > > So in my opinion images are part of the content, and not part of the styles > and even that part needs to be regenerated rather than merged. Well, you will have to tell Oasis, since they specified several style attributes that involve images :) > > Regardless of how I would prefer, or expect it to work, that's a limitation. > I don't get that, you seem to be saying that you don't think any style should be able to contain an image, but that doesn't make sense. > > >> [...] >> 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 :) > > > Ok, maybe I was not clear on this part. But I made already 2 styles for > myself (and the company I work for). The styles that I made are a copy of > existing styles from existing PDF documents that I liked. I just > reimplemented them by modifying the fonts, colors, alignment, spacing, > margins, admonitions, etc... But at this stage you are an XML expert. > > These are quite trivial to do by taking the default stylesheet and working > on that. Sure I am not a graphical designer, but I can do that. And the > people that are interested in the ODT backend in my opinion are system > administrators, developers and technical people that would like to deliver > something professionally looking, without the need to program in XSLT. Completely disagree with that, the majority of people that will be interested in the ODF backend will be people who need the ability to create styles without XMhell. They will *far* outnumber the few big companies that can do XML styling. > > Sure, the LibreOffice interface is nice, and that's definitely a plus. But I > wouldn't bet on that only, especially not if we want people to help improve > the ODT backend too. > There is no point in developing only for people who can help in developing, they can do it themselves, if that makes sense? [...] > > Incorrect, the construct changes do not necessarily map with existing > styles. I know because I modified a few of them over time already. A good > example is the admonitions, first implemented as a paragraph, than as a > table, than as a section. Each have different kind of properties, and a > different number of styles as well. You cannot expect this to keep on > working by just changing the names. > Yes, and that breaks XML styles just as badly. >[...] > > If you are only interested in the LibreOffice styling for real work, > expecting no changes. No than it's not the right time, on the other hand > without the ODT backend in package format we may not even attract those > people that can help out with the ODT backend in general. Sure, but at the current stage are there not more important issues than removing the need to open the FODT and save as an ODT? > > So I prefer both strategies, knowing that for pure endusers it may take a > while before we have a stable mapping between AsciiDoc/DocBook and ODF. > Of course I agree we want that in the long run. > > >>> 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. :) > > > I am not paid for it, I wish I was. But the only way to work on it is to > make it compelling as quickly as possible so others are willing to pay for > finalizing some part of it they need. If you are relying on this I am concerned that you are going to be severly disappointed. > > > >> 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. > When you said business hours I thought you meant as part of your work. If not fine. If you are doing it in work hours, or are expecting others to, then I am concerned that much (all?) of the Github contents is not explicitly open licensed. Should add a LICENSE file that says that files not explicitly licensed otherwise are GPL V2ed (to match asciidoc) and a2x-backend.py is MIT the same as a2x. Making the licenses the same avoids *any* issues of using them together. > > There is a difference between an organization evaluating an 'alien' Open > Source product and a company owning one and only considering the > revenue-generating stuff. Open Source is basically scratching your own > itches, I don't think nobody expects more than that. What Oracle is (not) > doing is on a completely different level, it's more about what people were > expecting and getting, and how Oracle (but also Sun) were not delivering. > > But since it is Open Source, you luckily do not have to depend on Oracle or > Sun, if you can afford to take over the development cost ;-) > Yep, don't get me wrong, I wasn't trying to compare you to Oracle, or Sun, just that they were the OpenOffice custodians. > > >>> 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? > > > AsciiDoc maps to DocBook, it's tailored to DocBook in many ways. So if I > want a mapping between AsciiDoc to ODF (which is what a backend basically > is) I need to find ODF constructs that implement DocBook (or if you prefer > AsciiDoc) elements. Oh, I see what you mean, I never really thought of it that way, so I interpreted your comment badly. > > But AsciiDoc is rather difficult to think of in abstract terms IMO. It's > simple to write, but less easy to parse. Yep, its that damn natural language in between the markup :) > > (And no, I am not interested in docbook2odf anymore, but after we have > defined the output of the odf backend(s), the work on docbook2odf is easier, > but since I hate XSLT, not on my watch :)) Totally agree :) [...] >> >> 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. > > > I am surprised you see two sides, the asciidoc community vs myself :) I > would divide the asciidoc community in three groups, those that are > interested in the first use-case, those interested in the second, and those > interested in both use-cases. > > I didn't know I was on my own ? Maybe we still havn't got the same understanding, I certainly wasn't meaning that, just as you said above, we need to support both use cases. I think where we have differing understandings is in where the help is likely to come from and therfore the order of doing things. Probably not helped by my having very little time and wanting to prioritise ruthlessly. > > > >>> 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. > > > Well, I am scratching my itch, you are scratching yours, that's how Open > Source works. We don't have to necessarily scratch the same itch. > Scratch, scratch, true :) (oh damn, its just the dogs fleas) > I don't completely understand where I offended you, Stuart or the asciidoc > community when I stressed that XML stylesheets and flat XML ODF will be > important in the foreseeable future, if only for speeding up development. > As I said somewhere else, I think much of it is misunderstanding of expectations and priorities. It sounded like you were saying that because there is a problem with ODT generation that nothing should be worked on other than XML stylesheets. Whereas I can see a glimmer of hope that we can move away from those things and want to have nothing further to do with them, concentrating efforts on interactive stylability. Probably the answer is somewhere between. I am also doubtful of the effort you expect materialising, but it would be great if it did. 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.
