Educating the Confused – Hermitian on the WH PDF

Just quite recently our friend Hermitian wrote at Dr C’s site the following response to Vicklund’s proposed workflow. Note how Vicklund’s predictions were quite accurate.
Hermitian June 12, 2013 at 4:52 pm #

VICKLAND [NBC: He probably means Vicklund…]

Let’s review the likely flow:
1. The original document is scanned by a Xerox machine in Landscape mode.

Hermitian: So your Xerox scanner scans 8.5 in. X 11 in. Pages in landscape orientation. You’ve got to be kidding.

[NBC: Check out how the scan on a xerox scanner happens when you feed it through its document feeder. I have shown how this is exactly what happens…]

Vicklund: 2. The scanner optimizes the raw image to create the PDF.

Hermitian:And you are claiming that there was no single raw bitmap image but rather nine bitmap images that were created by the scanner in nine different data streams (on the fly) and then optimized and assembled into the final PDF? And this scanner was supplied with your “Magic MRC software utility.

[NBC: As we have shown now, Xerox WorkCentre does exactly this… Ouch]

Hermitian: Funny that no Obot has been able to identify either the scanner or the software that created the WH LFCOLB PDF file.

[NBC: Oh the irony… Only a few weeks later…]

Vicklund: 3. In the process of optimizing the image, the software uses the previously mentioned patent to split the image into one background 8-bit color layer at 150 dpi* and eight 1-bit monochrome layers at 300 dpi (the layers with random white spots filling out two layers to complete the set of eight).

Hermitian: Prove it !!!

[NBC: Done… Funny how Hermitian is so intent on ‘proof’ but fails to provide any evidence for his own scenarios…]

Vicklund: 4. The rectangular segments for the monochrome layers have start points at the edge of 8×8 blocks, and end points at the far edges of the included monochrome image.

Hermitian: Wrong !!!

[NBC: Actually, spot on…]

Hermitian: When in their final embedded positions, the top and right edges of each rectangle are congruent with a grid of 8 X 8 blocks of 300 PPI X 300 PPI pixels but only if the rulers origin is moved from the upper left corner of the 81/2 in. X 11 in. page of the Artboard to the bottom left corner of the rectangular boundary of the background layer.

[NBC: Exactly. Thanks for verifying Vicklund’s claim. And the answer to this is quite simple. The document was fed into the scanner upside down and subsequently rotate 270 degrees.. Perhaps Hermitian is also not familiar that the natural coordinate system in a PDF starts at the bottom left corner? In Illustrator the conventions were changed with CS5. I can see why Hermitian may be confused here. Again the low level data would have set him straight.]

The bottom and left sides of each rectangle are congruent with one side (of at least one) 1/300 in. X 1/300 in. pixel (of at least one) text or handwritten character contained within that rectangular object.

All four edges of all nine rectangular object boundaries are congruent with the higher resolution grid of 300 PPI X 300 PPI.

Each and every pixel of the eight high-resolutions images are congruent with a grid of 300 PPI X 300 PPI resolution.

[NBC: Other than the ones that are not 🙂 But that’s just a minor detail… As I showed some of the edges when divided by 8 result in odd coordinates which of course result in 0.5 in the 300×300 DPI coordinate system.]

Each and every pixel of the low-resolution background image is congruent with a grid of 150 PPI X 150 PPI.

[NBC: Of course, they are aligned with the 8×8 bit JPEG blocks… Nothing remarkable here.]

All the pixels of the background image are offset by one high resolution pixel in the horizontal direction. The low-resolution pixels are not offset relative to the high-resolution pixels in the vertical direction.

[NBC: Time to more carefully check my friend… The raw data dump is your friend…]

Vicklund:5. The coordinate origin is in the top left corner. The background image is compressed as a JPEG and the monochrome layers are compressed using JBIG2. The optimized PDF file is saved to the computer.
The DCTDecode filter was applied to the one 8-Bit layer and FlateDecode filter was applied to all the other layers. These filters were read directly from the text within the LFCOLB PDF file when loaded into WordPad.

The optimized file is then opened in Mac Preview. The overall image is in Landscape, so the operator rotates the image 90 degrees. All layers rotate clockwise, keeping the same relative position. The operator then realizes the image extends past the printer margins, so crops the overall image to create aw ide enough margin. The operator then renames and saves the slightly modified file, using the suggested compression settings of JPEG/DCT for color layers and flate for monochrome layers. Since there is no loss when rotating a JPEG, the background image is compressed rotated. However, since flate is not lossless when rotating images, the monochrome layers are compressed at their original orientation (with an instruction to rotate when reconstructing the file). The file can now be printed (btw, Macs print at 72 dpi) and uploaded to the net. *It is also possible that the lower resolution for the background image wasn’t generated until compression in Preview.

Hermitian: I won’t bother to try to untangle your mess here. Let’s just deal with the question of whether or not Preview can edit individual layers in multilayer PDF documents. Fortunately someone else already asked that question at this forum

[NBC: Totally missing the point.  Vicklund never suggested that individual layers were edited but rather how Preview read and saved the objects when saving to PDF 1.3. And now that we have the forger identified, we have done the experiments. It’s time to share some more data with our confused friend here.]

PDF Layers in Apple Preview?

You are not going to like the answers that he got.

Use Adobe Reader !!!

You aren’t suggesting that Preview’s file compression is based on MRC are you?

[NBC: Nope. He never did say this…]

There is more about clipping layers etc and since our friend relies on Illustrator and other high level tools, he totally missed the tell tale signs.

That’s unfortunate but I am sure he will now reconsider his position? Or provide a more likely scenario… Either way…

He tried:

The WF LFCOLB was most likely created on a MAC computer using MAC Illustrator and then run through Preview to strip out the Adobe METADATA. That works for me.

and failed…

But to use his own words: Prove it… So far he has done nothing of the kind…