Inkscape

Bug #1046170
Comment #9

Comment 9 for bug 1046170

Revision history for this message

su_v (suv-lp) wrote on 2012-09-10:

mixed test case (SVG only, not related to SVG<->PDF round-trips) with text style properties defined on various levels of elements inside a regular object. Edit (7.1 KiB, image/svg+xml)

> - a fix has been committed to bzr rev 11661.

Personally, I have no idea how safe this assumption is because I don't know any details of how the PDF importer works for text:
// assume all <tspan> nodes in a <text> node share the same style
Does the PDF import routine always enforce the creation of separate text objects if a style attribute (e.g. bold/normal) changes within a contiguous text?

> - the result is that the font family is now displayed in the status
> line at the bottom.
> - I am not sure if this addresses all the issues raised in this report

It does not address the underlying issue of the select tool messages as far as I understand it. You can reproduce a similar - at first sight inconsistent - message of the select tool for selected text in Inkscape itself (without importing or round-trip-editing a PDF file with text), for example by changing the font family of a regular text object by explicitly highlighting all content and choosing a different font family for the highlighted text. This will result in the select tool reporting a different font family in the status bar than shown in the text tool controls bar when selecting the text with the text tool cursor (the text tool controls bar shows the correct style of the current <tspan>, whereas the select tool apparently only considers the style attribute of the parent <text> element.

It seems to me that either
a) the select tool each time ought to check whether any <tspan> object inside the selected <text> object has a different font style set than the parent <text> object, and adjusts the message accordingly (if none of (possibly nested) <tspan> objects overrides an inherited style attribute, report the style of the parent <text> object; if all <tspan> elements result using an identical computed style (family, size, style, …), and it differs from the style of the parent <text> object, report the computed style; else report something like "various font styles used".
or
b) it is considered ok that the message in the status bar always reports the style assigned to the parent <text> object, including 'None' if no 'style' attribute is present on that level (which makes sense considering that within the <text> container, there can be an unlimited number of different style attributes added to various (nested) <tspan> elements, making use of style inheritance rules while overriding individual properties).
or
c) a mix of a and b: only report the style of the <tspan> children instead of the parent <text> object if they all use an identical style (also applies if the parent has no 'style' attribute itself). For text objects containing multiple <tspan> elements with various different style properties, always report the style of the parent <text>.

</possibly off-topic>

> - a fix has been committed to bzr rev 11661.

Personally, I have no idea how safe this assumption is because I don't know any details of how the PDF importer works for text:
      // assume all <tspan> nodes in a <text> node share the same style
Does the PDF import routine always enforce the creation of separate text objects if a style attribute (e.g. bold/normal) changes within a contiguous text?

> - the result is that the font family is now displayed in the status
>   line at the bottom.
> - I am not sure if this addresses all the issues raised in this report

It seems to me that either
a) the select tool each time ought to check whether any <tspan> object inside the selected <text> object has a different font style set than the parent <text> object, and adjusts the message accordingly (if none of (possibly nested) <tspan> objects overrides an inherited style attribute, report the style of the parent <text> object; if all <tspan> elements result using an identical computed style (family, size, style, …), and it differs from the style of the parent <text> object, report the computed style; else report something like "various font styles used".
or 
b) it is considered ok that the message in the status bar always reports the style assigned to the parent <text> object, including 'None' if no 'style' attribute is present on that level (which makes sense considering that within the <text> container, there can be an unlimited number of different style attributes added to various (nested) <tspan> elements, making use of style inheritance rules while overriding individual properties).
or 
c) a mix of a and b: only report the style of the <tspan> children instead of the parent <text> object if they all use an identical style (also applies if the parent has no 'style' attribute itself). For text objects containing multiple <tspan> elements with various different style properties, always report the style of the parent <text>.

</possibly off-topic>