Shading pattern bug with stitching functions

Question

I am using Acrobat Professional 7 for Windows, but I don't believe the situation has changed in Acrobat 9.
I have a simple hand-crafted pdf that is designed to test shading patterns with extend regions when used with stitching (Type 3) functions. These behave according to the spec in most cases, but there is a special case where they don't. I've included the job at the end of this message.
The special case is where a Bounds entry is identical to one of the Domain values. The spec doesn't say what should happen for this case, but I might expect either the end child function would be ignored, or that it is used but the appropriate colour would be evaluated using it and applied to the extend region.
What in fact happens, is that the extend regions have their colour derived from evaluating 0 or 1 through the end child functions. This is true regardless of whether the shading domain includes zero. But, these are used the wrong way round.
This might seem like a specialised case that would never appear in the field from real world application, but that is not the case. I have dozens of such jobs from customers displaying exactly this problem with varying workarounds by producers such as (Agfa Apogee Normalizer), (Acrobat Distiller 6.0 \(Windows\)), (Adobe PDF library 7.77), (Creo Normalizer JTP ver. 3.1.6), (Adobe PDF Library 8.0).
In more detail, the job has one radial shading pattern using a stitching function with 6 child functions. The first child function coincides with the function domain, as do the last two child functions. The domain of the shading is a subset of the stitching function, arranged so that the end child functions should never be evaluated.
I believe the whole of the shading should be a solid cyan because the domain is 0.3 to 0.7. Only one of the child functions covers this range which is solid cyan. Acrobat displays the inner extended region as black which can only be explained by pushing 1 through the first child function, and the outer extended region is yellow which can only be explained by pushing 0 through the final child function.
I believe Acrobat should be using the shading domain limits for the extend regions. Instead, it is using 0 and 1. But worse, the values are being used the wrong way round.
This is my hand-crafted job for testing shading patterns with Type 3 functions. The job is hand crafted, and I haven't gone to the trouble of setting the xref table or setting the stream lengths, but Acrobat does repair the file and it behaves the same as other, real-world, jobs
%PDF-1.4
%âãÏÓ
1 0 obj
<<
/Type /Catalog
/Pages 2 0 R
>>
endobj
2 0 obj
<<
/Type /Pages
/Count 1
/Kids [4 0 R ]
>>
endobj
3 0 obj
<< % Info dictionary
/Title (FunctionType 3 boundary test)
/CreationDate (D:20051118000000-00'00')
/Author (John Jefferies)
>>
endobj
4 0 obj
<< % Page 1
/Type /Page
/Parent 2 0 R
/Resources 5 0 R
/MediaBox [0 0 300 300]
/Contents [6 0 R]
>>
endobj
5 0 obj
<< % Resources Groups
/Shading <<
/Radial 7 0 R
>>
/ProcSet [/PDF]
>>
endobj
6 0 obj
<< % Page contents
/Length 1
>>
stream
q 1 0 0 1 0 0 cm /Radial sh Q
endstream
endobj
7 0 obj
<< % Radial shading covering group
/ShadingType 3
/ColorSpace /DeviceCMYK
/BBox [0 0 300 300]
/Coords [150 150 30 150 150 175]
/Function 8 0 R
/Domain [0.3 0.7]
/Extend [true true]
>>
endobj
8 0 obj
<< % Function for shadings
/FunctionType 3
/Domain [0 1]
/Range [0 1 0 1 0 1 0 1]
/Functions [9 0 R 10 0 R 11 0 R 12 0 R 13 0 R 14 0 R]
/Bounds [0 0.25 0.25 1 1]
/Encode [0 1 0 1 0 1 0 1 0 1 0 1]
>>
endobj
9 0 obj
<< % Function for shadings: Red - Black
/FunctionType 2
/Domain [0 1]
/Range [0 1 0 1 0 1 0 1]
/C0 [0 1 1 0]
/C1 [0 0 0 1]
/N 1
>>
endobj
10 0 obj
<< % Function for shadings: Green
/FunctionType 2
/Domain [0 1]
/Range [0 1 0 1 0 1 0 1]
/C0 [1 0 1 0]
/C1 [1 0 1 0]
/N 1
>>
endob

Answer 1

Philip, thankyou for offering to look at this.
I have attached 'FunctionType 3 boundary.pdf' which was the original file I attempted to post. The file 'AcrOut Domain 0_3-0_7.png' makes it clear what I am seeing in Acrobat. I would also like to augment my original post a little to point out incompatibilities between Acrobat and CPSI.
1. From my PoV, compatibility between Acrobat and CPSI is important, so I've also attached a file that contains equivalent PostScript. On my Ricoh Aficio with CPSI (3016.203) inside it, the job is rendered in solid cyan as I would expect given that the domain of the shading is restricted to [0.3 0.7].
2. If the jobs are changed to make the shading domain [0 1] instead of [0.3 0.7], Acrobat displays a green ring (expected), and the inner extend region is now red (expected). The outer extend region remains yellow.
CPSI renders the job almost the same as Acrobat, but the outer extend region is painted in cyan, not yellow. An Nth reading of the PDF and PS specs has revealed a subtle difference; there is one sentence in the stitching function section of the PDF spec not present in the PS spec, it is "If the last bound, Bounds(k−2) , is equal to Domain(1) , then x′ is defined to be Encode(2i)". I take this to mean the outer extends region may have different color in the PDF and PS versions by design.
3. If the pdf job is changed to make the shading domain [0.01 0.99], Acrobat displays the inner extend in black as before (unexpected), otherwise the same as 2).
To summarise:
1. There appears to be a bug in Acrobat whereby it ignores domain of the shading when painting the extend regions.
2. There is an incompatibility between Acrobat and CPSI in the outer extends region when the final Bounds entry is equal to the Domain value. This may be by design.