1-to-n is first sheet to last or the order the pages are aranged in the document.
n-to-1 is last sheet to first, which means the printer must RIP the entire job prior to printing.
N-to-1 will delay the printer startup.
Yes Hello I have an error code I have not seen before - (XPE-09-3026) The toner seems to magnitize on the print engine area roller just above lever 2 where the glass is...It looks like a brush. I vacuum it our and clean everything only to have it reoccur. Any suggestions?
Let us say we have a 10x12 4C TIF at 300 dpi, that will be about 42 MB. The RIP has to process the 42 MB for every page in the PDF.
Now let's size that TIF down so that we are placing it at 100%, it is now about 2 MB.
That extra 40 MB we aren't RIPping now is going to speed up everything.
The N-1 & 1-N setting is in the Output tab/ Finishing section under Output Order.
"To take advantage of concurrent RIP and job printing, VI jobs
should be printed using 1-N. Printing N-1 will cause the entire
job to RIP before printing starts. For natural reading order,
select face down when printing 1-N. However, N-1 may be
necessary to accommodate some finishing selections."
Not sure I understand what you referencing when you mention the PDFs at 100%. I understand the 300 dpi...
Please explain what youu mean by the N-1 or 1-N?
I agree that the speed of the RIP is due to the type of image file.
I have a client who always sends me PDFs made with 300dpi images placed at 20%. It would cut the RIPping time down if only they would place a 300dpi image at 100%. Much less info for the RIP to process.
Now, are you printing N-1 or 1-N? Are you waiting for the entire PDF to RIP before printing or are you printing as the file gets RIPped then waiting for more pages to RIP?
Xerox recommends printing 1-N. You would need to set the print to face down also.
Another thing to check is your Variable Data Object value under System Preferences/ Job Processing. You can increase this up to 35% from the default of 10%. Do this if your RIP is out of room.
not sure I clearly understand.
When we print the image it usually at a 200 line screen and we have the over print toggled on. The images arer sent over to us as PDFs from our prepress. We have considered the idea of creating a new que in case the current que is corrupted.
However, I think since the images are now stepped (four up as opposed to us creating the stepping) this makes the file bigger, but certainly shouldnt take as long as it is to spool.
This morning we are downloading a veriable data job and the images seem tyo be taking longer. Prior to the issue we where recieving the images from prepress and then releasing the image for print. To increase productivity we have asked the prepress department to step the job four up. This has created a larger file. Is this common for the image to now download so slowly?
Solved! Go to Solution.