[...] >> >> Ok, as I said, if we wrap the metadata in a comment for packaged ODF >> it can be extracted and written to meta.xml. > > > I don't know how that mechanism works though.
I explained it in a previous post. When the non_flat_odf attribute is set wrap the meta info in a comment which a2x-backend.py can extract and put in the odt. That will be part of my next set of changes, so you need only wait till then. > > > >> 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. > > > I don't know yet, I have not investigated the OTT case. It might be due to > the lack of meta information ? Possible, or different settings, at least at first glance some of the settings look like they may affect how output is rendered (although most seem to be about printing). [...] > > Yes it does, it allows by default to have us store the default styles in XML > format (which you don't care about, but is useful), and theming would work > out of the box, even if you are not interested in that specific use-case. > I said elsewhere that now I have an idea that it might work I will do it when I get time. IIUC the way themes are going to work with different backends is still to be decided. > > >>> the current implementation fails for an obscure (to me) reason :) >>[...] Are you sure you have the latest odt.conf, the changes I committed a week ago should have fixed this. Side point, are you getting notifications of commits and comments made to github? I'm not entirely convinced I get them all? [...] >> 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? > > > I know how LibreOffice does them, but I don't want to do them on a per cell > basis. At least, I have no clue where to start because that would make OTT > styles useless: add a column and your existing styles are off by one > column... > Don't we have to apply styles on a per-cell basis since asciidoc can do that? As for applying OTT styles, we can't, a user table style is not stored in the OTT file, it appears to be in the user configuration somewhere. If you create a table style with one document it is available when you go to the next document. But if you send the document to someone who doesn't have the table style defined it isn't available. So it doesn't go with the document :( Should be raised as a bug on LO if confirmed, since how does the next person modifying the document apply it to a new table? So OTT tables will be limited in styling options until LO is fixed. C'est la vie. > >>>> [...] > > It's not so much about the size, as it is about the size for every change. > 6.4 kB per change vs. a few bytes. And since you cannot track any changesn, > what's the point ? > Since this will change soon it doesn't matter, but for your information. I get tired of explaining this to every newbie developer on another project where we store *installable* files produced during a build. If we don't, then anyone trying to use the latest version from git has to have all the development tools installed to be able to use it, in this case make, zip etc (yes I had to specially install zip for this, everything else I do uses gzip, bzip2 or xz). Non-programmers and windows users may not even have make installed. You still have the sources to do your comparisons of changes, I'm not suggesting you remove those. [...] > You cannot share/merge changes to an OTT easily. If you deny that, try using > Word documents in a Git repository. > Word??? thats a four letter word :) > > > > Go and do this. Take a document with images included, modify the styles, > save it as an OTT and then look inside the OTT (zip) file. The images are > there. And this is exactly the use-case you are proposing. So the OTT file > will be retaining all images during various iterations. Re-read what I said above, "this happens if you use documents with content" don't have content in your ott file, especially images. > > Are you going to disagree on that too ? Because that's how it works. > > Now let's take the example where headers and footers _do_ include the image > in the stylesheet (it's one of the few examples where it can). I think the more likely one is list bullets, if you select one of the LO graphics bullets for example. And I found backgrounds do it too. So you cannot > drop all images, but you also cannot retain all images. > Ummm, thats what I said :) > > >>> 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 :) > > > Indeed, example above. So either we embed them in the styles and drop them > from the package, or we have to implement some processing in a2x. > Or you use empty OTT files. You need to use empty OTT files to prevent name clashes between pictures anyway (see issue #16). Well, we can't make LO embed them in the styles. I am going to search the styles.xml and settings.xml for references to Pictures and copy those files as well, lets hope thats enough (and that the text "Pictures/" doesn't occur anywhere else in the files) [...] > No, I am saying that it's not clear cut as you make it out to be. Images in > general are not part of the styles (with a few exceptions), while in some > cases we would prefer these to be part of the style, e.g. admonitions. > Submit a bug report to Oasis :) I wasn't suggesting images in general were part of styles, just that they can be, and so we need to handle that case as well. And that the current method of generating ODTs handles it by default. > > >>>> [...] > > Yes, but I fail to make your understand it's easier to fix with XML styles. Clearly I fail to make you understand that I consider doing *anything* with XML worse, by definition :) [...] > Compare this to in-tree kernel device drivers, and out-of-tree kernel device > drivers. The in-tree ones are being maintained, the out-of-tree require the > owner to take notice and adapt. With zipped OTT files there's no > collaboration. > Well, its up to you how many "in-kernel" styles you want to modify, at this point I would have thought we only wanted one, the standard one, otherwise it will start to impact your workload significantly if the way ODF is generated changes as much as you suggest it will. "out-of-kernel" styles are the style owners problem IMHO. But we shouldn't egregiously break them. > > >>> [...] >> >> If you are relying on this I am concerned that you are going to be >> severly disappointed. > > > Maybe, but it worked for a few other Open Source projects of mine in the > past. One of them is used by quite a number of large corporations. > Oh well, don't get me wrong, I will be *very* happy if it does work out. > > [...] >> 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. > > > Right, I was expecting GPLv3, but what you suggest makes more sense. The a2x > stuff has been removed from Github and I cannot add a LICENSE to already > removed content. Do you mean the modified version of a2x that was there until Stuart fixed the real one? If so don't worry, it explicitly says MIT. > > I will add a GPLv2 standard license ! > Good, I'll add a line to a2x-backend.py when I make the changes saying it is licensed the same as a2x. Since it is loaded by a2x it should match to avoid any problems. Otherwise it might need LGPL to use it with a non-GPL a2x, but I am only a "bush lawyer" and I prefer to avoid such issues. [...] >> 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 like to offer more functionality than you are interested in. I don't see > why we need to choose. "support both" means no one has to choose. I think we are saying the same thing in different ways :) [...] 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.
