Thorsten Behrens wrote:
Christian Lippka - Sun Microsystems Gmbh - Hamburg wrote:
[...] and pleaser don't state that I don't want it because it
confuses users as I never said that.
Then what else did you mean by demanding something that "allows
editing by a typical office user"? I can only assume that you wanted
to express svg editing being too complex for the average layman, and
thusly too confusing. Sorry, but do tell, what did you want to state?
See my remark to Eric.
Which was
Sorry Eric, it is not about the number of features, it is about the
complexity. For example, if there are 1001 ways to add a footer to
your document, start imagine how to implement a "show/hide" footer
feature....
Last time I checked, svg had no way of defining footers. What else
would not work?
Exactly, but you can do footers in svg, svg just does not specify how
you do footers. So how
should the application know what was meant as a footer by the documents
creator? This is only
possible if svg will get tags and restrictions, but wait, then we have ODF.
Huh? Christian, for supporting embedded svg you basically only need
to render it. What makes you think anyone wants to tweak filter
coefficients, or gradient transfer functions?
Alexandros wiki page is more about using svg as the document format.
No it's not. It's about using full-featured svg for draw shapes,
instead of just a copied & re-defined subset. Nobody would prevent
us from specifying that svg elements can only reside below
draw:svg-shape-whatever; nobody (at least not me) is expecting ODF
to swap out drawing wholesale, and swap in svg instead. That would
indeed be something svg was never designed for.
So we allow linking of svg graphics as images. Perfectly works right
now, why you need them
embedded in the content.xml stream? We already plan to cut up the
content.xml and styles.xml
stream in multiple streams (f.e. one per slide in impress, one per sheet
in calc) which is more
like the format that the guys who pay you want for OOo as a default anyway.
Well then we could also use html for writer. That would not be
advisable for the very same reasons.
HTML was never designed for editable, nor for office content. A
mapping would kind of work, but be quite lossy & un-natural. In
contrast, svg is used as the native document format for vector
drawing applications, and except for a few corner cases, it's
actually a superset of ODF's drawing features. So this is really not
a valid argument, quite the contrary.
Yes svg is used by vector drawing applications, and we talk about office
applications.
(note that the SVG WG offers to fill these few feature gaps)
The problem are not the feature gaps, the problem is that both formats
are designed
for a special purpose. On the same level we can argue that we can do the
same by
using png. Png can be perfectly displayed on small devices and
information about
the document structure can be put in user defined chunks.
I'm not against svg, I'm against using it for something that it was
never designed for.
Done:
http://blog.thebehrens.net/2009/07/28/hackweek-iv-canvas-convwatch/
(only needs to be hooked up in drawinglayer & xml impex) ;)
I know your definition of done, but for me that is started and never
finished. I know it
is cool and easy to do the first 20% of a job and show screenshots
around., but it is
the last 80% that counts.
Other than that, it would help this kind of argument if you'd start
answering to my question; why you'd expect a user wanting to change
all those arcane svg attributes, while at the same time you don't
allow that for e.g. the SMIL stuff?
Exactly, like every where else in ODF we borrow from other standards
like fo or svg.
This is how xml was meant to be used. You can read this at w3c.org. And
the smil
elements and attributes in ODF are used where appropriate and capsuled
in ODF
elements that define what is possible and what not. This is the only way
to ensure
that each ODF supporting application is able to show the simple time
line of animations
that a typical office user expects. If you allow full SMIL than you are
at a level
where you need a user interface like Adobe Flash. Which the typical
office user
will not be very comfortable with.
Christian.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
