Hi Henrique,

> If I understood you correctly, by using FreeDOS GRAPHICS, I could send
> a codepage directly to the printer's RAM (naturally, one which wasn't 
> already hardcoded into it). Am I right? It would be great.

No. You could print a screenshot of DOS showing text in some
(possibly user-defined, with some codepage) as a picture, as
graphics. That only works if you switched to a GRAPHICS mode
first and if our DISPLAY driver makes sure that your custom
font is used there (as opposed to only in text modes where
the VGA hardware does the font handling). However, it shows
the general idea.

I believe Aitor also wrote some tool long ago which works
similar but for hardware TEXT modes: The tool reads the VGA
hardware font and uses that when printing the text that you
see on the screen in text mode, printing a picture of that.
If you use DISPLAY to load a custom codepage, the VGA font
in hardware will be the font loaded from your codepage then.

A third tool would be one which reads a text FILE or poses
as a DOS printer device (like PRN or LPT1 etc) but then does
not print the text as text. Instead, it would read the font
of a codepage of your choice and send a picture of the text
in that codepage font to your printer.

While I am not aware of a nice implementation of this idea,
I once wrote a similar driver which hooked LPTn+1 (where n
is the number of real printer ports that you have) and made
graphical printouts of all text sent there using the VGA 8x8
BIOS font to print huge amounts of text on one sheet of paper
but at the expense that printing happens only every 3 lines,
as I had a 24 "pin" printer at that time ;-) Of course this
meant that only plain text could be printed to LPTn+1, and
that you had to be careful printing to LPT1 while the tool
was active because LPT1 was where the actual printer was.

> 5) Somehow "send" those codepages to the printers' RAM. (I'm aware
> that unfortunately not all printers might provide such a feature.)

I know that the 24 "pin" printer had that feature. You could
overload few, many or all character shapes depending on how
much of the RAM in the printer you wanted to spend: The more
characters you overloaded, the shorter the built-in FIFO RAM
buffer for printing would go, in the said 3 possible steps.

>      (At least in my mind,) this particular step would require some 
> software to somehow analyze the codepages encoded into the FreeDOS 
> codepage libraries (CPX files) and send the necessary info to the 
> printers' RAM.

That would be a relatively easy transform as far as I remember,
the font encoding for sending custom characters was relatively
straightforward. I think Nx8, Nx16 and Nx24 font sizes could be
loaded, with some 8 to 9 and 16 to 24 upscaling done by the ROM
software of the printer to work on 9 / 24 pin hardware modes.

Also, N could be different for each character if you selected
sending a proportional spacing font. As DOS codepages are made
for VGA, which has fixed character sizes, you could only check
whether characters have extra empty space at the sides and then
condense that to say one empty pixel after each character, to
automatically calculate a proportional spacing. Of course this
has to be user-selectable if you implement it at all, otherwise
ASCII arts and text screenshots would break. Those only work in
fixed spacing fonts, obviously :-)

> Such step would naturally not be necessary to deal with 
> regular codepages, like 858 or 808...

You assume that printers have codepage 858 in hardware. The
set of implemented codepages varies wildly and 858 which is
850 plus Euro sign will probably NOT be implemented in older
printers but then it is a good example how loading only ONE
character (Euro) in the printer RAM can efficiently implement
some codepage by starting from another codepage, e.g. 850 :-)

Some printers would for example support ASCII, 437, 850 and
something Asian (Katakana?) or Russian, but not necessarily
anything which is equal to any particular DOS codepage. You
would probably want to have a look-up table to work around
some differences. On the other hand, switching DIP switches
to select a codepage cannot be done in software, and sending
an escape sequence to select a codepage has to be done only
once (until a reset code arrives) so you could make a tool
which works on the COMMAND LINE and lets the user send such
escape sequences, as opposed to a driver which would do it
in more fancy ways (e.g. uploading fonts to printer RAM or
doing mapping with a look-up table or printing text using
images etc).

I hope this mail explains more than it is confusing :-)

Eric


------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Reply via email to