https://bugs.documentfoundation.org/show_bug.cgi?id=128879
--- Comment #11 from Dave Gilbert <[email protected]> --- I've got some sympathy for the pdf code here... Looking at the two PDF attachments, uncompressed and in meld, the biggest differences are the newer one has a bunch of added bitmap/images embedded. Digging into the example screwdriver in inkscape, there are two paths which have hideously complex masking and filling on, and I think they do have a forward reference which I guess Xisco's patch made the reference work and now the PDF code has tried to do masking. In particular, inkscape says path 106 has mask g, fill i, mask g has a reference to fill: url#h (i.e. to the next fill - so not yet defined) gradient h: has a graident transform and is linked back to a nice simple fill c <linearGradient id="c"><stop offset="0" stop-color="#fff"/><stop offset="1"/></linearGradient> <mask id="g" height="50.138" maskUnits="userSpaceOnUse" width="45.542" x="20.098" y="17.939"><g filter="url(#a)"> <path d="m30.168 19.316-10.438 9.329-5.914-6.618 10.439-9.328z" fill="url(#h)"/></g></mask> <linearGradient id="h" gradientTransform="matrix(.7457 -.6663 .6663 .7457 4.3633 147.9164)" gradientUnits="userSpaceOnUse" x1="97.9258" x2="97.9258" xlink:href="#c" y1="-80.3257" y2="-83.1696"/> so I guess it's something to do with the pdf exporters masking code or it's handling those complex fills. Perhaps it just gave up and tried to spit out the image. -- You are receiving this mail because: You are the assignee for the bug.
