Thorsten Behrens schrieb: > Kai Ahrens wrote: >> 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()' ... >> > Hi Kai, > > oh, replacing svm - well, turns out this is more a gsl topic; god I > hate this mailing list segregation ... :( > > But yeah, Rodo implemented a very smart way of tunneling EMF+ > through svm, quite similar in concept to the way EPS is tunneled. > The catch of course then is to detect that case during rendering, > and defer to a native svg renderer. But something quite doable. > > And even more, something that gets me closer to my goal of getting > rid of 'importing' graphics in the first place, but instead passing > them around natively, and having dedicated renderers (no difference > at all, conceptually, than 'importing' them to svm).
> That's exactly what I meant with still using GDIMetaFile to wrap the native format, which is currently already available for passing around graphics if they are not modified on their way from the file into the final document. This will 'just' get extended in the way you described, by adding appropriate renderers for displaying the content of the native format. I currently _don't_ plan to do a conversion from SVG to SVM. >>> 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. >> > Ideally, I would not 'import' svg at all. There are mature svg > renderers out there, just use those. Yes, please see my comment above. One option would be to use the Mozilla SVG renderer, although I didn't take a deeper look yet. > No, I was referring to inline usage of svg, e.g. being able to use > svg gradients directly on a draw:shape would be awesome. > >>> 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. >> > Let's think about the concept in public. This is a feature request > being pushed by the community; now please, let's involve the > community. As far as I can see, we're already doing this with these mailings. > As much as I hate my work being rejected/duplicated for obscure & > nit-pickish reasons (*at least* the document import is pretty nice & > useful on it's own right), _if_ Sun absolutely wants that, then > _please_ invest that work into something that benefits other filters > & the general architecture in the long run. Nobody and in special Sun rejected your work and it (or parts of it) may be used for the upcoming solution if useful. On the other hand, please don't speak of multiple/duplicate work on topics, given that Haui already came up with a working document import for SVG, but you felt to do it again (in principle) during one of your 'Hacker Weeks'. - Kai --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
