mark@ece-csc.UUCP (Mark Lanzo) (11/03/86)
Well, I'm back again with more to say/ask regarding making a printer driver
for the Toshiba P1340 printer. This time maybe I can be more precise.
I apologize for being a vague about some things in my previous article.
I didn't have my RKM nor the source code for my driver handy when I posted
my previous article (couldn't find 'em!), and it had been two months since
I had last worked with the driver program -- I couldn't ask my questions
when things were fresh in my mind since my link to USENET has been
gone for 1-2 months (thanks to numerous hardware failures; upgrades from
4.2BSD to 4.3, etc...). But I got it all now...
First off: I have the graphics dump routines working in a somewhat better
fashion now. Many thanks to Dave@cbmvax who wrote me suggesting that the
reason why the dithering did not seem to work well was that the printer
dots overlap (dot size larger than the dot spacing) -- this does indeed seem
to be the problem. I've modified the routine to fire every other dot
rather than every dot when setting pixels. I.e.: The printer resolution is
1440 dots per line. The system now thinks the printer has a 720 dots/line
resolution; when it says to set a pixel in column 'x' I actually fire the
printhead pin in column '2x'. Likewise for vertical spacing.
This seems to yield better results. I'm still experimenting to see what
else might help (such as firing a 2x2 block on the printhead for each pixel
the system wants to set). Incidentally, for anyone else working on a
printer driver, the dithering is done using a 4x4 matrix; this yields 16
different shades of grey, with successively darker shades obtained by simply
setting an increasing number of dots in the 4x4 tile. Judging from the
graphics dumps I've seen on some other printers, I'm not the only one who
has run into this problem of overlapping print-dots.
-------------------------------------------------------------------------------
Now: For the text functions -- more precise questions:
* What is the difference between reset (aRIS) and initialize (aRIN)?
(answered by andy@amiga)
* what is "normal pitch" (aSHORP0) supposed to do? (That is,
what pitch is "normal" -- 80 chars/line? 10 cpi? 12 cpi?)
Or should I get this from preferences somehow?
* What is the difference between "elite" and "condensed" modes
(for aSHORP1, aSHORP2, aSHORP3, and aSHORP4)
* What is line normalization? (aSUS0)
(answered by andy@amiga -- it's cancel subscript/superscript)
* I presume "proportional on" (aPROP2) means to enable proportionally
spaced printing; and "prop. off" (aPROP1) turns one mono-spaced
printing. But then what is "proportional clear" (aPROP0)?
Also what does "proportional offset" do? (aTSS)
* What is "letter space" (aJFY3)?
Also, in regards to my earlier postings where I asked for suggestions on
how to handle things like italics, underscore, etc. on a printer which
didn't have that many features, yet which could probably be made to perform
some alternate action in some instances which would be semi-acceptable:
My original question:
>
>The P1340 unfortunately is not very smart in regards to different character
>sets et al. It's a 24 pin printer which prints very nicely, particularly
>when put into NLQ mode. However, it does not have italics or boldface,
>although it does have underlining. The question is: how should I treat
>requests for italics and other special fonts? My current solution is to
>treat any request for italics/boldface/shadow-print/etc as a single
>"standout" mode. If I am in draft-mode (non NLQ), I turn on NLQ mode,
>which causes the text in "standout" mode to print as darker and more
>distinct than the surrounding text. When all "standout" attributes are turned
>off, I switch back to draft mode. If I'm already in NLQ mode,
>there's nothing much I can do, so I just ignore the requests. I can't say
>that I really like this arrangement, but I don't have any better ideas.
>Suggestions?
One reply (from Matt Dillon -- thanks Matt):
-> Yes, you can simply overwrite the line... a double pass on the chars
-> you want in boldface will make them darker whether your in LQ or not. In
-> terms of italics.. the standard convention for printers that do not have
-> italics is to underline them instead... however, make sure you treat it as
-> a separate mode, so if the user does 'italics on, underline on, underline off',
-> following text will still be italics (underlined). until an 'italics off'.
(not to worry here; I do track each option separately and only clear
"standout" mode when ALL special options are turned off)
Actually, this was what I wanted to do originally. The problem here is that
the person writing the "printer driver" doesn't actually see all the standard
characters. He just writes his own "DoSpecial" routine along with the
"CommandTable". Code outside of the printer driver recognizes
the Amiga standard control sequences (where by "control sequences" I mean
any special functions -- things like CR, LF, as well as more exotic
escape sequences) in the text being printed, and uses "DoSpecial" and the
"CommandTable" to translate these codes into the equivalent code for
the printer being used. However, regular text is just sent straight on
to the printer without being filtered through the portion of the printer
driver you get to substitute. Hence, I don't have any way of buffering
up characters so that I may do this "double-strike" stunt.
It would also be desirable to intercept regular characters in the event
that I need to change them to print as something else on my printer.
For example; assume my printer does not put slashes through either zeroes
or "O"'s (the letter Oh), but I would like zeroes to be slashed. If I
could intercept a zero in the text then I could replace any occurence
of "ZERO" with "ZERO BACKSPACE FORWARD-SLASH". Similarly, I could perhaps
then define combinations of overstruck characters to simulate all those
goofy metacharacters in the Amiga's character set (for instance; ALT-L
prints a British "Pound" symbol, which could be generated as "L BKSP -").
Now, if anyone knows a way of doing this (short of also rewriting
the PRT: device driver! :-) I would be really interesting in knowing how.
I don't *think* the information is in my RKM. (maybe it is in newer
versions of the book, if there are any...)
--------------------------------------------------------------------------
More questions:
1. Why does "DoSpecial" get called for some actions even though
the entry for that action in the CommandTable does not contain
any "\377" characters?
(answered by andy@amiga)
2. What precisely are the "currentVMI" and "vline" arguments to
to DoSpecial routine? Are these altered by the PRT: driver
or are they just pointers to variables I can use in any way
I want?
3. What sets or clears the "crlfFlag" argument to DoSpecial and what
is its meaning? I have just defined the aNEL entry in CommandTable
to be "\r\n", and aIND to be "\n" which seems to work fine.
"\r" by itself I should hope would only return the printhead to
the left margin, without dropping to a new line. Incidentally,
I notice that the CommandTable doesn't have an entry for a RETURN
function. Since some printers
like to add their own LF after a CR or vice versa, it seems that
the CommandTable should have an entry for a RETURN function in
the same way that it has an entry for the LF function (aIND).
-------------------------------------------------------------------------
Well, thanks folks for the replies so far... keep 'em coming!
-- Mark --
ps: In the event that "postnews" inserts the line
"Organization: North Carolina State University" in the header
would someone please tell me how to disable that??
My only connection to NCSU at present is my account on this
machine.