comp.sys.acorn (3389/3487) Path: cix!slxsys!uknet!acorn!osmith From: osmith@acorn.co.uk (Owen Smith) Newsgroups: comp.sys.acorn Subject: Re: Faxmodem standards and software Message-ID: <13451@acorn.co.uk> Date: 23 Mar 92 20:01:35 GMT References: <23MAR199200434270@pavo.concordia.ca> Sender: osmith@acorn.co.uk Distribution: comp Organization: Acorn Computers Ltd, Cambridge, England Lines: 187 In article <23MAR199200434270@pavo.concordia.ca> n_sabra@pavo.concordia.ca (NIZAR SABRA) writes: >I believe that there is a standard fax image format >that is compatible with all the fax/modems. How difficult would it be to >find out the file format of the image used? Would it be hard to write a >program to send/receive faxes from the WIMP? There are quite a few faxmodem >programs available for the PC's. One of them is called BitFax. This seams to >work with most of the faxmodems, and so this is how I figured that there is >a standard. Under RISC OS 3, the approach I would recommend to writing fax sending software would be to write it as a PDumper module (like PDumperDM and PDumperLJ). Thus it would all be part of the printer drivers and hence you could send a fax from any application that could print. OK so you'd need a seperate little application to set up the fax number to send to etc. or a new BASIC back-end to !Printers (see !Printers.dp.Resources.Support and similarly for lj and ps - these are the things that put up the printer control windows for each of the three different types of printer). Doing it with a !Printers back end would be best, but its probabaly more work than just using the dp (or lj) back-end with you own PDumper. The Fax PDumper shouldn't be too much trouble - across the interface from PDriverDP you get given a monochrome or 8 bit grey level sprite at the output resolution. You need to error diffuse or halftone that (there is now a module called PDumperSupport with SWIs that do this for you - its in Ace Computing's Deskjet 500C driver for RISC OS 3) and then you need to modify the data to be in the right format and output it. If you're lucky you'll find that the format is the same as for LaserJet printers, either to the extent that no code needs writing at all or maybe just some tweaks to PDumperLJ if it's TIFF format (LaserJet mode II compression) but with different control sequences to LaserJets. If you want !Printers text printing to work, and the Fax modem has no way of rendering text for you (eg. a fax modem that fully emulated a LaserJet would be able to do it) then there is some work to be undertaken to write a !Printers back end which would do text printing using the font manager and the printer driver SWIs. Personally I wouldn't bother - you can always fax your text files with !Draw or Impression instead. Under RISC OS 2 you could also do it as a printer driver, but the source code package from Acorn is essential for this and is quite large. (On RISC OS 3 while it is better to use the Acorn source code the more adventurous could almost certainly knock up a PDumper without source.) Here is a whirlwind tour of the RISC OS 3 printer drivers: Applications ------------ The !Printers application is itself split into a front end core in ROM, and back-ends on disk inside the !Printers application directory on App1. More of these can be added by ISVs (eg. LaserDirect and Fax). The front end handles the text printing queue, reading printer definition files, much of the FirstWord+ text printing engine etc. The back ends handle the printer type specific stuff, such as controlling the printer configuration windows and passing the information to the modules. Nearly all of !Printers (both front and back ends) is in BASIC, there is also a small amount of machine code. The back-ends are loaded up as BASIC overlays. !Printers (front-end core in ROM) | | +----------------+----------------+ | | | PS - PostScript LJ - LaserJet DP - dot matrix (back-ends on disk) !PrintEdit, on App2, is a stand alone application for editing dot matrix and LaserJet printer definition files (PostScript ones are done by hand with !Edit - they only consist of a list of fonts the printer supports anyway). If an ISV or indeed a user needed to make a small change to some Epson codes we were sending to a printer (because their printer is not quite compatible) they would just use !PrintEdit to modify the appropriate string in the printer definition file. (This is equivalent to using !Edit to edit your PrDate file under RISC OS 2.) Files ----- The printer definition files sit on App2 in the Printers directory. Inside the Printers directory there is a directory per printer manufacturer (eg. Epson, Star, Apple etc.). Inside each manufacturer directory there is a Read_Me file and some printer definition files (eg. FX-80). The Read_Me files give some technical detail on what is in each definition file, paying attention to tricky areas to guide people who may want to modify the files or who want to work out from their printer manual which file to use. The Read_Me files also give some guidance on which files to try for "compatible"" printers. Modules ------- PDriver | +--------------------+----------------+ | | PDriverPS PDriverDP | +-------------------+---------------+ | | | PDumperLJ PDumperIW PDumperDM PDriver, PDriverDP and PDumperDM are in the ROM. The rest live on disk inside !Printers. (All of these modules are written in assembler.) The purpose of PDriver is merely to share the PDriver SWI chunk, such that it is possible to have multiple resident printer drivers. PDriverPS is the PostScript printer driver and apart from connecting to PDriver to share the SWI chunk it's job is the same as under RISC OS 2. PDriverDP renders print jobs into bit image strips. The strips are then passed to the appropriate PDumper for it to output the bit image in an appropriate manner for the printer types it knows about eg. LaserJet for PDumperLJ, ImageWriter for PDumperIW and Integrex/Epson for PDumperDM. (Note that PDumperDM is effectively two PDumpers in one. This was done to save ROM space.) The PDumper is also responsibe for performing colour matching, error diffusion and halftoning. There is an additional module called PDumperSupport (in the ROM). This can be used as a resource by any PDumper that is happy to use the Acorn colour matching, halftoning and error diffusion, as it provides SWIs to perform those functions. In RISC OS 3.00, all the PDumpers had the same code in them to do this job. An ISV may chose to not use this module and have his PDumper do this job itself. Another option is to replace the PDumperSupport module to modify the colour matching etc. performed by the Acorn PDumpers. Note that there is NOT a one to one correspondence between PDumper modules and !Printers application back-ends. The DP back-end caters for both PDumperIW and PDumperDM. PDumper palette files (held in !Printers) are read in by the PDumperSupport module. Third parties. -------------- There are several levels of things third parties could supply: 1) Printer definition files. This is the easy option - it merely involves creating a new file (or more likely modifying an existing one) with !PrintEdit for your particular printer. This may be for as trivial a reason as changing the name to match a particular printer, to make things more obvious to the user or it may involve changing sequences to make things work better (or work at all) with a particular printer. 2) New PDumper. This would be done when the existing PDumpers don't understand the output format of the printer (eg. the ImageWriter dumper) or when you want to optimise things for your printers (eg. printing on 20 out of 24 pins, providing new colour matching/halftoning etc.). A new PDumper is virtually garunteed to have a new printer definition file to go with it. Sometimes !PrintEdit will be capable of creating this (eg. 20 out of 24 pins, ImageWriter), sometimes you will need to do them by hand, modify !PrintEdit or write your own tool. (eg. PDumperLJ for LaserJets except in that case we took the cop-out option of embedding the graphics control sequences into the PDumperLJ module - this was a mistake). You might also supply a new palette file for your dumper. 3) New !Printers back-end, and matching PDumper. This would be done for a very different type of printer eg. direct drive laser printers, fax. While these printers are still bit image and thus can use a PDumper sat under PDriverDP, they need new text printing code and new printer connection management (you can't fasten it to the parallel port) and hence need a new !Printers back end to handle all that. The LaserJet is a good example of this - it uses a PDumper yet it has its own !Printers back end. 4) New !Printers back-end and new printer driver under PDriver. This is done for radically different types of printer eg. PostScript is done this way. A pen plotter or turtle graphics printer driver might need this option. It is likely that Computer Concepts will take this approach since they already have their own printer driver. 5) A "sideways" option for a third party would be to provide a new palette file and/or a new PDumperSupport module. This would modify the colour balance while still using the Acorn drivers and PDumpers. PostScript ---------- For the sake of clarity, the above descriptions ignore the MakePSFont module (written in C - shock horror probe!). This resides on disk inside !Printers, and it is used by both !Printers and PDriverPS for building PostScript Prologues that handle font declarations intelligently and do on the fly font downloading. The !FontPrint application (in C too!) also has a hand in this since it can be used to permanently download fonts to the printer. Owen Smith, Acorn Computers. 23rd March 1992. The views expressed are my own and are not necessarily those of Acorn.