On Mon, Aug 24, 2009 at 10:52 AM, Kai Ahrens<[email protected]> wrote: > Hi Thorsten, > > Thorsten Behrens schrieb: >> >> Kai Ahrens wrote: >>> >>> Taking a look at both existing 'extensions', I don't consider >>> them as a final solution for the problem. As Thorsten already >>> mentioned, they don't touch the internals of OOo, which is >>> good on the one hand but doesn't allow us to get a really >>> well designed, tight integration into OOo on the other hand, >>> which seems to be needed if it should be a 'real' replacement >>> of our current internal vector graphic representation. >>> >> Hi Kai, all, >> >> right, in general - so, the existing solution for importing svg as >> an image (like e.g. you can insert png or wmf graphics) is limited >> by the capabilities of the StarView metafile format, so everything >> that needs to get us better svg image fidelity needs to either >> enhance svm, circumvent it, or replace it entirely as the way vector >> graphics are transported inside OOo. > > Replacing SVM entirely would be my choice #1, although this will > require quite a _lot_ of effort. Maybe an intermediate solution > would be to still use the GDIMetaFile internally for transportation > reasons, but switch to SVG use when it comes to external usage. > > E..g seomething like 'GDIMetaFile::is/getSVG()' ... > >> >> It's basically the same story for the document import, only that, in >> order to improve on this, we'd not only need to enhance the applications >> cores, but also the ODF file format (something I'd be very interested in; >> ideally svg would be fully embeddable inside ODF). > > Sure, this is what I meant with external usage. Their would > only be the SVG or original file format used inside ODF, which > of course requires stable SVG import, export and display possibilities.
This is also a BIG todo on the OASIS TC and W3C, some of the previous conversation and hurdles can have been documented as well as being part of ODF-Next: http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_ODF Then again maybe you are more familiar than me since it seems to be mostly handled by Sun's Michael Brauer. > >>> I talked with several people inside the Sun-OOo group and >>> as a result of these discussions, I finally put this on top >>> of my ToDo list, which means that I will come up with a proposal >>> and even a first prototype for evaluation purposes very soon. >>> Please read 'Soon' as a time span of a few weeks and _not_ years. >>> >>> As soon as I'll have a proposal/prototype ready, I'll come back >>> to you and will announce it on the appropriate lists/blog for >>> further discussions. >>> >> It would be helpful to have this discussion, _before_ embarking on an >> implementation, on the public mailing lists; I'm convinced there are a lot >> of people that are interested in this topic. > > As said, I will not come up with a complete implementation, but with > a proposal and maybe a first prototype instead. So, there will be enough > time for discussions, but for the beginning, I'd like to think of a > concept at all before going public. > >>> At the moment, I'm very optimistic to get it into the next major >>> release, which will be OOo 3.3. >>> >> So, do I get this right, you're suggesting not to offer a bug >> bounty, but instead have this implemented internally at Sun? > > No, that'll be not the case. At the moment, I think of a combined > effort, meaning to agree on a concept in the first run and > to do some basics initially on the Sun/... side. Further efforts could > then be combined with a bug bounty program. As you do know very well, > there are quite a lot of things to consider for replacing the > GDIMetaFile at whole and I doubt that there are more than a handful of > people (including you) at the moment, knowing all possible pitfalls. However as far as I have seen there seem to be already some solutions that have clearly avoid th pitful without compromising the current development (although it seems it will eventually need to update). > With best regards > Kai > > F'up on [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Alexandro Colorado OpenOffice.org Español IM: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
