Filtered objects count

[David Mathog]

The attached SVG was prepared with 0.48+devel on Windows XP SP3. There are supposed to be tick marks on the left, bottom and right sides of the black rectangle. When viewed with Inkscape 0.48.2 these are visible. However, they are not visible with Seamonkey or Inkscape 0.48-devel. Bizarrely, these ticks can be selected in the 0.48-devel version, and the stroke settings appear to be exactly the same as for 0.48.2, yet they are not visible.

This file was produced using 0.48-devel with a few patches in the EMF output routines, nothing that should have affected a simple line draw like this. This file also had a similar glitch involving text which mysteriously fixed itself when the "fill" property was toggled off and then back on again. In that case text in the drawing was being drawn behind, or merged with, the underlying picture (since removed from the lower layer). This had the mind bending effect of having an object (the image) in the bottom block an object on the top.

Note, at one point this file had a rectangle with no border in it, so this glitch may be related to bug 939918

[David Mathog (mathog)]

Hmm, I just noticed that the text around the rectangle is not visible when viewed in Seamonkey either, and that is visible in either version of Inkscape. Seems like the SVG might be corrupted in some manner, and different programs are handling that corruption in different ways.

[su_v (suv-lp)]

The "missing" ticks (and labels in Firefox) on both sides of the rectangle in SVG viewers like web browsers is due to them having a filter effect (layer blend mode 'Multiply') applied (which apparently only has partial support by several SVG viewers) - the message on the status line in Inkscape when selecting such an object gives the necessary hint ("filtered").

Browser support varies:
- Firefox 10.0 renders neither ticks nor labels,
- Chromium 19 and Opera 10.61 render the filtered text but not the ticks
- Safari 5.1.2 renders the original SVG file as expected (labels + ticks).

Underlying issue:
At some point in your workflow, those objects must have been either copied from a layer which - probably mistakenly - had this layer blend mode enabled or moved through such a layer (with menu 'Layer > Move selection to layer above|below').

Attached is a "fixed" version of the file with all filter effects removed (menu 'Filter > Remove Filters…') - as far as I can tell it renders as expected in Firefox, Chromium, Opera and Safari.

IMHO this is a duplicate of
Bug #233800 "Moving an object through a layer with blending options causes the object to adopt blending options "
<https://bugs.launchpad.net/inkscape/+bug/233800>

[su_v (suv-lp)]

Whether or not Inkscape's new renderer (in trunk) is correct to not render the straight horizontal/vertical lines with such a blend effect applied should be filed and discussed separately if you think this is an incorrect implementation of the SVG 1.1 specification (Other SVG viewers seem to disagree among themselves, and I can't tell who is correctly implementing the specification: blurs applied to such lines make them disappear as well, as discussed in bug #168943).

View attached sample test case [1] in different display modes (menu 'View > Display mode > Normal' and 'View > Display mode > No Filter') to see which objects are affected (those with only one dimension), as well as in different browsers.

[1] in this example the blend mode has been intentionally transferred from a layer to objects on a different layer

[David Mathog (mathog)]

Thanks for the view -> display mode -> no filters, I was not aware of that setting. There was no intent to filter anything in this drawing, it must have been enabled by an errant mouse click or erroneous keyboard shortcut.

from post 3: 'the message on the status line in Inkscape when selecting such an object gives the necessary hint ("filtered").'

But it doesn't, at least not reliably. Turn on View -> display mode -> no filters, ungroup the graph part of the drawing one level.

Then:

1. Select just the column of ticks on the left side of the rectangle, look at the bottom
of the screen - there is no mention of "filtered".

2. Select everything on the left side of the rectangle (axis label, ticks, and tick labels) and again the bottom of the screen says nothing about filtered.

3. select tick labels, again, no "filtered".

4. select the single axis label - this shows "filtered".

It seems like if some or all members of a set or group of objects are filtered that message will not be shown. It is shown only when a single object is selected. To verify that

5. ungroup all of the tick labels, select one, now it shows "filtered"
6. with the tick labels still ungrouped, select two, Now it says "2 objects of type Text in layer Layer 1", and nothing about them being filtered.

It would be much more informative if this messages:

  N objects <of type X<,of type Y,<...>> in layer Layer 1

became

  N objects <of type X<,of type Y,<...>>; filtered in layer Layer 1

(filtered in italics as for single objects). Possibly with the extra modification that filtered would be half italics
if some where filtered, and some were not. That is, two text objects, one filtered, one not

  2 objects of type Text; [I]filt[/I]ered in layer Layer 1

Other variations on this theme would be as good or better. For instance, a filter icon on the bottom row to the right of the lock icon. It is grayed out if there are no filters active in the selected objects, outlined if at least one filter is present, and progressively filled up or colored as the fraction of filtered objects selected increases. Clicking on that icon would toggle the view between filters on and filters off.

