WH7655USDFedRotPreview – 8 bit alignments

Since Hermitian cannot do this himself, here are the calculations. Obtain the (x,y) coordinates of the top right corner. Convert to 300 ppi, calculate distance in pixels to top and right hand side boundary. Again we find the 8 bit alignment. Was this so hard Hermitian?

(x, y) top right corner
(xp, yp)     = (x*300/72, y*300/72)
(xoff, yoff) = (xp-2555, yp+6)
xoff/8, yoff/8
              x      y      xp    yp   xoff  yoff xoff/8 yoff/8
Mostly Text 526.8  207.84  2195   866  360   872   45     109
Random      444.24 309.6   1851  1290  1296  704   88     162
Signature   490.32 680.16  2043  2834  512  2840   64     355
Date        234.96 699.36   979  2914 1576  2920  197     365

Red indicates an error I corrected for the WH7655USDFed results (See comments for my mistake, 360/8 is definitely 45)… Note how they match…

             x        y    xp    yp  xoff  yoff xoff/8 yoff/8
Mostly Text 207.84  85.2   866  355   872   360  109   45
Random      309.6  167.76 1290  699  1296   704  162   88
Signature   680.16 121.68 2834  507  2840   512  355   64
Date Stamp  699.36 377.04 2914 1571  2920  1576  365  197

