Direct printer access from FTN95 program

I have been unable to print my output from a FTN95 program, & the 'help' section of the compiler has no understandable (to me anyway) information on what to do nor is it present in Chapmans book. What I need is an example which will output characters & numbers to the printer which I can use in my own programs. I have the printer port designation & am using the Plato IDE in a Windows xp environment.

Thanking you in anticipation,

Bernard Mitchell.

Here is an extract from the help file...

FTN95 permits you to write directly to a given device. For example,

OPEN(UNIT=8, FILE='LPT1:')
WRITE(8, '(A)') 'Output to printer'
CLOSE(8)

This does not work on some machines and requires the printer to be connected directly to the PC.

Alternatively you can write formatted output to a file and then print the file using Plato or Notepad for example.

You can also print using ClearWin+. Further details are given in the help file.

Paul,

I tried to supplement your answer by noting that if the printer is a PostScript or Windows Printer, this approach won't work. Also, there are some ports that have a name as far as Windows is concerned, but you don't seem to be able to send straightforward Fortran output to them (I think various USB ports might be mentioned here - although these do tend to have Windows Printers on them).

Hence, for foolproof output, one needs to make sure that the Fortran output goes via the printer driver. In the callback section of a call to winio@ I use a sequence such as:

... 'PRINTER_OPEN',8,Printing_FUNCTION ...

to connect Fortran Unit 8 to a user-selectable printer, and then go on to 'Printing_FUNCTION' to do the actual formatted writing using Fortran write statements. This always works, regardless of whether the printer is PostScript, a Windows Printer, etc.

It occurred to me that if one was running a non-windows application, one might still need to go through windows to make sure that writing would work. So I knocked up the following:

   WINAPP  
   OPTIONS (INTL)
 
   PROGRAM TRY
   INCLUDE 'WINDOWS.INS'
   CHARACTER*40 DEV, PORT
   IA = SELECT_PRINTER@ (DEV,PORT)
   OPEN (8, FILE=DEV)
   WRITE(*,*) 'DEV=', DEV, '  PORT=',PORT
   WRITE(8,*) 'Got it in one!'
   CLOSE (8)
   END

(I also tried FILE=PORT in the OPEN statement instead of FILE=DEV).

A good try, but it doesn't work. My printer is a networked HP colour laserjet. The SELECT_PRINTER@ gave me the printer selection, and my pop-up window showed me the correct info for the selected printer. However, my message went to a file, not to the device or port.

I was left wondering what use SELECT_PRINTER@ is, and also how to send output via the windows printer driver even from a console app. The OPEN_PRINTER@ and OPEN_PRINTER1@ functions seem to be for graphics only, and thus are not equivalent to the standard callback functions PRINTER_OPEN and PRINTER_OPEN1.

Incidentally, CHARACTER*20 (as recommended in the FTN95.chm) isn't long enough - at least not for my printer.

I read, some time ago, in the comp.lang.fortran group that Fortran only has files, not devices, in the standard, and so writing to a device is an extension.

Regards

Eddie

Hi Eddie,

You might have more luck using the Windows API routines OpenPrinter, StartDocPrinter, StartPagePrinter, WritePrinter, EndPagePrinter, EndDocPrinter and ClosePrinter. The documentation on these can be found on MSDN: http://msdn2.microsoft.com/en-us/library/ms535752.aspx

Hope this helps,

Martin

One might try using the resulting port name because LPT1: is an example of a port but there is more to it than this.

The Open Printer dialog basically provides a device context to print to and something has to do the rendering to this device context.

When you use 'LPT1:' (and when it works) there must be something somewhere that is doing the rendering for you.

Martin,

The information is helpful (to me) but I suspect not to the original poster. I suppose, in the end, it depends on how far from Fortran one wants to go. I don't like to stray far from Fortran, and Fortran-77 at that!

Paul is correct to say that something must do the rendering - of course, with a basic type of printer one sends a stream of characters and the printer does the rather trivial job of 'rendering' - this is definitely not so with PostScript or a Windows GDI printer.

Eddie