Christian Lippka - Sun Microsystems Gmbh - Hamburg wrote: > So we allow linking of svg graphics as images. Perfectly works right > now, why you need them embedded in the content.xml stream? > Actually I don't care about where exactly it's placed, if you share the same shape set across many places, it would even be a good idea to only reference a master instance; the point is that I want e.g. shape polygons to stay editable, while e.g. retaining the nice svg multi-color gradient it originally had, and not have it mapped to the sub-par ODF gradients.
> 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. > I'm not speculating what agenda the guys that pay you might or might not have; I for once tend to have my own opinion on things & are permitted to speak freely; this sometimes happens to be in line with my employer, sometimes not. In this case, it's just technically superior to split up xml into smaller chunks, and I guess that's the reason you're after it. Similarly, I consider svg technically superior for expressing rich vector graphics, and that's why I'm pushing for it. In case this is not painfully obvious, I'm working for Novell. Which is totally irrelevant to this kind of technical discussion. >> 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. > Oh right - FWICT there's still OpenOffice.org Draw included in the standard shipment, which, quote from the project page, "allows you to easily create pixel and vector based graphics" - how is that different from a vector drawing application? ;) (and since Draw and Impress share the same code, this transitively applies to Impress as well - but the argument is bogus anyway, see below) >> (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. > Very true - ODF originated from OOo's initial xml format. And especially the draw: namespace contains numerous examples of stuff 'special-cased' for OOo - i.e. not abstracted away from OOo's core. In contrast to that, SVG has evolved from at least two competing formats (PGML and VML), and has thus far a much better track record of independent implementability & interoperability. So ODF's draw namespace is indeed designed for the special purpose of serializing OOo's drawing layer content; whereas svg is designed for the special purpose of being a universal vector graphic format. I think the difference is obvious; also noting that svg was influenced by VML, and knowing what's that used for inside MSO (and specifically what it's *not* used for), pretty much gives an idea how OOo/ODF could benefit from embracing svg. >> 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. > Wow. You did notice the smiley? ;) >> 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. > Except that you didn't borrow from svg, you copied the names & changed the semantics. > 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. > Exactly my point. We use, err, 'borrow' from SMIL, and hide the complexity away from the user - she can select an effect like "loop-de-hoop eight times in a row" from a gallery-like list, which completely abstracts away the sequence of atomic animation elements & their delicate timing setups. Why can't we do something similar with svg? Nice gallery of gradients, with some speaking name & a preview - and if anyone absolutely needs to customize that, she can use a specialized svg editor on the gallery fragments. Cheers, -- Thorsten
signature.asc
Description: Digital signature
