Space between copiesgreenspun.com : LUSENET : PosterShop Talk : One Thread
As we use metric units we generaly face the problem of mismatches between settings and print results. Even changing from mm to inches is unsatisfactory. We rip with PosterShop 4.5 and print on a Colorspan DisplayMaker Series XII. When we set the space between copies to "0" the result is definetly NOT zero. What may be the cause of this?
-- Anonymous, March 17, 2000
All copies are aligned on a byte boundary for output to the printer. This was done to speed up the output to the printer. If each copy was not aligned on a byte boundary, then the output would have to be bit shifted on each line of data output to the printer. This would significantly slow down printing. The only way to achieve absolute zero space between copies is to turn off registration and crop marks, and make sure that the number of pixels (bits) in the width of one copy is evenly divisible by 8 (8 pixels (bits) per byte). You can calculate this amount by taking the width dimensions in inches and multiply that amount by the output resolution which is in dots (pixels) per inch, and then divide by 8. If your calculator shows an integer value with no digits to the right of the decimal point, then you will have absolute zero space between copies.
For example, if your output width is 348 mm; convert that to inches, which becomes 13.7007874 inches = 348 mm / (25.4 mm / 1 in.); multiply 13.7007874 inches by your output resolution, lets say 600 dpi, 13.7007874 in. x (600 pixels / 1 in.) = 8220.47244 pixels; round up to the next pixel because there is no such thing as a .47244 pixel; we end up with 8221 pixels; divide 8221 pixels by 8 = 1027.625 bytes. The .625 tells us that the end of the picture only fills up part of a byte and by multiplying .625 by 8, we get 5 pixels into the last byte. That means that I will have 3 pixels of white space between my first copy and my next copy because PosterShop is not going to shift all the bits of the next copy to fill in the 3 bits to align the copies next to each other. In order to align the copies, I will either have to change my width to add 3 pixels or subtract 5 pixels.
If I add 3 pixels I end up with 8224 pixels; divide that by 600 dpi = 13.70666667 inches = [13.70666667 in. x (25.4 mm / 1 in.)] = 348.1493334 mm.
If I subtract 5 pixels I end up with 8216 pixels; divide that by 600 dpi = 13.69333333 inches = [13.69333333 x (25.4 mm / 1 in.)] = 347.8106666 mm.
If you put either of these values in for your width, your copies will have zero space between copies.
We made the decision not to shift bits for alignment between copies after we tested its effect on print speed. It significantly reduced print speed which resulted in banding and head pausing. This was totally unacceptable for quality output, therefore, we don't align by bit shifting. If you can imagine trying to bit shift 8221 pixels by 3 bits to the left for a 348 mm print for the first two copies and then by 6 bits to the left for the next copy because the last byte of the second copy only occupies 2 bits into the last byte, etc., etc., etc., and then multiply these operations by the number of lines in the output, and then multiply the resulting operations by the number of colors on the output; you begin to realize how inefficient these operations are when you have to bit shift billions of pixels just for the sake of alignment.
Sorry for my long winded explaination. I hope this helped in explaining the cause of the problem.
Another reason that makes things worse, is that resolutions on printers are measured in dots per inch, which is an English unit, which generally results in a fractions when converting between Metric and English values. Depending on the "Default Job Properties / Display / Measurement Precision" set in PosterShop, you can unknowingly be truncating measurements which can propagate to be truncated further each time a calculation is made within PosterShop. This would result in large errors for the final measurement value. Increase the "Measurement Precision" as appropriate for your needs so that truncation is minimized.
-- Anonymous, March 17, 2000