Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!convex!swarren
From: swarren@convex.com (Steve Warren)
Newsgroups: comp.sys.amiga
Subject: WYSIWYG hardcopy (was Re: ProWrite 3.0 summary)
Keywords: features, description, ProWrite, new product
Message-ID: <102835@convex.convex.com>
Date: 6 Jun 90 17:56:22 GMT
References: <1990Jun5.201807.15693@uncecs.edu>
Sender: usenet@convex.com
Organization: Convex Computer Corporation; Richardson, TX
Lines: 102


Here is something that bothers me a bit, and I wonder why I haven't
heard of anyone doing this.  Dave Haynie has explained that the
reason WYSIWYG word processors that do not use postscript or
Compugraphics font technologies produce less pleasing hardcopy than
similar applications on Macs is because the Mac has a standard
number of pixels for its printers, and all the Mac apps know about
this size standard.  So, with the Mac screen exactly half as wide
as a Mac printer (in pixels), the Mac simply does an "integer" mapping
(that is - no dithering or fractions of dots are needed or attempted),
resulting in output that looks very uniform and visually appealing.

Compare this to typical Amiga hardcopy, in which the printer driver
is attempting to map one pixel on the screen to 1.3 pixels on your
printer, or something equally dubious.  This is not to say that I
am not impressed by the quality of the printer drivers.  These
drivers are excellent pieces of work.  Unfortunately I think that
word-processor application writers seem to lean heavily on the
printer drivers and therefore the quality of their output suffers
from an irregular appearance as they feed bitmaps to the drivers
that do not match the width of the printer they are to be output
to.

Now I don't know about the rest of the readers of this news group,
but as far as I am concerned if there is going to be any dithering
or partial-pixel approximations in a document, I would prefer, indeed
if at all possible I would *insist* (this is why I still haven't
purchased a WYSIWYG application), that this partial-pixel approxima-
tion would occur on my *screen*, while the true bitmap would be done
on my printer.  Why would I want to make the printer try to approximate
my *screen* when producing a letter?  That is so bass-ackwards!!  I
want my *printout* to look good!  I don't *care* if the screen looks
great!  The screen appearance will be gone forever after I finish my
letter and mail it to someone.

Since the actual document is the ultimate *product* that I am trying
to get out of this application, why does the application give me a
perfect *temporary view* of my product on the screen, and then give
me a perverted hardcopy?  I think that a decent application would do
much better to give me a perverted temporary view on the screen so that
the hardcopy is the part that comes out uniform and with a one-to-one
bitmap (what I call "hardcopy bitmap pixel-integrity" - ie the pixel
boundaries line up uniformly with printer dot boundaries).


Here is how I would envision such an application working:

1) When I start a fresh page it goes out to see which printer driver
   is currently set up in preferences and sets the total pixel-width
   of the new page to be equal to the pixel width of the printer that
   corresponds to this printer driver.  Similarly it sets the vertical
   pixels.  I also have a menu selection that allows me to select a
   bit-map-to-page size by selecting either an alternate printer (an
   alternative to the one currently selected through preferences), or
   by entering the raw parameters directly.

2) In one-to-one mode the screen would be a scrolling window over the
   bitmap of the entire page.  The application would treat it as a
   scrolling play-field is treated in an arcade game, blitting in
   the hidden edges when necessary to allow fast scrolling around
   the screen.  Typing in text in this mode would be fast since the
   character bitmap could be blitted into place without the need to
   do any computations on the bitmap data.

3) In "true-aspect-ratio" mode the pixels will be dithered to approximate
   the appearance of the output on the printed page.  This viewing mode
   would take time to compute, but once the entire page was computed
   there is no reason why scrolling around in it could not be very fast
   (I have not seen a WYSIWYG app that scrolls well in this type of mode).
   One would not want to type in text in this mode since recomputing
   the whole screen after each character was typed would add so much delay
   that it would become unbearable (Pagestream is an example of this).

4) When the document is printed it will look as clean as any Mac document,
   provided it is printed on the printer that was selected for it when
   the pages were created.  When it is printed on some other printer you
   will get the same inconsistencies that you normally get on all printers
   when you don't have these features in your word processor.


Now, IMHO you haven't lost anything if you created your document for one
printer and later print it out on another printer and get inconsistencies
because it wasn't created for that printer.  With the old-fashioned style
of word processors you would have had similar inconsistencies on *all*
printers.

However, when you print it on the printer it was created for, you have
gained much.  You have finally obtained the Holy Grail of word processing
on the Amiga: hardcopy bitmaps with pixel-integrity .

Does anyone feel that what I am suggesting is ridiculous?  Does anyone
know of a wordprocessor that actually does what I am talking about (I'll
buy it!)?  If not, are you writing the Holy Grail Word Processor yourself
(I want to shake your hand!)?  I really want to know if anyone else ever
gets the frustrating feeling that our word processors on Ami are doing it
backwards.

--
            _.
--Steve   ._||__      DISCLAIMER: All opinions are my own.
           v\ *|     ----------------------------------------------
             V       {uunet,sun}!convex!swarren; swarren@convex.COM