Hello All,
when we print a document, the printer mostly receives the bitmap data and then displays them. If I have a printer that expect to receive text data, that is unicode charset, is it fesible to capture the text data from the parameters of DrvTextOut function called by GDI each time and then sends those string data to the printer by calling WritePrinter function? And the printer uses the STM32 as its processor. After receiving the printing data, STM32 processor extracts the glyphs of the character from the flash and then display the character on the TFTLCD so as to simulate a real printer. In other words, when a user print a document, my printer can display the text on its LCD and I want to develop my own printer driver to obtain the text data instead of bitmap data. How to develop such a printer driver?
Thanks a lot.
2393632485@qq.com wrote:
when we print a document, the printer mostly receives the bitmap data and then displays them. If I have a printer that expect to receive text data, that is unicode charset, is it fesible to capture the text data from the parameters of DrvTextOut function called by GDI each time and then sends those string data to the printer by calling WritePrinter function? And the printer uses the STM32 as its processor. After receiving the printing data, STM32 processor extracts the glyphs of the character from the flash and then display the character on the TFTLCD so as to simulate a real printer. In other words, when a user print a document, my printer can display the text on its LCD and I want to develop my own printer driver to obtain the text data instead of bitmap data. How to develop such a printer driver?
That’s how dot-matrix and inkjet printers used to work, and I believe
the unidrv components still support that. You do have to be able to
describe your embedded fonts precisely, so applications like Word can do
their word-wrapping correctly.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Is it necessary to use device-managed surface, instead of GDI-managed surface? Becasue the Unidrv uses a GDI-managed surface. I wonder how the data stream is sent to spooler when the EMF print processor plays back EMF records, call the WritePrinter each time after an EMF record is played back, or just call the WritePrint one time after all EMF records are played back?
2393632485@qq.com wrote:
Is it necessary to use device-managed surface, instead of GDI-managed surface? Becasue the Unidrv uses a GDI-managed surface. I wonder how the data stream is sent to spooler when the EMF print processor plays back EMF records, call the WritePrinter each time after an EMF record is played back, or just call the WritePrint one time after all EMF records are played back?
Do you actually have a bitmapped surface in your printer? One way to do
it is to have your driver expose a custom font handler. You might take
a look at the src\print\tty sample from the Windows 7 WDK, which is a
dumb text-only TTY printer. It doesn’t use the “surface” concept at
all. It has sample font metrics files.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>Do you actually have a bitmapped surface in your printer? One way to do
it is to have your driver expose a custom font handler. You might take
a look at the src\print\tty sample from the Windows 7 WDK, which is a
dumb text-only TTY printer. It doesn’t use the “surface” concept at
all. It has sample font metrics files.
Thanks a lot. The src\print\tty sample can completely solve my problem.