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