From 742a9f313606eed2c5e2340f73ccd89818ad6599 Mon Sep 17 00:00:00 2001 From: buliabyak Date: Sun, 11 Mar 2007 05:24:36 +0000 Subject: [PATCH] fix 1656169 --- src/sp-item.cpp | 66 ++++++++++++++++++++++--------------------------- 1 file changed, 29 insertions(+), 37 deletions(-) diff --git a/src/sp-item.cpp b/src/sp-item.cpp index eb3abce16..486e00d16 100644 --- a/src/sp-item.cpp +++ b/src/sp-item.cpp @@ -640,46 +640,38 @@ sp_item_write(SPObject *const object, Inkscape::XML::Node *repr, guint flags) repr->setAttribute("transform", c); g_free(c); - SPObject const *const parent = SP_OBJECT_PARENT(object); - /** \todo Can someone please document why this is conditional on having - * a parent? The only parentless thing I can think of is the top-level - * element (SPRoot). SPRoot is derived from SPGroup, and can have - * style. I haven't looked at callers. - */ - if (parent) { - SPStyle const *const obj_style = SP_OBJECT_STYLE(object); - if (obj_style) { - gchar *s = sp_style_write_string(obj_style, SP_STYLE_FLAG_IFSET); - repr->setAttribute("style", ( *s ? s : NULL )); - g_free(s); - } else { - /** \todo I'm not sure what to do in this case. Bug #1165868 - * suggests that it can arise, but the submitter doesn't know - * how to do so reliably. The main two options are either - * leave repr's style attribute unchanged, or explicitly clear it. - * Must also consider what to do with property attributes for - * the element; see below. - */ - char const *style_str = repr->attribute("style"); - if (!style_str) { - style_str = "NULL"; - } - g_warning("Item's style is NULL; repr style attribute is %s", style_str); - } - - /** \note We treat object->style as authoritative. Its effects have - * been written to the style attribute above; any properties that are - * unset we take to be deliberately unset (e.g. so that clones can - * override the property). - * - * Note that the below has an undesirable consequence of changing the - * appearance on renderers that lack CSS support (e.g. SVG tiny); - * possibly we should write property attributes instead of a style - * attribute. + SPStyle const *const obj_style = SP_OBJECT_STYLE(object); + if (obj_style) { + gchar *s = sp_style_write_string(obj_style, SP_STYLE_FLAG_IFSET); + repr->setAttribute("style", ( *s ? s : NULL )); + g_free(s); + } else { + /** \todo I'm not sure what to do in this case. Bug #1165868 + * suggests that it can arise, but the submitter doesn't know + * how to do so reliably. The main two options are either + * leave repr's style attribute unchanged, or explicitly clear it. + * Must also consider what to do with property attributes for + * the element; see below. */ - sp_style_unset_property_attrs (object); + char const *style_str = repr->attribute("style"); + if (!style_str) { + style_str = "NULL"; + } + g_warning("Item's style is NULL; repr style attribute is %s", style_str); } + /** \note We treat object->style as authoritative. Its effects have + * been written to the style attribute above; any properties that are + * unset we take to be deliberately unset (e.g. so that clones can + * override the property). + * + * Note that the below has an undesirable consequence of changing the + * appearance on renderers that lack CSS support (e.g. SVG tiny); + * possibly we should write property attributes instead of a style + * attribute. + */ + sp_style_unset_property_attrs (object); + if (flags & SP_OBJECT_WRITE_EXT) { repr->setAttribute("sodipodi:insensitive", ( item->sensitive ? NULL : "true" )); if (item->transform_center_x != 0) -- 2.30.2