Hi, > I updated the ticket, but when the time comes, we actually may want both. Right.
> Depending on how this plays out, we might not want to implement > SVGSerialization using 100% PIvot code. If we were to depend on third party > libraries, like Batik, that would require the user to have a larger client > download. Yes, much larger than Pivot (currently). Ah, I've seen svg compressed (with gzip) as svgz, could be useful to handle ... and maybe have also a wtkd.gz or similar ... > The app developer could sidestep that issue if they converted their svg files > to wtkx before deployment. You means WTKD, tight ? And maybe also the ability to save the drawing as image, chosen resolution, color depth, transparency, etc ... I like this approach, could be a very good utility (with view, import features, etc) under tools ... But going a step further, what do you think on providing also the ability to save the digested WTKD format (in a binary or other efficient serializable format for example using our existing serializers) to avoid parsing, etc ? This could be an utility under our Tools, choosing one or more resolution, etc ... Bye
