[263] in Enterprise Print Delivery Team
Re: 3827 conversion scope issues
daemon@ATHENA.MIT.EDU (David F. Lambert)
Thu Jun 1 19:21:41 2000
Message-Id: <10006012321.AA23156@MIT.EDU>
Date: Thu, 01 Jun 00 19:02:35 EDT
From: "David F. Lambert" <LAMBERT@MITVMA.MIT.Edu>
To: Rachel Sage <SAGE@MITVMA.MIT.Edu>,
Enterprise Printing Delivery Project Team <printdel@MIT.EDU>
Cc: Karen Fortoul <FORTOUL@MITVMA.MIT.EDU>, Peter B Kelley <KELLEY@MIT.EDU>,
Roger A Roach <RAR@MIT.EDU>
In-Reply-To: Message of Wed, 31 May 00 13:16:20 EDT from <SAGE@MITVMA.MIT.Edu>
On Wed, 31 May 00 13:16:20 EDT Rachel said:
>
>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
Thanks for the additional conversion details, Rachel. On the topic
of resolution, it seems to me we shouldn't do any extra work to
increase the resolution to 300dpi unless the customer really requires
it. I agree that we should proceed by doing some testing and checking
with customers. Lynne thought there was a chance we are no longer
using in home grown fonts. Can you confirm this one way or the other
without doing any additional research?
re hole placement on separators: do you have any feel for the amount
of work it would take to rotate the duplex jobs? I agree that we shouldn't
suck up an alternate input hopper just for hole alignment for the
separators. Would it be possible to have two types of separators, one
for simplex jobs and one for duplex? Worse case seems like we simply
live with the misaligned separator holes with duplex jobs. I wonder
if customers file their hole output with the separators???
re paper loading: Worse case here also sounds like we live with
oper forms such as -HL & -HR. Not a big deal in my mind. However,
if the rotation trick solves two problems, it might be worth the
effort. Lynne certainly has a better handle on the work involved
(I hope). She was out yesterday but I'm sure she'll have some comments
on your note when she has time.
I did think of one other issue after last week's meeting. Can you
(Rachel) confirm we're running the most recent release of PSF/VM?
My concern is that we have the appropriate release installed to
apply the PTF which allows the printing via TCP/IP.
Thanks again for helping clarify the conversion issues!
-Dave
