By creating a static getInstance() method on the PDFStreamEngine, I got the color space to the appropriate code.
But it isn't changing the rendering at all. So I'll keep digging. And I'll address the concerns I have about the getInstance() method in the thread I started about a Singleton. I very much appreciate your continued suggestions! On Wed, Apr 22, 2009 at 6:59 PM, Daniel Wilson < williamstonconsult...@gmail.com> wrote: > Actually the colorspaces are maintained in the GraphicsState that belongs > to the PDFStreamEngine. > > Both PDFPageDrawer and PDFTextStripper extend PDFStreamEngine. I think > it's safe to say that any manipulation of a PDF will involve a > PDFStreamEngine. > > But ... that doesn't mean the PDXObject can access it. > > Am I missing something in the object model? > > > On Wed, Apr 22, 2009 at 6:05 PM, Daniel Wilson < > williamstonconsult...@gmail.com> wrote: > >> I'm working on this again, and I'm sure you're right, Andreas, that the >> ImageMask flag is key here. >> >> But I think the solution is much simpler than any of us have been making >> it. Both of you say we need to somehow get it to return the right >> colorspace. >> >> On an ImageMask, the XObject doesn't specify the colorspace. It's the >> <b>current nonstroking colorspace</b>. >> >> Current code is asking the XObject for the colorspace -- which in every >> other case is true. >> >> Solution? >> 1. Check if it's an ImageMask -- which should be trivial. >> 2. If so, return the current nonstroking colorspace, NOT something from >> the XObject. >> >> So ... how does the XObject access the current nonstroking colorspace? >> Isn't that maintained in the pdfbox.pdfviewer.PageDrawer? >> >> Thanks! >> >> Daniel Wilson >> >> 2009/4/16 Andreas Lehmkühler <andr...@lehmi.de> >> >> > An other option is the source itself. It's not that difficult to read a >>> > pdf-file and it's sometimes easier to read the source than debugging >>> the >>> > app. As most of the pdfs are compressed you've to decompress them. I've >>> > already thought about a little tool based on pdfbox, but I didn't found >>> the >>> > time ... yet. For the moment I'm using a freeware tool from here [1] to >>> > decompress pdf-docs. >>> >>> I've a closer look into the source and found the follwing XObject. It >>> seems to be one of the 2 images. >>> >>> ... >>> 21 0 obj >>> << >>> /Intent /RelativeColorimetric >>> /Subtype /Image >>> /Length 178200 >>> /Name /X >>> /ImageMask true >>> /BitsPerComponent 1 >>> /Width 1188 >>> /DecodeParms << >>> /Columns 1188 >>> /Predictor 15 >>> /BitsPerComponent 1 >>> /Colors 1 >>> >> >>> /Height 1188 >>> /Type /XObject >>> /Decode [ 0 1 ] >>> >> >>> stream >>> ... >>> >>> The parameter /ImageMask is the interesting one (from the pdf1.7 >>> reference): >>> >>> "(Optional) A flag indicating whether the image is to be treated as an >>> image mask (see Section 4.8.5, “Masked Images”). If this flag is true, the >>> value of BitsPerComponent must be 1 and Mask and ColorSpace should not be >>> specified; unmasked areas are painted using the current nonstroking color. >>> Default value: false." >>> >>> An other part of the pdf source looks like this: >>> >>> .. >>> /CS1 cs 1 scn >>> 792.0003815 0 0 792.0003815 0 -0.0003815 cm >>> /Im0 Do >>> .. >>> >>> Just right before the image is drawn (/Im0 Do) the nonstroking colorspace >>> is set to CS1 (/CS1 cs). >>> >>> And CS1 is defined through object 26 as follows >>> >>> ... >>> 26 0 obj >>> [ /Separation /RHUBARB#202 24 0 R << >>> /C0 [ 0 0 0 0 ] >>> /C1 [ 0.0599976 1 0.889999 0.580002 ] >>> /FunctionType 2 >>> /N 1 >>> /Domain [ 0 1 ] >>> /Range [ 0 1 0 1 0 1 0 1 ] >>> >> ] >>> endobj >>> ... >>> >>> So, I guess the is something wrong between setting the cs and getting the >>> cs in PDXObjectImage.getColorSpace. >>> >>> Andreas Lehmkühler >>> >>> >> >
