Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: 4.3.3
-
Fix Version/s: 4.3.4
-
Component/s: Core/Parsing
-
Labels:None
-
Environment:any
Description
A client has reported that they are having difficulty converting a few documents to image. During the capture process the user is allowed to pick one of the following capture type colour modes for the resulting buffered image:
// type is a given method-parameter - the user can define the ImageType
// possible values:
// - BufferedImage.TYPE_BYTE_GRAY
// - BufferedImage.TYPE_BYTE_BINARY
// - BufferedImage.TYPE_INT_RGB
There is a logo in the document in question that contains a gradient. If the buffered image type is gray or binary the batik library we use for pattern paint will fail. It should be relatively straight foward to catch the exception and use a solid fill instead of the gradient paint. A check for a newer version of the pattern pain class would also be another good idea.
// type is a given method-parameter - the user can define the ImageType
// possible values:
// - BufferedImage.TYPE_BYTE_GRAY
// - BufferedImage.TYPE_BYTE_BINARY
// - BufferedImage.TYPE_INT_RGB
There is a logo in the document in question that contains a gradient. If the buffered image type is gray or binary the batik library we use for pattern paint will fail. It should be relatively straight foward to catch the exception and use a solid fill instead of the gradient paint. A check for a newer version of the pattern pain class would also be another good idea.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Updated the MultipleGradientPaintContext class to support Gray colour space model. This fixes the unsupported exception that was being through. The PDF content stream now renders correctly when doing a page capture to a buffered image of type TYPE_BYTE_GRAY.