Obviously it is quite complicated and inelegant to first print a digital document and then to have the fax device re-digitalize the printed paper again before finally sending it to the addressee. Hardware components like Fritz Card, ISDN Card and such overcome this problem by virtually establishing a short circuit between computer and telephone line - and along with them a huge market for Fax Software arised, which drives these hardware components in order to send data through them. Now if you as a software developer intend to offer your clients a tailor-made Fax Software, by which the end user can print his digital documents without fax device, virtually directly into the telephone line, then you encounter two basic problems: How is my software supposed to know when the user requests the print process, or fax process, respectively ? How is my software supposed to get access to the graphical data and the text of the digital document destined to be printed, or faxed, respectively ? The only solution: A printer driver, which writes the graphical data and the text of the digital document destined to be printed, or faxed, respectively, into files, and notifies your software about all print processes, print events and filenames, so that your software can react to it and all that is done by Doc2Fax printer driver. When user requests a digital document (for example *.doc., *.ppt, *.xls, *.html, ) to be printed, the Doc2Fax printer driver * puts out one black-and-white-image in bitmap format (*.bmp) containing the graphic information for each page of the document to be printed (alternatively on demand a multipage TIFF-F aka Fax Group 3) * puts out one txt-file containing the text information for each page of the document to be printed. This later on allows keyword search, especially in large fax documents. * on print events starts the program or application, which you as software developer have scheduled for this case in configuration file