swarren@convex.com (Steve Warren) (06/07/90)
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.COMdailey@cpsin2.uucp (Chris Dailey) (06/07/90)
In article <102835@convex.convex.com> swarren@convex.com (Steve Warren) writes: [...Some pretty good WP ideas deleted...] >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. I agree with you very much! Oh, by the way, if Commodore is willing to send me a hard drive and a copy of Lattice C (or by mid summer C++) and pay me for my time, I'd be more than glad to write one for them (I write pretty good code :)! I though about doing something like this (well, some different ideas) but I do not have the equipment to really do it. Maybe Matt Dillon would be willing to tackle this as his next project? You would make a killing, Matt, if you sold it for, say, $50 a copy. A nice manual. Etc., etc., etc. Something that fits on one disk... (Sorry, I started drooling!) >--Steve ._||__ DISCLAIMER: All opinions are my own. > V {uunet,sun}!convex!swarren; swarren@convex.COM -- /~\ Chris Dailey (CPS Undergrad, SOC Lab Coord, AMIG user group Secretary) C oo dailey@cpsin1.cps.msu.edu (subliminal message-make WP5.1 for the Amiga) _( ^) "I am thankful for one leg. To limp is no disgrace -- / ~\ I may not be number one, but I can still run the race." -from B.C.
dylan@cs.washington.edu (Dylan McNamee) (06/08/90)
In article <102835@convex.convex.com> swarren@convex.com (Steve Warren) writes: > stuff deleted... >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. > >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 > I agree with the premise here, that screen appearance is less important by far than final page appearance. I strongly disagree with the proposal though...at all stages until actual printing, the document should be completely printer Independent. This may seem to be impossible, but read on... > >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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this is almost as goofy as the way "bad" amiga programs do it now! > >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 IMHO, you have lost quite a bit.... > >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 . In a better world, you could have both device independence and "perfect" printer output. At the risk of creating a mild uproar, I'll describe my current project: The "Post1.x" program by Adrian Aylward has allowed anyone with a Preferences printer to print and display PostScript programs on the Amiga. If a printer supports 300 dpi, fonts, graphics, etc, all get printed at the highest resolution. The device independent nature of PostScript supports ALL resolutions, and produces the best possible output on the device given. The trick then, is to get your document into PostScript. Many of the commercially available packages can do this, but they're expensive. One could write in "raw" PostScript, but this gets very tiring. Hence my project: I am writing an interactive PostScript editor. It will edit (perhaps just import at first) text, and create and modify object oriented graphics. The graphics/text display will be maintained by the Post interpreter, and the output will be a PostScript file, printable on any PostScript device, including the Amiga running Post. It will be truly WYSIWYG in the sense that Post will be displaying the Postscript code as it is edited. Smaller fonts will probably be illegible at 75dpi (the resolution of a 640X825 screen) but 12 point text looks acceptable. Now for the status: I have the basic interface almost completed, and will actually be creating PostScript files within the month, unless something unforseen pops up. I will let the net know when/where it is available. Depending on user feedback it will either be freeware or shareware (<~$30). >-- > _. >--Steve ._||__ DISCLAIMER: All opinions are my own. > v\ *| ---------------------------------------------- > V {uunet,sun}!convex!swarren; swarren@convex.COM I'm open for comments/suggestions... dylan mcnamee dylan@cs.washington.edu