OK, I'm changing over to 4 spaces. You're right, SCite has that option. I'm trying to run ant checkstyle, but am getting a UnsupportedClassVersionError. I think this is b/c I'm running jdk 1.4 -- which I'm doing to ensure I do not accidentally introduce something supported only in newer versions of Java.
Do you have suggestions on this? >> I read this as only relevant if you are using DataBuffer.TYPE_BYTE (for example) and per component less than 8 bits are used. Which is exactly what we're dealing with. Is there a better way to initialize the array? Providing it with the number of elements it needs? Thanks. Daniel Wilson On Wed, Apr 29, 2009 at 4:53 PM, Philipp Koch <[email protected]> wrote: > > Tab characters -- sorry, do those mess others up? I always found Tab > much > > cleaner for indentation than trying to remember how many times to hit the > > Space bar. > you can configure your ide so that the tab is automatically replaced > by 4 spaces. > > regards, > philipp > > On Wed, Apr 29, 2009 at 10:43 PM, Daniel Wilson > <[email protected]> wrote: > > Tab characters -- sorry, do those mess others up? I always found Tab > much > > cleaner for indentation than trying to remember how many times to hit the > > Space bar. > > > >>>Not all ICC color profiles have 4 components. > > > > True. It appeared to me that the only problems arose with the array was > too > > short, not when it was too long. > > > > > http://java.sun.com/j2se/1.4.2/docs/api/java/awt/image/ComponentColorModel.html#ComponentColorModel(java.awt.color.ColorSpace,%20int[],%20boolean,%20boolean,%20int,%20int)<http://java.sun.com/j2se/1.4.2/docs/api/java/awt/image/ComponentColorModel.html#ComponentColorModel%28java.awt.color.ColorSpace,%20int%5B%5D,%20boolean,%20boolean,%20int,%20int%29> > > > > Am I misunderstanding that? Is there a better way to initialize this > array > > based on the number of components? > > > > Thanks! > > > > Daniel Wilson > > > > On Wed, Apr 29, 2009 at 4:35 PM, Jeremias Maerki <[email protected] > >wrote: > > > >> Glad I could help. But I saw that you've introduced some tab characters > >> into the sources. I guess it would be great if you would change the IDE > >> settings for the PDFBox project. Also, I'm not sure if the following > >> always works. Not all ICC color profiles have 4 components. > >> > >> Seen in PDICCBased.java: > >> - int[] nbBits = { bpc, bpc, bpc }; > >> + int[] nbBits = { bpc, bpc, bpc, bpc }; //added 4th bpc to > handle > >> CMYK > >> > >> > >> On 29.04.2009 21:22:50 Daniel Wilson wrote: > >> > Jeremias, you got me very close. That part of the work is now > committed. > >> > Thanks for the help! > >> > > >> > Daniel > >> > > >> > On Wed, Apr 29, 2009 at 7:46 AM, Daniel Wilson < > >> > [email protected]> wrote: > >> > > >> > > Thanks, Jeremias! > >> > > > >> > > That makes sense. I'll try implementing it & may have a couple more > >> > > questions. > >> > > > >> > > Daniel Wilson > >> > > > >> > > > >> > > On Wed, Apr 29, 2009 at 3:01 AM, Jeremias Maerki > >> <[email protected]>wrote: > >> > > > >> > >> As noted in another thread, bitmaps with 1bpp (or generally > speaking: > >> > >> bitmaps with less than 8 bits per pixels) should be represented in > >> > >> memory using the IndexColorModel, i.e. a color lookup table. That > way > >> > >> the pixels don't have to be extended to their full color values. > The > >> > >> problem with the CMYK color space is that > >> java.awt.image.IndexColorModel > >> > >> only supports sRGB. So you may end up with implementing a new > >> ColorModel > >> > >> subclass which can represent non-sRGB colors. Of course, you could > >> also > >> > >> map the CMYK colors to sRGB and still use IndexColorModel but if > >> someone > >> > >> came an wanted a CMYK TIFF representation of a PDF, you'd have two > >> color > >> > >> conversions involved which could have all sorts of side-effects. > But > >> > >> that is certainly advanced stuff that could probably be handled at > >> some > >> > >> later point. > >> > >> > >> > >> Here's an example of an IndexColorModel for an RGB-based 1bpp > image: > >> > >> byte[] map = new byte[] {(byte)0x00, (byte)0xff}; > >> > >> ColorModel cm = new IndexColorModel(1, 2, map, map, map); > >> > >> > >> > >> That's just the color model with the lookup table. The other key > >> element > >> > >> is the DataBuffer instance (on which the Raster instance will > operate) > >> > >> with > >> > >> the correct SampleModel. For 1bpp, this should in the end be a > >> > >> java.awt.image.MultiPixelPackedSampleModel, for example: > >> > >> > >> > >> MultiPixelPackedSampleModel packedSampleModel = new > >> > >> MultiPixelPackedSampleModel( > >> > >> DataBuffer.TYPE_BYTE, img.getWidth(), img.getHeight(), 1); > >> > >> > >> > >> AFAICT, the approach with creating a ColorModel instance in the > >> > >> PDColorSpace subclass is probably wrong if you want to get an > >> optimized > >> > >> in-memory representation, since the color model just interprets the > >> > >> colors. It doesn't know how the pixels are represented > (SampleModel). > >> > >> Only the XObject itself knows how many bits represent a pixel. > >> > >> > >> > >> HTH > >> > >> > >> > >> On 29.04.2009 03:16:37 Daniel Wilson wrote: > >> > >> > Given a bpc = 1 and a DeviceCMYK color space: > >> > >> > > >> > >> > byte[] array = getPDStream().getByteArray(); > >> > >> > > >> > >> > creates an array with width*height / 8 bytes. > >> > >> > > >> > >> > PDColorSpace colorspace = getColorSpace(); > >> > >> > ColorModel cm = colorspace.createColorModel( bpc ); > >> > >> > WritableRaster raster = cm.createCompatibleWritableRaster( width, > >> height > >> > >> ); > >> > >> > DataBufferByte buffer = (DataBufferByte)raster.getDataBuffer(); > >> > >> > byte[] bufferData = buffer.getData(); > >> > >> > > >> > >> > cm is a ColorModel reporting 32 pixelBits. > >> > >> > bufferData now has width*height * 4 bytes -- or 32 times as many > as > >> > >> array. > >> > >> > > >> > >> > > >> > >> > System.arraycopy( array, 0,bufferData, 0, > >> > >> > (array.length<bufferData.length?array.length: bufferData.length) > ); > >> > >> > The ternary in there saves us from a buffer overflow ... but > that's > >> > >> still > >> > >> > the wrong answer. > >> > >> > Just copying a 1-bit/pixel buffer into a 32-bit/pixel buffer > cannot > >> be > >> > >> the > >> > >> > right answer. > >> > >> > > >> > >> > Am I to read each BIT of the source array and convert it to a > 32-bit > >> > >> integer > >> > >> > to write? So 0 becomes 0x00000000 and 1 becomes 0xFFFFFFFF ? > >> > >> > > >> > >> > Or is colorspace.CreateColorModel creating the wrong one? This > >> looks > >> > >> right > >> > >> > ... > >> > >> > > >> > >> > logger().info("testing Sector9's implementation"); > >> > >> > > >> > >> > int[] nbBits = { bpc, bpc, bpc, bpc }; > >> > >> > ComponentColorModel componentColorModel = > >> > >> > new ComponentColorModel( createColorSpace(), > >> > >> > nbBits, > >> > >> > false, > >> > >> > false, > >> > >> > Transparency.OPAQUE, > >> > >> > DataBuffer.TYPE_BYTE ); > >> > >> > > >> > >> > Thanks for your ideas! > >> > >> > > >> > >> > Daniel Wilson > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Jeremias Maerki > >> > >> > >> > >> > >> > > > >> > >> > >> > >> > >> Jeremias Maerki > >> > >> > > >
