Hello,

2011/5/5 Eric Auer <e.a...@jpberlin.de>:
> 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.

I think you refer to one that didn't print, but created a BMP file out
of it (good enough for what I needed, even if it wasn't too complex).

> 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.

This would be a way to create printer hardware handlers: if you write
a way to send that picture to the specific printer: printing in
"graphics" mode, bypassing any ways of the printer to load and use
codepages.
Programmers are welcome, I will give as much help understanding
DISPLAY as needed.

> 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.

If you can recover it, such driver can be created (so there would be a
binary PRINTER.SYS-style driver for FreeDOS).

>>      (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 :-)

As said above, if you volunteer....  (in assembler)

Aitor

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Reply via email to