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). Wrapping that behind drawing layer primitives, anyone? ;) >> 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. 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 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. See above for a start. ;) Cheers, -- Thorsten
signature.asc
Description: Digital signature
