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 Freedosfirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/freedos-user