When sending attached testfile ResourceDictionary.xps the last rectangle should be filled with a 'E' (using a glyph as fill in a VisualBrush.Visual). The rectangle however is not visible (second page shows what is expected). It looks like the pattern is not correctly created (i.e. not using the 'E' as tile).
Created attachment 5240 [details] ResourceDictionary.xps xps testfile (second page shows expected output). 'E' filled box is missing on 1th page.
Setting customer priority.
Reproduced with ghostpdl r9973 + gs r9980 on Mac OS X. During execution, gxps made some complaints. $ xps/obj/gxps ResourceDictionary.xps + ../xps/xpscolor.c:178: xps_parse_color(): cannot parse color ({StaticResource Fill2}) + ../xps/xpscolor.c:178: xps_parse_color(): cannot parse color ({StaticResource Fill1}) + ../xps/xpscolor.c:178: xps_parse_color(): cannot parse color ({StaticResource Fill1}) + ../xps/xpscolor.c:178: xps_parse_color(): cannot parse color ({StaticResource Fill}) xps: page /Documents/1/Pages/1.fpage has transparency + ../xps/xpsglyphs.c:577: xps_parse_glyphs(): cannot find font resource part '/Documents/1/Pages/f250f83a-158c-4a2b-93ab-213c7e7bb5b6.ODTTF' End of page 1, press <enter> to continue. xps: page /Documents/1/Pages/2.fpage does not have transparency GPL Ghostscript SVN PRE-RELEASE 8.71: Some glyphs of the font ArialMT requires a patented True Type interpreter. End of page 2, press <enter> to continue. $
The complaints come from the function xps_parse_color() being used during determining if a color is transparant (i.e. it decodes the color into 4 bytes, highest byte is then checked for being < 0xff (transparancy). During processing of the page the StaticResource is handled correctly.
The "cannot parse color {StaticResource}" warnings during analysis are irrelevant when scanning for transparency; the resource dictionary is scanned separately and any transparency in referenced resources is going to be found there.
Note that the problem (comment #1) is still not fixed. The 'warning' messages as mentioned in comment #3 have no priority.
+ ../xps/xpsglyphs.c:577: xps_parse_glyphs(): cannot find font resource part '/Documents/1/Pages/f250f83a-158c-4a2b-93ab-213c7e7bb5b6.ODTTF' It looks like we're using the wrong path for resolving relative paths in this instance, where the font is being referenced from an external resource dictionary.
r10107: Thread base_uri argument to fixed page parsing functions so that resources specified with relative paths can be resolved in the right context.