[261] in Enterprise Print Delivery Team
3827 conversion scope issues
daemon@ATHENA.MIT.EDU (Rachel Sage)
Wed May 31 13:29:25 2000
Message-Id: <10005311729.AA11206@MIT.EDU>
Date: Wed, 31 May 00 13:16:20 EDT
From: Rachel Sage <SAGE@MITVMA.MIT.Edu>
To: printdel@MIT.EDU
Cc: Karen Fortoul <FORTOUL@MITVMA.MIT.EDU>, Peter B Kelley <KELLEY@MIT.EDU>,
Roger A Roach <RAR@MIT.EDU>
As I mentioned on Friday, there are at least three issues that need to be
looked at to determine if they should be part of the scope of the
3827 printer conversion project. I will list the issue and consequences
here. So far, we have "lived with" each of these problems because they
were small scale, took focus away from bigger problems and they weren't an
issue on the 3827.
The issues are:
1. print quality at 300 dpi
2. hole placement on the separator pages
3. paper loading on the 3160
1. Print quality at 300 dpi
AFP prints at two resolutions; 240 dpi and 300 dpi. (The 3160 is a 600
dpi printer but that is really just a multiple of 300 dpi.) The resource
libraries on VM are 240 dpi libraries. This includes the fonts and page
segments (graphics). When we print on the 3160 printer, the printer
automatically rescales the data stream to print at 300 dpi.
This has caused some small problems. Our graphics (logos, seals, etc) are
"fuzzier" on the 3160. We have also seen placement change slightly on some
of our overlays. We've worked to fix some of the placement problems on a
case by case basis but not the graphics problems.
What we need to determine is whether the problems are big enough to solve
or small enough to ignore or fix on a case by case basis.
The correct way to solve this problem is convert everything we have to
300 dpi. That means ordering 300 dpi versions of fonts that are still
available from IBM, converting older (now unavailable) IBM fonts to 300dpi,
converting MIT home-grown fonts to 300 dpi, converting our graphics to
300 dpi (and cleaning them up) and changing all of our forms to use these
resources. This is large job for both the systems and forms design people.
I would suggest that someone start looking at some of the print quality
differences to determine if the problem is big enough to solve.
2. Hole placement on the separator pages
Because the 3160 has a different paper path than the 3827, there are problems
with the separator pages on jobs that are duplex and use three holed paper.
When you print simplex pages, the 3160 prints on the "front" side of
the paper first. When you print duplex, the 3160 print on the "back"
side of the paper first. This is not a problem on the 3827 because it
always print on the same side, regardless of simplex or duplex.
Separator pages are always simplex. Print jobs can be simplex or duplex.
There is no problem when no-holed paper is used. When three-holed paper
is used, the holes end up on the correct side of the print file but on the
wrong side of the separator pages.
We had previously decided that we would live with the problem since it
was only the unimportant separator pages that were affected. We could
continue to ignore this problem.
Fixing the problem involves either pulling paper from two input bins (one
for the separator pages and one for the print job) or changing all of the
duplex jobs to rotate the printout to allow both the separator page and
the data to print correctly.
The downside of pulling from two input bins is that we could no longer
use the second input bin as an alternate primary bin. If the primary
input bin breaks (as it does fairly often on the 3827), we would have
to wait until it is fixed.
The downside of changing all of the duplex jobs is that we would have
the change all of the duplex jobs!
3. Paper loading on the 3160
Again due to the paper path difference on the 3160, operators have to position
sensitive paper (such as three-hold or preprinted forms) in different
ways, depending on simplex or duplex jobs. This has lead to a coding on
the operform name to specify paper loading. Form X999-HL means load
the paper "holes left" while X999-HR means load the paper "holes right."
This is similar to what we used to do in B11 with HI and HO.
This can be a pain in the butt.
If we want to eliminate this, we would have to change the forms so that
they rotate the data to print in the correct direction on the special
form. Same downside as problem number 2. More work for forms designers.
-----
If anyone has any opinions or feelings about any of the above problems,
I would like to hear about them. Personally, I don't classify any of the
above problems as "must fixes." I probably have the most concern for the
print quality at 300 dpi problem. We never got to revisit the issue
after the first conversion, but nobody has complained, yet. Obviously,
it involves a great deal of work, so if the current print quality is
"good enough," I'd really like to avoid the 240 -> 300 dpi conversion.
The other two problems don't really affect the customers and so are
probably much lower priority.
Obviously, solving each of these problems adds time to the timeline.
Let me know what you think and what we should persue.
Rachel
