Currently PSoutputDev:: forces rasterization whenever the pdf (page?) has any tranparency or uses pattern image masks. Instead it, as cairo does, should limit rasterization to the size of the non-opaque regions. In particular, if the only non-opaque objects are images, then those images should be pre-composed and treated as opaque images. Non-opaque images directly on the background should be composed to white. Non-opaque images atop a constant opaque vector or image object should be composed to said underlying object’s constant colour and then opaquely painted atop the object. For everything else, the area with non-opaque objects can be rasterized as the whole page currently is. Looking at PSOutputDev::, this will take some work.
I started looking at what would be involved in implementing finer-grained fallbacks in PSOutputDev. The first problem I found is how do we handle color spaces? In cairo PS output everything is in the DeviceRGB color space. When a fallback image is adjacent to vector graphics the colors match exactly. In PSOutputDev each object can have a different color space. When pdftops outputs a fallback image the DeviceRGB color space is used (except for certain cases like -level1 or the separation modes where DeviceGray or DeviceCMYK is used). What color space should the fallback images use to ensure that the colors match vector objects that intersect the images? As for implementation of finer-grained fallbacks I'm not planning to do anything fancy like handle drawing translucent colors on top of opaque colors. I would implement something similar to the way I implemented finer-grained fallbacks in cairo. ie when there is nothing under an object, blend it into white. When there is something else under the object, add the bounding box of the object to the region(s) to be emitted as fallback images. After outputting all the vector objects, draw the fallback images on top.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/344.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.