20 thoughts on “WH7655USDFedRotPreview – 8 bit alignments

  1. I wonder what a “random” layer looks like ?

    ROTFL… You are really running out of material, are you not… Poor Hermitian still refuses to accept that the Xerox workflow continues to explain the artifacts.

  2. NBC

    JBIG2Decode and PBM files only support Black and white images. Your printouts of the .pbm files are B & W. So exactly how does Preview select and then assign the monochrome colors to these B & W images provided by Xerox ?

    If you could post the lines of code where that is done by Preview then we could check behind with other tools.

  3. JBIG2Decode and PBM files only support Black and white images. Your printouts of the .pbm files are B & W. So exactly how does Preview select and then assign the monochrome colors to these B & W images provided by Xerox ?

    You are confused. They support monochrome images, and Xerox assigns a color to each bitmask.

    The code can be found in the PDF, both the raw Xerox and the preview document.

    But this is a test for you my friend… I am not going to help you until you either give up or present us the simple answer.

    It’s so trivial… Good luck

  4. NBC is becoming more “random” by the minute.

    ROTFL…

    You’re a funny dude my friend, but in comparison to some, I hardly am ‘random’.

    So far the score appears to be Hermitian 0 – Obots 3

    And you call me random…

  5. NBC

    From “pdf_reference_1-7.pdf”

    “3.3 Filters

    “Stream filters are introduced in Section 3.2.7, “Stream Objects.” A filter is an
    optional part of the specification of a stream, indicating how the data in the
    stream must be decoded before it is used. For example, if a stream has an
    ASCIIHexDecode filter, an application reading the data in that stream will
    transform the ASCII hexadecimal-encoded data in the stream into binary data.
    An application program that produces a PDF file can encode certain information
    (for example, data for sampled images) to compress it or to convert it to a port-
    able ASCII representation. Then an application that reads (consumes) the PDF
    file can invoke the corresponding decoding filter to convert the information back
    to its original form.

    “The filter or filters for a stream are specified by the Filter entry in the stream’s
    dictionary (or the FFilter entry if the stream is external). Filters can be cascaded
    to form a pipeline that passes the stream through two or more decoding
    transformations in sequence. For example, data encoded using LZW and ASCII
    base-85 encoding (in that order) can be decoded using the following entry in the
    stream dictionary:

    “/Filter [ /ASCII85Decode /LZWDecode ]”

    Thus decode filter ASCII85Decode is applied first followed by LZWDecode second.

    The data was first compressed by LZW and then by ASCII85Decode second.

    For the background layer, in both the Xerox 7535 scan to PDF and the Xerox 7535 / Preview print to PDF files there are two occurrences of FlateDecode and one instance of DCTDecode. in the object stream of both files.

    See: http://www.scribd.com/doc/163345891/Xerox-7535-Scan-to-PDF-vs-Xerox-7535-Scan-to-PDF-Preview-Print-to-PDF

    NBC says there is only DCTDecode in the Preview print to PDF for the background layer.

    NBC doesn’t have a workflow — instead he has a workflood. Unfortunately he has put himself beyond help.

  6. NBC says there is only DCTDecode in the Preview print to PDF for the background layer.

    NBC doesn’t have a workflow — instead he has a workflood. Unfortunately he has put himself beyond help.

    Of course, as there is in the WH LFBC

    For the background layer, in both the Xerox 7535 scan to PDF and the Xerox 7535 / Preview print to PDF files there are two occurrences of FlateDecode and one instance of DCTDecode. in the object stream of both files.

    One DCTDecode yes, but a few more flatedecode objects you seem to have overlooked.

    Who is beyond help here… I know you can cut and paste but can you comprehend… What really was your argument anyway…

    I am here to help you, as I have done so many times before…

  7. I am glad to see however that Hermitian has taken my suggestion to look at the PDF standard seriously, as both I and Kevin quoted from it… Many times…

    Still trying to catch up I notice… But nothing yet that even touches my workflow in any significant manner…

    Good luck my friend

  8. Oh and Hermitian, if you need any help properly decoding the FlateDecode/DCTDecode object …

    ROTFL

  9. NBC

    “”For the background layer, in both the Xerox 7535 scan to PDF and the Xerox 7535 / Preview print to PDF files there are two occurrences of FlateDecode and one instance of DCTDecode. in the object stream of both files.””

    “One DCTDecode yes, but a few more flatedecode objects you seem to have overlooked.”

    HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
    NBC read right through that “background layer” reference skipping over the important to the trivial.

    You see he probably didn’t bother to check out my link.

    If he had he would have seen my proof that the DCTDecode filter appears once and the FlateDecode filter appears twice in the object stream of the background layer in both files.

    You see NBC is still reading (and unfortunately believing) the sequential printout from his freetoy parser. However it’s a fact that a given application can execute a PDF file in any order without affecting the final document. So my advice for NBC would be to toss those long strips of toilet paper that he keeps posting into the trash and try (hard) to think out of his box.

    Now you know and I know that it’s just too late for NBC. Because he is still living in his linear world. All he has to do is run his forefinger from the top of each long strip to the bottom. That’s obviously his comfort zone because he has already used up several TP roles in just the last few weeks.

  10. WKV

    NBC, on July 20, said:

    “Yes, as I showed, the JPG from Xerox is encoded in DCTDecode (JPG) and then in lossless FlateDecode. Somewhat of an overkill.

    “When you open the document in Preview and print as pdf, you will find that Preview cleans up the double compression.”

    HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
    That’s nice but he also recently posted the following:

    “”wonder why Preview would leave it in there ?”“ ( refers to YCbCr)

    “This is best understood when realizing that Preview is not a JPEG editor or bitmap editor. You can manipulate PDF objects but Preview does not touch the embedded image Xobjects. This makes a lot of sense because it has no reason to resave them. In fact, resaving a JPEG as JPEG may lead to additional quality reductions, even when saved at full quality. But one can do the experiment and print a JPEG to PDF and then extract the JPEG and look at the metadata. It remains exactly the same”

    So Preview “cleans up the double compression” “but does not touch the embedded image XObjects”.

    Maybe if he had said “doesn’t touch the COMPRESSED image XObjects” it would have worked ?

    Nah ! It’s beyond fixing !

  11. If he had he would have seen my proof that the DCTDecode filter appears once and the FlateDecode filter appears twice in the object stream of the background layer in both files.

    I really am not sure what your point is here. Yes there is DCTDecode in the background, which in the case of the Xerox is also flateDecoded. Again, that is old news… You just could never really figure out how to properly extract the object🙂

    There are flatedecode entries everywhere, what is Hermitians point, I have already shows a careful side by side comparison. What does he still not comprehend?

    However it’s a fact that a given application can execute a PDF file in any order without affecting the final document.

    Partially true… Remember that the paint object which paints all the objects is a single object and you cannot exchange the bitmask with the DCTDecode

    If you only spent some time understanding, your life would be much easier my friend

  12. So Preview “cleans up the double compression” “but does not touch the embedded image XObjects”.

    It ‘unzips’ the DCTDecode what is so complicated about this. You really need to familiarize more with this. It does NOT resave a JPEG (DCTDecode). You do realize that FlateDecode is a lossless compression?…

    Sigh…Poor poor Hermitian, so desperate to share with us his knowledge, unaware how he exposes his unfamiliarity with these concepts…

    You’re doing a fine job Hermitian… Did I thank you for it this week?

    Why can our friend not even properly do the experiment…? That would have saved him from so much embarrassment… Oh I forgot, he lacks the tools to do so…

    Those experts, I tell you…

  13. For the background layer, in both the Xerox 7535 scan to PDF and the Xerox 7535 / Preview print to PDF files there are two occurrences of FlateDecode and one instance of DCTDecode. in the object stream of both files.

    Trying to figure out what Hermie is babbling about. I think that one of the FlateDecode occurences he’s talking about is the one for the Page object (the one that has the cm commands, etc.), which applies to both files. The second FlateDecode occurence for the Xerox file is of course the second compression filter of the background image bitstream. I think he’s including the reference to the “deviceRGB” alternate colorspace definition as the second FlateDecode occurence in the Preview file.

    Note that the two items I think he is talking about do not match the double compression definition he quoted from the PDFReference manual, as they are filters located in other objects. If he looked at the actual PDF code, rather than relying on Preflight’s interpretation, he would better understand what is going on in the PDF.

  14. Note that the two items I think he is talking about do not match the double compression definition he quoted from the PDFReference manual, as they are filters located in other objects.

    I guess our friend has found out that FlateDecode, unlike DCTDecode is not limited to images…

Comments are closed.