[265] in Enterprise Print Delivery Team
Re: 3827 conversion scope issues
daemon@ATHENA.MIT.EDU (Lynne E. Durland)
Fri Jun 2 11:50:54 2000
Message-Id: <4.2.2.20000602110502.00c9b5e0@po12.mit.edu>
Date: Fri, 02 Jun 2000 11:50:46 -0400
To: Rachel Sage <SAGE@MITVMA.MIT.Edu>, printdel@MIT.EDU
From: "Lynne E. Durland" <durland@MIT.EDU>
Cc: Karen Fortoul <FORTOUL@MITVMA.MIT.Edu>, Peter B Kelley <KELLEY@MIT.EDU>,
Roger A Roach <RAR@MIT.EDU>
In-Reply-To: <10005311729.AA11206@MIT.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Rachel, ,
Sorry for the delay, here are some thoughts.
At 01:16 PM 5/31/00 -0400, Rachel Sage wrote:
>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.
1. Yes I think that it makes sense to order the 300 DPI fonts, do that have
to replace the 240 libraries or can the two coexist?
2. Changing a font on a form is not that hard. Change it in elixir, check
placements, upload, compile, test print. may involve a couple of
iterations to adjust placements but not that hard.
3. re rendering images is more work than replacing a standard font with a
standard font. Would we work with the existing image file and scale it up
or find a "clean" printed copy and re scan and save at the new DPI? Either
involves work, but my memory is that the re scan may involve less work and
clean up of the image. the scaling in the printer is what is causing the
fuzz in the first place.
4. Scope of this work partially depends upon how many forms we are talking
about. Are we using 100 or 20 or somewhere in between? I know that after
Bill French left when I had to work on a form I would replace home grown
fonts with standard IBM fonts whenever possible. (the biggest exception is
the benefits form, bad news all around on that one. I plan to check and
see how much is involved in switching the printer to run at 240 for
printing this specific form, which I think is only once a year ) Also
along these lines and related to point one above, if there is not an exact
match of a 300 DPI IBM font that we currently use at 240 DPI I would
strongly recommend that we get "close" with a new standard font and not get
into the business of creating fonts again, it is time consuming, pain the
butt, eye straining work that is not worth the effort in the end.
5. When Art and I chatted yesterday he said he would start printing some
samples from the 3160. As I have not yet seen _any_ of the prints from the
3160 I have no real way of knowing how big any of the problems are yet. I
have set up a book to hold samples from both printers side by side for
comparison. As Art and/or I get these samples printed I can have a
somewhat better idea of scope by mid June. this would also include the
number of x forms still in use.
>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.
How difficult to have a second set of separator pages with a page eject for
duplex?
My memory is that it should not be difficult to add a line of code to the
overlay and PPFA files to rotate the output. I will check so don't hold me
to this one yet please. I will commit myself to having this answer by mid
June.
>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
I will defer to Lambert on this issue.
>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
Lynne E. Durland
Information Systems
Database Services
W91-109
258-5857
"Happiness often sneaks through a door you didn't know you left open."
--John Barrymore