In any case, thanks for the help, I can complete that drawing now.

[su_v (suv-lp)]

<off-topic>
> There was no intent to filter anything in this drawing, it must have
> been enabled by an errant mouse click or erroneous keyboard shortcut.

I already explained how these layer blend modes usually get transferred to objects.

> But it doesn't, at least not reliably. Turn on View -> display mode -> no filters,
> ungroup the graph part of the drawing one level.

Note I: You seem to use a different drawing file now: in the one you had originally attached (and which I did take a look at), there is no such group. I cannot comment on the steps 1-6 and your conclusions.

Note II: I was careful to use the phrase "when selecting such an object" - this does not refer to a selection of multiple objects with possibly different attributes. My description was also based on the document against which the report was filed (which has all objects directly on Layer 1 (not grouped).
</off-topic>

Since this gets off-topic with regard to the original bug report, and probably is more a question about usage and user interface design, I'll leave it to others to comment/close/further triage the report, also to decide whether to further investigate what was detailed in comment #4 in a separate report.

[David Mathog (mathog)]

Here are some changes that result in the selected object(s) showing "<count> filtered", so long as count >=1 and the number selected is >1. However, this code does not drill down within a Group to see if some grouped objects are filtered. So the selected group itself is filtered, then "filtered" shows up, but if the group is composed of objects, and some of those are filtered, then it does not trigger the "filtered" message. It doesn't try to keep track of what type of filtered, as
in a complex drawing there might be many, many different filters in use at once, which would overfill the status line.

Changes relative to trunk (2/29/2012):

 diff sp-item.h.dist sp-item.h
194a195
> int ifilt();

diff sp-item.cpp sp-item.cpp.dist
966,978d965
< * Returns 1 if the item is filtered, 0 otherwise. Used with groups/lists to determine how many, or if any, are filtered
< *
< */
< int SPItem::ifilt()
< {
< int retval=0;
< if (((SPItemClass *) G_OBJECT_GET_CLASS(this))->description) {
< if ( style && style->filter.href && style->filter.href->getObject() ) { retval=1; }
< }
< return retval;
< }
<
< /**

 diff selection-describer.cpp selection-describer.cpp.dist
94,105d93
< // Returns the number of filtered items in the list
< int count_filtered (GSList *items)
< {
< int count=0;
< SPItem *item=NULL;
< for (GSList *i = items; i != NULL; i = i->next) {
< item = SP_ITEM(i->data);
< count += item->ifilt();
< }
< return count;
< }
<
245a234
> _context.setF(Inkscape::NORMAL_MESSAGE, _("%s%s. %s."), objects_str, in_phrase, _when_selected);
247,257d235
< // indicate all, some, or none filtered
< const gchar *filt_str =NULL;
< int n_filt = count_filtered ((GSList *)items); //all filtered
< if(n_filt){
< filt_str = g_strdup_printf (_("; <i>%d filtered</i> "),n_filt);
< }
< else {
< filt_str = g_strdup_printf ("");
< }
<
< _context.setF(Inkscape::NORMAL_MESSAGE, _("%s%s%s. %s."), objects_str, filt_str, in_phrase, _when_selected);
260,261d237
< if (filt_str)
< g_free ((gchar *) filt_str);

In the attached screen shot there are two filtered individual objects and one pair of objects grouped which was then filtered. That counts as 3 filtered, which is what is shown in the message at the bottom.

[David Mathog (mathog)]

Hmm, that stripped out spaces. Here are those diff -u's again, all in one text file.

[David Mathog (mathog)]

Can somebody please put this patch in?

It was (re)generated against revision 11289. All it does is add an extra information field to the status line, so that in addition to listing the number of objects selected, it also shows how many of these are filtered. This is useful in those situations where they cannot be filtered, as when exporting to EMF. It does not enter grouped objects to look for this information, but if this is important to know one may ungroup the selection.

[David Mathog (mathog)]

Example showing what the patch does. 4 objects, the two within the red line are filtered, and that is shown in the status line.

[jazzynico (jazzynico)]

Patch tested successfully on Windows XP, Inkscape revision 11342.
I'm going to test it on Ubuntu a bit later.

[jazzynico (jazzynico)]

Patch committed in the trunk, revision 11355.
I've just modified the string so that it can be correctly translated (single and plural forms).

Thanks for your patch, David!

[su_v (suv-lp)]

JazzyNico wrote:
> Patch committed in the trunk, revision 11355.

Can we close this report then? About the originally reported problem, see earlier comments #3, #4 and #6 (AFAIU the report is about an unfortunate combination of two known "issues" each already tracked in separate reports: bug #168943, bug #233800).

[David Mathog (mathog)]

This one can be closed.

The underlying issue (as I see it) has been posted as a wishlist item as bug 998094