KoPathShape saveOdf and loadOdf oddities

[Boudewijn Rempt]

On Saturday 17 January 2015 Jan 09:58:28 Stefano Bonicatti wrote:
> Hello, we have a problem in Krita with drawing a polygon or a bezier curve
> (or basicly anything that uses KoPathShape) in a vector layer, then
> transform it so that the lines increase their thickness, then save the file
> in .kra format and then reload it: the thickness is not kept.
> I've found that this is because loadOdf does something different than
> saveOdf when loading and i don't get why.
> First it only loads some attributes back, then it checks for some specific
> element names (and in my tests i never entered in those ifs), then the
> transformation matrix is baked into the viewbox and the path geometry only,
> while the stroke is kept unchanged.
> This is wrong though because the original transformation, before saving,
> changed also the stroke thickness.
> Why baking the matrix into the path geometry only? Why loadOdf doesn't just
> do the "opposite" of what saveOdf do?
> 
> I tried replicating what saveOdf does writing simply this:
> 
> Q_D(KoPathShape);
> loadOdfAttributes(element, context, OdfAllAttributes | OdfViewbox);
> KoPathShapeLoader loader(this);
> loader.parseSvg(element.attributeNS(KoXmlNS::svg, "d"), true);
> d->loadNodeTypes(element);
> loadOdfAttributes(element, context, OdfCommonChildElements);
> loadText(element, context);
> 
> as a replacement for loadOdf and it works as expected.
> Though not being 100% that this doesn't give problems somewhere else, i'm
> writing here for clues.

One possibility that springs to mind is that the work on using svg inside flake actually never got properly finished. Jan started on it, did a ton of work, but then real life caught up and he had to stop working on the project. But if we save it, we should load it, and it seems all nicely namespaces in KoXmlNS::svg, so I don't expect any problems with a patch that basically does this.


-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org