Pattern fill with bitmap not shown in browsers

[David Mathog]

The SVG that Inkscape uses for using a bitmap as a pattern seems to be incompatible with firefox, seamonkey, and opera, none
of which filled with the bitmap. Inkscape itself fills. I suppose that it is possible that all of those browsers have a problem in this area, but it seems likely that Inkscape may be doing something a bit unusual here.

[David Mathog (mathog)]

Sorry, hit post too soon. In the attachment SVG look for the lines which contain EMFimage. These show up correctly in Inkscape (the two rows of expanding squares, the upper row colored, the lower row "monochrome", but in firefox & seamonkey & Opera they are empty (no fill).

[David Mathog (mathog)]

The SVG made by inkscape has this in <defs>

    <pattern
       y="0"
       x="0"
       height="4"
       width="4"
       patternUnits="userSpaceOnUse"
       id="EMFimage1">
      <image
         id="image3992"
         xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAQAAAAECAIAAAAmkwkpAAAAFUlEQVQImWMMDQ1lgAEmBiTAglMGAEruAgjcYZR9AAAAAElFTkSuQmCC" />
    </pattern>

And this where it is used

    <path
       d="m 174.74529,338.99085 2.24993,0 0,2.24994 -2.24993,0 z"
       id="path4516"
       style="fill:url(#EMFimage1);fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:8;stroke-opacity:1;stroke-dasharray:none" />

I have read through these a couple of times and they look OK to me. Anybody see what the problem might be???

Thanks.

[David Mathog (mathog)]

The pattern has to be like this for the browsers to use it (at least the width & height fields within <image>):

    <pattern
       height="4"
       width="4"
       y="0"
       x="0"
       patternUnits="userSpaceOnUse"
       id="EMFimage1">
      <image
         id="image3992"
         height="4"
         width="4"
         y="0"
         x="0"
         xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAQAAAAECAIAAAAmkwkpAAAAFUlEQVQImWMMDQ1lgAEmBiTAglMGAEruAgjcYZR9AAAAAElFTkSuQmCC" />
    </pattern>

This came up in the context of a bitmap pattern import from EMF and my own patch. I have modified my code to add the extra fields and Inkscape retains them.

This might still be considered a bug though. If inkscape reads an <image> tag missing width and height it does not add them, and the resulting SVG on save will not render properly. Presumably when it processes the file it unpacks the png into
an RGB, so it should be able to determine width and height.

[su_v (suv-lp)]

Related section in the SVG specification:
<http://www.w3.org/TR/SVG11/struct.html#ImageElementWidthAttribute>

«The width of the rectangular region into which the referenced document is placed.
A negative value is an error (see Error processing). A value of zero disables rendering of the element.»

[su_v (suv-lp)]

> This might still be considered a bug though. If inkscape reads an <image>
> tag missing width and height it does not add them, and the resulting
> SVG on save will not render properly.

I disagree. When Inkscape _renders_ an SVG file it's not supposed to _modify_ the SVG source of the content itself (based on the assumption that the original author of the content didn't intentionally omit those attributes to prevent the image from rendering).

SVG compliance has two sides:

1) writing and editing SVG:
Bitmap images imported in Inkscape (and pattern fills created based on them) always have a width/height attribute. No bug here.

You can intentionally delete the width/height attributes of an embedded or linked bitmap image via 'Edit > XML Editor', and they are added back as soon as the image is edited with normal tools (e.g. moved with the select tool).

2) rendering SVG (its own, or created by third-party applications, or by uncommitted patches):
AFAIU the error here is that Inkscape should _not_ render the pattern fill (to conform to the SVG specification, and display the content the same as other SVG viewers).

[David Mathog (mathog)]

Is this the situation?

1. leaving out width in <image> defaults that field to 0
2. a width of zero should disable drawing (post 6)
3. so inkscape should not fill the pattern with the image either

(1) is an inference on my part, for all I know the SVG standard may not say what happens when that field is left undefined.

[su_v (suv-lp)]

> 1. leaving out width in <image> defaults that field to 0

> (1) is an inference on my part, for all I know the SVG standard
> may not say what happens when that field is left undefined.

Probably needs further investigation - OTOH even Inkscape interprets the SVG spec like this:
1) import a bitmap image
2) delete width/height attributes in the XML Edior
3) convert the selected image to pattern with 'Alt+I'

Result: the image disappears, the <image> element in the pattern definition has width = height = 0 added -> rendering of the bitmap image in the pattern is effectively disabled.

[su_v (suv-lp)]

> (1) is an inference on my part, for all I know the SVG standard
> may not say what happens when that field is left undefined.

Squiggle (Batik 1.8pre) - Inkscape's main reference SVG implementation - complains about a missing attribute when opening the SVG file from comment #2:
> The attribute "width" of the element <image> is required
and stops processing the content after the first error occurs.

 -> batik's interpretation seems to be that width/height for <image> are mandatory attributes.

[David Mathog (mathog)]

Comment 9, please clarify. Are you saying that happens only when width/height are omitted?

Look at the example svg in 5. The two series of expanding squares contains <image> tags in <pattern>, one series is color, the other series is two tone ("monochrome" in Microsoft speak). These fills draw as expected in Inkscape. From what you said in (9) they would be empty.

[su_v (suv-lp)]

> Comment 9, please clarify. Are you saying that happens only when width/height
> are omitted?

Please clarify: what is 'that'?

> Look at the example svg in 5. (…) These fills draw as expected in Inkscape. From what you said in (9) they would be empty.

No. That's not what I said. The SVG file from comment #5 sets both attributes (width, height) for both bitmap images in the two pattern definition to values > 0. Thus the pattern with the bitmap image is correctly rendered (visible in Inkscape and in other SVG viewers).

In comment #9, I simply showed some steps which indicate that when _writing_ SVG code (e.g. when using the command to convert selected object(s) to pattern), Inkscape interprets the missing attributes 'width' and 'height' as being defined as zero, adds them as explicit attributes with value '0' to the <image> element in the pattern definition, and consequently doesn't render the image when the pattern is applied to an object (a value of zero of either attribute disables rendering of the <image> element).

This is separate from the _rendering_ issue of existing SVG code: AFAIU Inkscape should _not_ render the pattern fills when loading the file from comment #2:
- either because the missing attributes (width, height) have the effect as if a value of '0' were specified for each of them (the rendering of the <image> element in the pattern is disabled),
- or because both attributes are indeed mandatory attributes for <image> elements, and Inkscape should not further process objects with such paint servers (since the missing attributes are an error).
As mentioned before, the rendering part needs to be further investigated (does the SVG specification actually say that missing attributes are an error, or that missing attributes imply them being set to zero). AFAIU if 'width' and 'height' missing are actually an error, it needs to be addressed based on Inkscape's SVG error processing in general, else the renderer must be fixed to not render such images due to them having one or both dimensions set to zero.

[Nathan Lee (nathan.lee)]

Two updates: SVG2 allows for width and height not to be explicitly set, and firefox 84.0 and chromium 87.0.4280.88 (Official Build) snap (64-bit) (presumably other browsers too) don't.

resvg, which tries to comply strictly with SVG 1.1, doesn't render the images.