On Tue, 21 Feb 2012, Lex Trotman wrote:
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.
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 !
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.
Thanks for the clarification. That is indeed what I intended.
[...]
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 :)
I hope I am not going to be solitary for too long...
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.
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.
[...]
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.
Indeed, and I lack the proper ODF knowledge to make good decisions. I have
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.
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.
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?
The lack of metadata, the mismatch of styles, the fact that we have to
have one generated in the distribution (for the default case) and the fact
that the current implementation fails for an obscure (to me) reason :)
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?
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 !
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).
[...]
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.
That's why working on XML stylesheets within a company makes more sense,
than modifying ODT files and sharing them in Github.
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.
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.
Regardless of how I would prefer, or expect it to work, that's a
limitation.
[...]
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 :)
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 ;-)
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.
But AsciiDoc is rather difficult to think of in abstract terms IMO. It's
simple to write, but less easy to parse.
(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 :))
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.
I will.
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.
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 ?
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.
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.
--
-- 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.
