OT: Phaser 6200 Printer Issue
Kevin Weilbacher
Laser Printer (with 384m memory) connected to the network via built in
Ethernet connection. Printer runs great for all regular print jobs. But a
really large single page graphics job, may take 8-10 minutes to complete.
She's mainly using Photoshop 7.0, Illustrator 10.0 and Quark Express. This
last thing she tried to print was with Photoshop.
It does *not* appear to be a problem in sending print job to the printer, as
the printer internal log shows that most of the delay occurs once it has
received the print file.
Not sure how to diagnose this. The printer can go to 512mb of memory, but I
don't want to throw more memory at it without proof that it will help. I've
already downloaded and installed the latest Phaser print driver and firmware
for the printer.
I don't know much about printing graphics, and was wondering if I need to be
adjusting or playing with printer settings on the PC, like for using
Postscript.
Any takers?
If not - I'll move on to one of the graphics newsgorups.
-kw
Dave Nickason
scanned Acrobat PDF files take over 1 minute per page on an HP Laserjet
1200. "Normal," non-graphical documents take 15 seconds or less. The only
relevant comments I can make are that I think it's something to do with the
file format or driver, rather than hardware. I have a couple of these
printers, and switching them doesn't make the problem go away for the
original user. Also, HP says that more printer memory will not address
this.
I'm assuming that your customer is using the most recent postscript driver
for the printer? I've had other instances of problems printing Adobe files,
where upgrading to a new PS driver helped.
"Kevin Weilbacher" <kwei...@gte.net> wrote in message
news:#D8M9jw5...@TK2MSFTNGP11.phx.gbl...
Steve Foster [SBS MVP]
wrote:
Well, if the delay occurs after the printer has received the job, it has to
be a printer issue. What's the physical size of the job as submitted? If
it's large, it will be using up some of the printer RAM just to hold the
raw job, before print processing even occurs. And the bigger the raw job,
the more RAM the printer will need to process the job...
--
Steve Foster [SBS MVP]
---------------------------------------
MVPs do not work for Microsoft. Please reply only to the newsgroups.
Jim Nast
similar. I switched it to *not* print in the background, and it went through
in 2 seconds.
"Kevin Weilbacher" <kwei...@gte.net> wrote in message
news:#D8M9jw5...@TK2MSFTNGP11.phx.gbl...
Kevin Weilbacher
I went over there today, and the printer is working fine. So it does appear
that the issue is that the graphics person is creating really huge files.
She had a one page ad in Photoshop PSD format (over 11mb in size) that took
over 3 minutes to print. I told her the printer was fine, but that she
would need to contact a graphics expert to learn how to size her documents
and images better.
The printer already has 284mb memory - it can go to 512mb - but I don't
think the extra memory is enough to offset the really huge files she is
creating.
-kw
"Steve Foster [SBS MVP]" <steve....@picamar.co.uk> wrote in message
news:oprltq0m...@msnews.microsoft.com...
Kevin Weilbacher
located. I don't recall seeing it on her printer settings.
-kw
"Jim Nast" <sys...@sedonalibrary.org> wrote in message
news:rqGdnTmvqf5...@sedona.net...
Kevin Weilbacher
latest postscript driver, and printer software, and also aupdated the
printer firmware. The printer works great on regular files. I went over
there today and it definitely is tied to the fact that she's using really
huge graphic files and images on her page.
-kw
"Dave Nickason" <gwdi...@frontiernet.net> wrote in message
news:OBZIdWx5...@TK2MSFTNGP09.phx.gbl...
Rick
out for something like this, if it was me, I would call Xerox's support and
let them tell you what the problem is.
Rick
"Kevin Weilbacher" <kwei...@gte.net> wrote in message
news:#D8M9jw5...@TK2MSFTNGP11.phx.gbl...
Jeff Middleton [SBS MVP]
for troubleshooting this would be to set the printer port (or chose as
destination) print to file. This eliminates the transfer and printer storage
from the question and simply rips the target to a file. It should tell you
if you have a front-end or backend problem. Once you have the file, do a
DOS copy to the UNC port location and see if the time reoccurs there, this
indicating that the printer's RIP (processing engine and RAM) is part of the
problem in the processing speed. If you get similar total time in
processing, then go to the printer driver Advanced settings and look to
change the resolution from 1200 to 300, to see if it's just the dithering of
photos that is taking so long. In theory, you would think this is a change
of 4:1 in resolution, but that's squared, therefore 16:1 reduction in file
size....but that's still not the entire answer. Resolution in printing is
spatial ( x by y), but it is also color depth in shades of gray. Therefore,
resolution in black and white printing is actually 3d (x by y by c) as
color depth. Therefore, if you are working in only B&W, you impact the size
of the file and file processing because the screen lines required to achieve
a certain number of shades of gray is therefore a multiple of the pixels, so
rather than 16:1, you could easily see 10x the file size just for shades of
gray calculations. When you are doing color, this part drops out due to the
24 or 32 bit color depth being fixed, assuming that these are bitmaps, not
spot color.
The main point is that if you reduce the pixel per inch resolution, you get
a significant reduction in file processing, and transfer, as well as buffer
space required in the printer. If you are doing black and white printing,
you shouldn't assume it's just 2 colors, 1 or even insignificant, it depends
upon the screen, resolution, and shades of gray requested. It's a common
problem with inexperienced digital graphics arts folks that they scan at
maximum resolution offered on the scanner, ask for maximum shades of gray
(screen size), then wonder why the printer automatically reboots everytime
the print! Overkill is just that. I've seen a single print job take 3 Gig of
disk space where a correctly configured setting required just 120Mb of swap
space at full resolution, and as little as 18Mb as a postscript file
properly encapsulated.
There is actual math that can be used to calculate this stuff, but most
artists don't take the time to learn it.
"Kevin Weilbacher" <kwei...@gte.net> wrote in message
news:ONfR0m05...@TK2MSFTNGP12.phx.gbl...
Kevin Weilbacher
panel actually lets you know when it is "receiving" the file from the
workstation, and when it is "processing" the file. The delay is definitely
in the "processing" part - because once it has received the file from the
PC, the hourglass goes away as well on the PC. On the job I tried this
morning, it was maybe 30 seconds getting to the printer, and then another
3-4 minutes processing before the job actually printed.
Another interesting thing is that the print driver for this Xerox printer
does not have the usual Resolution setting. That was the first thing I
looked for. I'm used to installing HP Laser Printers, and the default
resolution is usually set to 600dpi, and the users want to know why it takes
so long. I go in, reduce the resolution and they're happy and I look like a
genius!
So, there is no such resolution setting for this laser printer.
Another question: since I am NOT a graphics expert - what is CMYK? The file
that the user was trying to print today was saved ina CMYK format. Is that
good or bad o simply an option in grpahics?
-kw
"Jeff Middleton [SBS MVP]" <je...@cfisolutions.com> wrote in message
news:#tE4K345...@TK2MSFTNGP11.phx.gbl...
Merv Porter
<Snip>
Short for Cyan-Magenta-Yellow-Black, and pronounced as separate letters.
CMYK is a color model in which all colors are described as a mixture of
these four process colors. CMYK is the standard color model used in offset
printing for full-color documents. Because such printing uses inks of these
four basic colors, it is often called four-color printing.
In contrast, display devices generally use a different color model called
RGB, which stands for Red-Green-Blue. One of the most difficult aspects of
desktop publishing in color is color matching -- properly converting the RGB
colors into CMYK colors so that what gets printed looks the same as what
appears on the monitor.
<End Snip>
Merv
=============
"Kevin Weilbacher" <kwei...@gte.net> wrote in message
news:u9w$8f55CH...@TK2MSFTNGP10.phx.gbl...
Jeff Middleton [SBS-MVP]
30 seconds to exit the workstation is reasonable, at least, for the moment,
let's assume that we want to solve the 4 minutes printer RIP (Raster Image
Processing) question at the printer.
I'm not looking at a Phaser printer driver, but I would think that the
printer driver default resolution would be found in the Printer Properties |
General (tab) | Printer Preferences (button) | Layout (tab) | Advanced
(button). Here you should see some information to set on the features of the
printer, including the resolution. There are probably settings here that
also allow you to control the font substitution and download information.
However, everything listed here can be controlled or overridden by the
application itself, so this is more of list of defaults before overrides
list.
When you send a print job to the printer, the hardware (power on defaults)
are overridden by the driver defaults, and those are in turn overridden by
the application embedded defaults, which are in turn tuned by the project
embedded conditions in the actual print stream.
In most cases, all of the settings you need to control on a Postscript
printer doing graphics is really controlled by the application software
page/layout setup. Part of page layout is defining the resolution, screening
pattern, color space CYM/CYMK/RGB/spot, separation printing, encapsulation,
etc. The stuff in the driver setup is really just a guide to the hardware
features of the printer you are standing in front of, but everything about
postscript print jobs is specified in the actual print file stream....this
is the nature and wonder of why postscript is what it is. Postscript is a
unified, hardware independent language designed to assure that you can build
a file on one printer, and get the same results on any other printer
supporting postscript. By this, you should understand that the origin of
this extends waaaaaaaay beyond PC/Mac issues, were are talking about massive
imagesetters, typesetters, offset press devices, film recorders.......many
types of devices. Therefore, a postscript file is actually a readable text
file, not that you would find it an interesting read! It's a command list
which is executed in a manner similar to what SQL represents to database
queries, postscript represents a uniform instruction list of commands to be
converted from layout, spacing, fonts, and graphics commands.
Where postscript begins to start disappearing into confusion is when you get
to the use of embedded objects and downloaded objects. You see, the original
concept of Postscript (TM) was that everything was standard. Then the
language was extended to allow "embedded objects" like bitmaps and font
substitutions that are downloaded within the print job. Now, introduce a PC
that is quite capable of building and substituting *everything*, and now you
have a postscript file that can't actually be reproduced reliably between
different devices that support postscript language because basically all of
the postscript standard framework is effectively replaced in the downloaded
package of information and rendered as embedded graphics unique to the
characteristics of the RIP and bitmaps. If you don't have the bitmaps
properly sized to the screen size and true resolution of the output device
you are using, you end up with either really bad performance, bizarre output
quality problems, or both. The place where all this holds together remains
that if you have postscript devices that accept the same line screen, output
resolution, and color space requirements, then you can get machine to
machine independent printing results that are consistent. This is why really
good graphics artists are supposed to know the technical aspects of why
building a good file is a good idea, rather than just accepting the
assumption that "anybody can print postscript". Postscript has been reduced
from being a common language to being a common platform of communication in
which consistency of output has been lost. Far to many graphic designers
simply push crap at the printer without paying attention to what is needed.
One of the remarkable things you discover with printing technology is that
the typical scanning resolution you need is driven by knowing the output
resolution and the line screen resolution, doing the math, then not
overkilling the process.
It's been more than 10 yrs since I gave much thought to this topic, but here
goes. For instance, if you have a 4"x5" photo that you plan to scan, paste
into a layout, then print at 8"x10", you are effectively cutting the output
resolution in half of what the source was. Scan the original at 300 dpi, you
will have 150 dpi in the end result. Using a 1200 dpi output printer, too
many people assume that means that they need to therefore start by scanning
the original image at double that for the reason I just offered, the image
being printed at twice the size of the original. However, what they are
missing is that the screen pattern of 120 lines divides into that, so you
get good results with a 1200 dpi output if you have something close 100dpi
resolution in the image at output time (1200/120 = 100), however you may not
get the maximum apparent color space in gray scale. Therefore bumping the
resolution by 50% reasonably suggests that you need maybe 150 dpi output
resolution on the picture, therefore the scanner resolution at 300 dpi would
be fine since you are doubling the size of the original image dimensions to
the final image dimensions. But, if you don't understand this, you instead
scan at 1200 dpi, therefore you capture 4x pixels in each direction,
therefore the file is 16x the size it needs to be. When the printer goes to
process that, it will likely take 16x as long to handle a large than needed
bitmap scanned at just 4x the require resolution. Now, looking at your 4
minute print-time, if you had this same error in bitmap resolution, a 240
second print job quickly is brought down to 15 seconds and we can all move
on to another question.
Taking a different look at bitmaps, it's also a common mistake to scan an
entire image (like a photo of five people), and then use the image box
cropping tool to block out all but one person's face instead of literally
cropping the original image to insert just that portion of the photo. Say
you have a 4x5 photo of which the area of interest is only 2x2. That's an
original 20 square inches of pixels of which only 4 sq. inches
matters.....and this accounts for another 5x bloat in the image embedded in
the file. Take that 5x, the previous 16x, and we now have 80x error rate!
240 seconds divided by 80x and you get a 3 second output?!?
Another common problem is people who intend to output on black and white but
design with color pictures because it's more interesting to look at on
screen. An 8-bit gray scale looks basically the same as a 24-bit color
bitmap when printed on a B&W laser printer, therefore you have another 3x
potential file size advantage in that sort of work. Now combine the 3x with
the 16x error rate and we are at a 48x overkill if both are true. The 240
second print time could be reduced to 5 seconds? Okay, I realize we are
talking a color printer here, but I'm just trying to make this simple point:
you get more productivity from a task by asking for what you need, not
everything that is possible to ask for. It's like sending someone to the
grocery to bring back one of everything on the shelf just because you don't
want to decide what you are going to cook that night. Turns out that if you
really needed 3 tomatoes instead of one, the one of everything method still
isn't effective, just overkill.
Looking at font substitution and font tables also reveals some interesting
problems. If you have a person doing their own final output, it means the
printer they have next to them can be setup to take the print job repeatedly
without downloading all the fonts with every print job, or perhaps by just
using resident fonts. Downloading fonts means they become resident in RAM,
on a local cache drive (built into the printer), or are pulled from the host
computer as needed. What am I talking about here? Well, if you do a page
layout with say 6 scalable fonts Truetype/Postscript (not bitmap fonts),
these may be only about 3Mb in size, if that. However, if the graphic
designer has specified a family of fonts to be downloaded with every job,
and not reduced the list of fonts below the entire family, you can have a
situation where you are downloading 50-100Mb of fonts! Worse, the unskilled
operator request the fonts to be downloaded with every print job, not just
on first setup of the printer, or some other intelligent method. All of
this shows up in the printing time. It's common to embed unusual artistic
or specialty fonts, and in this day and age, I doubt that a standard set of
47 to 135 fonts would be considered practical, but efficiency of printing
suggests that you only embed the fonts you are using on the page. That's
what Encapsulated Postscript is all about: encapsulating all of the fonts
and objects needed to render the job correctly based only upon sending a
single file. As a result, you can get an idea of how big a file should be if
you look at the EPS file, compare it to the size of any embedded bitmaps,
and make an educated guess on the number of fonts actually needed for the
job.
More often than not, you will find that dramatically bad printing output
performance is caused by dramatically bad media design and layout, not
technical issues. The issues come home that at some point efficiency of
print speed in design is less important than keeping the "production needs"
from limiting the creative process. You can't always expect people using a
stock library of images to know the best resolution to prepare stock images.
Worse, they don't always know the actual resolution output needs when they
are scanning images, and the worst of all.......too often they don't even
understand the tools of scanning, layout and printing with sufficient skill
to know when they are off the mark by 5000% in what they are asking the
equipment to do. Back when I was making a living at this, you would have to
appreciate that education people on reasonable skill in production design
made it possible to do things on a 386 computer with 16Mb of RAM that many
current users with P4 2G workstations with 1G of RAM just don't get the
point or wonder. Yet what remains true is that the fastest output from a
printer is nearly always achieved by know when you are sending the printer
information that it simply spits 49 out of every 50 pixels on the floor, and
the 1 in 50 pixels hits the page. Meanwhile, the apparent performance is
being driven the 99% of the file you sent being useless and overkill.
"Kevin Weilbacher" <kwei...@gte.net> wrote in message
news:u9w$8f55CH...@TK2MSFTNGP10.phx.gbl...