Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!swrinde!kent
From: kent@swrinde.nde.swri.edu (Kent D. Polk)
Newsgroups: comp.sys.amiga
Subject: Re: Stupid Wishes
Keywords: Wish list
Message-ID: <17222@swrinde.nde.swri.edu>
Date: 8 Jun 89 17:52:51 GMT
References: <17161@swrinde.nde.swri.edu> <108759@sun.Eng.Sun.COM>
Reply-To: kent@swrinde.UUCP (Kent D. Polk)
Distribution: usa
Organization: Southwest Research Institute, San Antonio, Texas
Lines: 111

In article <108759@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes:
>In article <17161@swrinde.nde.swri.edu> (Kent D. Polk) writes:
>>(First Biggest - No 640*400 non-interlaced video - should have been in 1.3)
>
>First point, the current chip set can't support non-interlaced video, no matter
[...]

Yes, I know about the hardware limitation, but considering Amiga owner
discontent over 640*400 interlaced & the number of sales lost to the ST
because of it's hires mode availability, I still say it should have
been considered earlier (like for the introduction of the A500's &
A2000's).  Now I don't have official figures here, just that I know
more than a few people who wanted an Amiga but bought an ST just for
this reason.  (Made the wrong choice, no?)
This discontent has been since the earliest release of the Amiga also.
While drawn to the Amiga from the first Byte article by multitasking,
shared memory-resident libraries, a structured OS, & many other things,
I must say that when I first saw 640 * 400 interlaced mode, I almost
gagged.

>>Proposition : Make prt: able to decode IFF text and graphic info.
>Is that what you really want, how about just a IFFPrint program that does
>this instead?

What I want is to make more information available to the printer
drivers and to make it easier for applications programs to output to
the printer. Now maybe this isn't the proper way to do it, but it was a
suggestion as opposed to simply griping about the poor support provided
for printers. I just felt that a different tack than filter hacks was
needed. It seems kinda silly to me that to get things like Postscript
output, one has to use a separate filter & can't even use prt:.  Not
consistent.

If this info was available, couldn't one make a 'simple' Postscript
printer driver (not easy maybe, but doable)? Exactly how could one get
font names for text (imbedded in the file)? Seems like IFF Text would
be the way to do this. It has such info available (and without
resorting to graphics output). This way one could print directly from
something like ProWrite to a Postscript printer without having to save
the file & bring up ProScript. One could also just 'type' the ProWrite
IFF Text file to prt:. Much more convenient.  Now, for fancy page
positioning & such, a separate program would be the advisable method.

Also, one could create fonts compatible with HP laserjet cartridges for
screen display, & then the IFF text info specifying those font names
would be sent to a new Laserjet printer driver, which would specify a
cartridge font for the text instead of resorting to graphics output to
get what you want. Seems like a major coup for Deskjet/Laserjet types
to me!  If the printer driver couldn't understand, then just print the
text.

Maybe there would have to be a different prt: device for this kind of
stuff, but it sure would be a shame if it wasn't compatible with prt:.
Maybe implement it like CON: & NEWCON: - a superset for those who need
such capability.

>>Proposition : Extend GraphicDump to support dumping a portion of the
>>	screen to the printer or a file. 
>An excellent idea. Doable too. 

Thanks, I though so too. Anyone want to sign up?

>>Question : Why is the info about writing printer drivers a closely
>>	guarded secret?
>It isn't, it just hasn't made it into easily accessible print yet.
>There was a talk on it at DevCon last year, a copy of which is available
>from CATS in the DevCon notes.

Please, Please, Please, lets work towards getting such info into
readily accessible print.  Sorry if this is repetitive, but how does
one get the DevCon notes when one is not a developer?  re UseNet
response: Yes, UseNet responses are invaluable. Problem is I don't feel
I should ask a question until I have a greater understanding about a
subject than I do about writing printer drivers (graphics mainly). (Why
am I asking these questions then, right? :-) )

And here I am asking for more capabilities included in printer drivers
- Masochistic, aren't I?

>>Please, no flames, I'm trying for constructive criticism and real
>>information .
>Great, how about meeting them halfway. 

I don't quite understand. If you are talking about supporting the
Amiga, sure I haven't written much software for it - nothing worth
giving out certainly, but I have been responsible for the purchase of
about 30 or 40 Amigas through other efforts - Such efforts, and much
greater ones than these from others :-) are what has kept the machine
alive, certainly not Commodore. I believe in the machine, just wish it
was easier on people who don't have the option of dedicating their life
to learning how to program this machine. (Working on it though).

>>The question is: how does one try to convince Commodore management to
>>direct funds towards needed, purposeful & consistent development?
>As far as I can tell this isn't possible.
Big Shame on Commodore.

>>Towards this end, what do others see as needed goals that we can
>>request (in unison)?
>This is where you get a lot of bang for the buck at the Developers Conference,
>[...]        so I will definitely be lobbying for improvements in that area.
>So even if you can't go, it isn't like you aren't heard :-). 
>--Chuck McManis

Then I can't say how much I appreciate your voice at these functions.
Maybe my current high level of frustration with a few aspects of the
Amiga are not just self-erosive. Thanks for listening.

BTW, I really do love this machine, just wish ... 

Kent Polk