On Wed, 22 Feb 2012, Lex Trotman wrote:
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 :)
Not necessarily.
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.
I don't know how that mechanism works though.
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 ?
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.
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.
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 :)
Ok, when I run it on any file I get this clear problem:
----
[dag@moria asciidoc-odf]$ a2x -b odt examples/asciidoc-cheatsheet.txt
Traceback (most recent call last):
File "/usr/bin/a2x", line 934, in <module>
a2x.execute()
File "/usr/bin/a2x", line 356, in execute
self.to_backend()
File "/usr/bin/a2x", line 608, in to_backend
eval('to_%s(self)' % self.backend)
File "<string>", line 1, in <module>
File "/etc/asciidoc/backends/odt/a2x-backend.py", line 87, in to_odt
a.make_archive(opts.base_doc, self.asciidoc_file, odf_file)
File "/etc/asciidoc/backends/odt/a2x-backend.py", line 57, in make_archive
shutil.copyfile(mc.group(1), os.path.join(td, mc.group(2)))
File "/usr/lib64/python2.6/shutil.py", line 50, in copyfile
with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory:
'/home/dag/home-made/asciidoc-odf/images/icons/home.png'
----
This file has this configured:
:iconsdir: /usr/share/asciidoc/images/icons
The same happens if you are using a2x on a file in a different directory
with inline images (without iconsdir set):
----
[dag@moria asciidoc-odf]$ a2x -b odt examples/asciidoc-odt-test.txt
Traceback (most recent call last):
File "/usr/bin/a2x", line 934, in <module>
a2x.execute()
File "/usr/bin/a2x", line 356, in execute
self.to_backend()
File "/usr/bin/a2x", line 608, in to_backend
eval('to_%s(self)' % self.backend)
File "<string>", line 1, in <module>
File "/etc/asciidoc/backends/odt/a2x-backend.py", line 87, in to_odt
a.make_archive(opts.base_doc, self.asciidoc_file, odf_file)
File "/etc/asciidoc/backends/odt/a2x-backend.py", line 57, in make_archive
shutil.copyfile(mc.group(1), os.path.join(td, mc.group(2)))
File "/usr/lib64/python2.6/shutil.py", line 50, in copyfile
with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory:
'/home/dag/home-made/asciidoc-odf/dag-professional-250.jpg'
----
The obscure (to me) error might be related somehow. It is looking in /tmp
for image-files it should have in its working directory.
----
[dag@moria examples]$ a2x -b odt asciidoc-odt-test.txt
Traceback (most recent call last):
File "/usr/bin/a2x", line 934, in <module>
a2x.execute()
File "/usr/bin/a2x", line 356, in execute
self.to_backend()
File "/usr/bin/a2x", line 608, in to_backend
eval('to_%s(self)' % self.backend)
File "<string>", line 1, in <module>
File "/etc/asciidoc/backends/odt/a2x-backend.py", line 87, in to_odt
a.make_archive(opts.base_doc, self.asciidoc_file, odf_file)
File "/etc/asciidoc/backends/odt/a2x-backend.py", line 57, in make_archive
shutil.copyfile(mc.group(1), os.path.join(td, mc.group(2)))
File "/usr/lib64/python2.6/shutil.py", line 51, in copyfile
with open(dst, 'wb') as fdst:
IOError: [Errno 2] No such file or directory: '/tmp/tmpbupoAW/Pictures/i_1.jpg'
----
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?
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...
[...]
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.
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 ?
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 :)
You cannot share/merge changes to an OTT easily. If you deny that, try
using Word documents in a Git repository.
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.
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.
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). So
you cannot drop all images, but you also cannot retain all images.
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.
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.
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.
[...]
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.
Yes, <paraphrase>administrators, developers and technical
people</paraphrase>
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.
Again, think about the 3 types of users, consider the use-case you mention
and the fact that those users are the last to be pleased. And then
remember my preference (read: _my_ preference) to focus on flat XML ODT.
You are welcome to work on your preferred use-case.
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?
Again, you seem to again live in thise one-dimensional world where only
one use-case is ever needed. Whereas I am trying to stress that this
project has phases, and there is a *need* to not only consider the final
use-case we are work towards.
Why is this is difficult ?
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.
Yes, but I fail to make your understand it's easier to fix with XML
styles. Because people can track the changes we make to our XML styles
that can be properly versioned in Github _and_ can easily be performed on
the existing styles (if any).
The way I see it work is that people submit an XML style theme, and
whenever a construct is adapted/improved, we would modify the existing XML
styles. (That is what I am doing already anyway)
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.
[...]
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?
Depends. The ODT backend improvements, which I am postponing until I can
discuss this during the ODF plugfest with some knowledgeable people. I'll
probably experiment while using the asciidoc-odf workflow and prepare the
presentation(s) though.
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.
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.
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.
Oh, but it is as part of my work in the sense that I write documentation
in AsciiDoc and now produce PDF's through this toolchain. That's how I
currently have been doing some of the improvements. But I am not being
paid for working on it.
And there's a chance that the toolchains might be used internally by other
people too after we promote it some more (with the existing theme I made).
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.
I will add a GPLv2 standard license !
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.
Ooooh, I know this too well. I am not a big friend of Oracle, even if they
do make some contributions to Open Source, the balance is skewed on the
wrong side.
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 like to offer more functionality than you are interested in. I don't see
why we need to choose.
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.
Oh, but I am not betting this project on my or your availability. Mine is
too unpredictable anyway. The only driving force in my case is that I tend
to add deadlines by sending in proposals to conferences, hoping they get
selected and then implement the stuff I'd like to demonstrate ;-)
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.
Ok, but I am not at all managing anyone else's time but my own. I have not
authority over everything else (unfortunately ;-)). So if you somehow
thought I implied what other people should be doing, than forgive me my
poor English !
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.
Oh no, I definitely want a working ODT asap.
I am also doubtful of the effort you expect materialising, but it
would be great if it did.
I have no doubts that we get there, but I can not predict whether it's
going to be this year, next year or even later. It all depends on the
interest and contributions.
Without your help and Stuart's help, I would have been nowhere today. And
today I am already using it for various documents !
--
-- 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.
