This is a follow up to bug 691528: The document at the URL has an inline OCG that should only be rendered for the "Print" target. And http://www.creepingfog.com/grrr/Invite.pdf contains a dozen inline OCGs of which only a few are supposed to be displayed.
Partial fix: http://code.google.com/p/sumatrapdf/source/detail?r=4018
Looks like the inline OCGs in the document from http://code.google.com/p/sumatrapdf/source/detail?r=4022 were a red herring. That document's printing behavior is fixed, if the Print flag for annotations is respected (fix: http://code.google.com/p/sumatrapdf/issues/detail?id=1272 ). The "partial fix" is thus largely complete, except that it doesn't fully implement the visibility calculations PDF would offer for OCGs.
Created attachment 8154 [details] Invite.pdf
I've added (at least initial) support for optional content groups (both inline and XObjects) in my local repo: commit d744ac7f5bd6e64cc834bee3a1cec67a77cbafd3 Author: Robin Watts <robin.watts@artifex.com> Date: Thu Nov 24 19:28:25 2011 +0000 First cut at support for OCGs in mupdf (bug 692314) When opening a file, create a pdf_ocg_descriptor that lists the OCGs in a file. Add a new function to allow us to set the configuration in use (currently just the default one). This sets the states of the OCGs as appropriate. When decoding the file respect the states of the OCGs. This results in Invite.pdf rendering correctly. There is more to be done in this area (with automatic setting of OCGs by language/zoom level etc), but this is a good start. I'll close this bug when that hits the main repo.
Closing