#PageSetter
20 messages in this thread
Hi Arno… I had the same problem as Doug Erdely so I appreciate the
information (bug fix?) about using PagePrint. But when using it one doesn't
seem to be able to selectively print individual pages, just the entire
document. Is there a way around this? Also, Doug mentions in a previous
message some line distortion…I've got this too…that is, some lines are
'taller' than others. This happens when using either an Okimate 20 or a Gemini
10X. It isn't a platen problem because it happens to the same lines on the
page every time regardless of the starting platen position (also occurs in both
friction feed or sprocket feed modes. Problem is worse on the Gemini but is
definitely there on the Okimate. If you've got any info, I'd sure appreciate
it. PageSetter is a good program but if I can't get it to print properly it
won't do me much good.
Thanks, Steve
The "thickening" or "thinning of lines is due to the scaling factor applied by
DumpRPort, which sends the pixel information to the printer driver.
As far as I know, the only way around it is to write a special dump routine.
Regards, Larry.
Larry,
How can I write a special dump routine without completetly rewriting
the printer.device?
I'm trying to get a better dump program which will do anti-aliasing
when in B/W mode — I'm also trying to avoid having to implement it in the
render function of my driver.
Any suggestions are MUCH appreciated.
Happy almost 198AMAIN/LARGELY
1987 all … By the way, that WAS!!!!! my password until 2 seconds
ago! Sh*t!
Todd Weiss
76526,1135
Todd, in the time it took you to change your password someone could have logged
off and on with it! If something like hitting a Function key and displaying
your password happens again just edit the line in your message. For example if
you are using SED type e at the Leave action: prompt and replace the string in
that line that is incorrect.
Marlene
Thanks for the warning Marlene. I didn't know about the edit possibilities as
they don't appear on the menu and I didn't want to type the message over.
Happy 1987.
Todd Weiss
TBS
Welcome Todd – Happy '87 to you too.
Marlene
Todd, if nothing else, at least do a /EX, then an A (Abort). Then redo the
entire message. I use Abort whenever I really mess something up and haven't
gone too far into the message. Easier than learning FILGE I guess.
Regards, Larry.
If you don't like Edit (Filge) you can always switch to SED — the line
numbered editor. Just go to OP and switch editors.
Right Steve…
It isn't that I don't like Filge, it's just that I so seldom really need to
go back and edit (only for errors that really change the meaning), that I have
to look up the appropriate commands every time. I find it a lot easier to just
dump the message and redo it in a lot of cases. I find SED somewhat awkward,
and changed to Edit years ago.
Regards, Larry.
Marlene,
There is no e option at the Leave action. I'm not sure what SED is,
but if it's what I'm using right now, there doesn't seem to be any way to edit
a message. If you know of one, please let me know.
Thanks.
Todd
Todd,
If you are using the line numbered editor that is SED, if you get no
line numbers you are using EDIT. You can also check which editor you are using
by checking your user options by typing OP at the function prompt.
EDIT is what used to be called FILGE and we have a complete help file
in DL 1 for use with FILGE, its called FILGE.HLP. The other option is to type
"/H" at the beginning of a line (no quotes) and you will get on-line help.
Once you exit a message, and are at the ACTION prompt…you can enter C for
Continue and be put back into the editor, or P to preview the message and of
course the other options like Save, SaveUnformated, MAil, MailUnformated.
And finaly you can Abort the save of the message.
If you chose to continue the edit, you are put back in at the TOP of
the message, and anything you type will be added at the top, you have to move
to the bottom manualy "/TYPE" or "/B" will do it. In the case where you
accidentaly hit a function key, you could have entered a "/D" (BTW, lower case
works also on all the above) to delete the offending line, assuming it was the
line you had just entered, or moved to that line and done the same thing.
EDIT is actually a fairly good on-line editor once you get used to it.
Don
Thanks for the info Don. I won't let it happen again.
Todd
Todd!
Hope you went out and changed it IMMEDIATELY!
<still picking myself up off the floor> <chuckle>
Got it on F5 have you?
Anyway, to the matter at hand…
As far as I can tell, the printer device accepts pixels (on only) in X/Y
form (though I may be getting it confused with the driver). If this is the case
then all you would need to do is to analyze the picture in terms of what you
want to do, and send the appropriate "on" pixels. If not, it may still be
possible to do a LoadSeg on your driver and send the appropriate stuff
directly, bypassing the printer.device. Don't forget you'll need the
port-handler in the picture soehow. **somehow.
Regards, Larry.
Larry,
Yes, I did change it IMMEDIATELY! (it was about time anyway). Here's
what I want to do. The ideal thing would be to rewrite the DumpRPort function
of the printer.device. If I implemented the code at the printer driver level
(it would have to be in render()), it would be A) too much of a pain in the
a**, and B) it would not be printer independant leaving my code useful to
myself and others only while (and if) they are lucky(?!?) enough to be one of
the few proud owners of an Okidata Microline 84 Step 1 printer (it was given to
me and is a true gem, but it's kind of old now, so I don't expect that many
have it). This means that if I ever get any other printer, or a laser driver,
this code will be entirely useless to me and I'll have to re-do it every time
(no thank you).
IMHO, the printer.device leaves something to be desired on B/W dumps
(although I think it does a pretty good job on the shading) and should have
been implemented with at least an option to smooth out a printout. Well,
Commodore didn't do it, so I'm looking into whether it would be worthwhile for
me to do it.
Any comments/suggestions/ideas/mindblowing insights are very welcome.
Happy New Year,
Todd
I guess what I would most like to see implemented is a switch that would allow
you to do 1 for 1 dumps. My main use of drawing or paint programs is in drawing
schematics, flowcharts, and an occasional form. I can always adjust my on
screen image to allow for the modified aspect ratio on the printer, but of
course DumpRPort messes up single lines so badly that it is almost useless.
Still digging.
Regards, Larry.
What I'm saying is just a guess, but if DumpRPort works the way that I think it
does (which explains the lousy lines), there should be some way of setting up
the aspect ratio on your dump which will work out exactly for your printer and
not leaving those half-a**'d lines.
They probably work out their printer pixel sizing with simple modula math (or
is that modulo — oh well). Therefore, there SHOULD (I say should because I
haven't found it yet — then again, I haven't tried all that hard) be some
size/combination that will work out exactly providing an exact pixel/pixel (or
2 pixels or whatever) ratio, and working out so that all pixel/printer-pixel
combinations are identical.
Of course, it would probably be easier to find a needle in the Indian Ocean
than to figure it out by trial and error, but there's probably some neat way of
figuring out exactly what the combination is and requiring only a ream or two
of paper and a weekend to figure out.
In other words (subtlety doesn't always help), if anyone from C-A who happens
to know about how the DumpRPort function was written (or can find out), please
let us in.
Any help is appreciated.
Todd Weiss
Triangle Business Systems
Todd,
That's not necessairly true. For example, the screen is 640 pixels
wide, while lots of dot matrix printers are 980 pixels wide. They just don't
divide evenly. So even rounding off and saying the ratio between the screen
and the printer is 2 to 3, what do you do with a single pixel? Do you print it
as 1 pixel or 2 pixels? What about 3 pixels…do you print them as 4 pixels or
5 pixels? Do you do a 1 to 1 dump? Then what about the 1/3 of the printer
width that isn't being used. I think the main thing to be realized is that
this isn't a photograph…it's computer generated graphics and there is some
difficulty translating screen pixels to print pixels when the ratio between the
2 is not 1 to 1 or 1 to 2 where the translation is easy.
Don
Don,
You got it! There are a lot of factors involved, the worst of which is that
even if you specify somehow that your width is exactly right, the Dump will
still scale in an attempt to make the aspect right. The only right way to do it
(if you truly want a 1:1 representation) would be to write your own dump.
Regards, Larry.
Don,
I believe that the DumpRPort function takes the 980 pixel wide figure
only for figuring the maximum dump width. A printout very rarely actually
reaches this figure. Instead, the dpi figure is used which is also in
printertag.asm. I have noticed that an inch or two is missing from the end of
a dump in any case.
Anyway, the basic idea is that yes, it is necessary to rewrite the Dump
— Sorry … the DumpRPort function … lost my place … hold on a sec …
ah, there we are. I'm finally learning FILGE (Fully Impossible Literary
Grossout Engine) … as the best solution is to implement a mixture -i.e. since
most graphics are more than 1 pixel wide and let's say that it is better to add
an anti-aliasing routine which smooth's out the jaggies between pixels. If
this were implemented, you would still have the same 1 pixel = 2 dots
(sometimes) = 3 dots (sometimes) = 1 dot (somtimes) problem, although it
should really be ei (2 or 3) or (1 or 2) but not both — (long weird sentance)
— but as jagged pixels would be smoothed out it wouldn't look quite as bad.
And with a laser printer (or other hires printer) it would be almost impossible
to notice at all, thereby leaving a clean and wonderfully beautiful screendump
(now wouldn't that be nice?).
Anyway, I'm still interested in any information regarding rewriting the
printer.device if anybody happens to have any info available.
Best Wishes & sorry about the lousy grammer.
Todd
the problem is the way the amiga graphics are done. if the amiga graphics
system were like the mac's, then it would be a snap to do such things since
lines, characters, etc would be represented by a graphics primitive instead of
being translated to screen pixels immediately.
–Scotty