Yes Eric, now that you mentioned that, it was what I did with that Epson LX-800 printer that I had - but, as I had said, I used MS-DOS 6.0 and QBASIC for that. Developing a wholly independent program for that is something else - which I don't know how.
My question is still up, Eric: Would you be interested? I know that you said "regarding your question" but I think I didn't understand what you meant. Let me see - your idea was to give coordinates on how to do the whole thing? If it was that, it was helpless. I'm sorry. It seems that you have the knowledge to develop the "printer driver" (well, a program that would send pixel data to printers). I could enter with the info on the pixel data itself. I have a huge text file with many glyphs in the format below. You'll see the Euro sign as an example. That huge text file is composed primarily by extracted data from the 8x16 font files of all codepages that I had prepared for FreeDOS' CPI files until 2006. That was part of a partnership between me and Mateusz Viste for his Foxtype Unicode text file viewer for FreeDOS. He provided the software that extracted data from the font files. In a following step, I edited that huge text file directly to enter more Unicode chars which weren't (some still aren't) part of any codepage. #20AC ........ ........ ........ ..@@@@.. .@@..@@. @@...... @@@@@... @@...... @@@@.... @@...... @@...... .@@..@@. ..@@@@.. ........ ........ ........ The number refers to the hex code (Unicode). Naturally, every dot would be a "0" and every "@" would be a "1"; with a little math, we have pixel data for any printer. The following step would be to create association files. I would prepare them. Let's say that we would have a file called "CP858.TXT", which would be checked by, let's say, "PRINTER.EXE". There would be a line which would read: D5, 20AC Then, I would run C:\> PRINTER 858 Now, PRINTER.EXE knows that it would have to check CP858.TXT. If, when intercepting data being sent to a printer, it receives byte D5h, it would send the glyph code 20AC from the text file I have here. You see, Bert and Eric, that in what concerns the characters themselves, I have that figured out already (ok, perhaps I missed something - if you feel that to be the case, please let me know). However, in what concerns *how to send the data to the printer*, someone else will be needed for that. I think that you both agree that we could forget about the idea of developing software to extract data from CPI files (no matter who would do that). That leaves another variable out of the equation and simplifies the whole process, in my opinion. Cheers, Henrique Em 5/5/2011 20:09, Eric Auer escreveu: > > Hi Henrique, Bret, > >> interesting to know that there's someone out there, familiar to FreeDOS, >> still using those 9-pin printers. At least here in Brazil they're still >> used on lots of places because of their low operational cost. >> >> Well, Eric and Konstantyn... So much for the museum idea! > > Well... We had a 24 pin printer 20 years ago and I patched some closed > source tools which were hardcoded for a 9 pin printer from 25-30 years > ago to work with that new printer when the old 9 pin broke, so... ;-) > > Anyway, regarding your question and the comment from Bret: I think you > can do quite a bit with ESC/P, HP PCL and PostScript when you stick to > basic feature sets, as those tend to be in the "common denominator" of > things supported by different variants of said printer languages. You > can check the FreeDOS GRAPHICS source codes for the general idea if > you like, Bret :-) > > The short story for printing text as graphics is as follows: You send > some ESC sequence to initiate graphics mode, then you send a header > sequence saying that N columns of pixel data follow and then you send > the pixel data as either 1 or 3 bytes per column (8 or 24 pins used). > > For 24 pins, you can either scale a VGA font, increase margins, or both, > or design a special printer font. I think scaling 8x8 would be a bit > pointless (can just use low quality 8 pin mode then, even 24 pin head > printers support that) so I would either go for 8x16 and leave 8 pins > unused (line spacing and thus papere movement per line of graphics are > adjustable after all) or try to tweak-scale 8x14 to "ca 2 times 8x12". > > For PostScript and HP PCL, the pixel data formats are different, but > you can be very creative with PostScript anyway. Actually uploading > a font might be a good choice for the latter, or turning the font to > some sort of "rendering macro" that you would send as "header" before > the text that you want to be printed. > > As far as I remember, HP PCL pixel data was row oriented, so you send > all pixels for one stripe of paper (e.g. as wide as suitable to print > 80 characters if that is the output style you have in mind) at a time > and the printer itself decides how to pool pixels to avoid having to > move the print head too much. Usually it would flush the pool when a > page gets full or no new data arrives for a certain amount of time. > > Regards, 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-user ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-user
