forums.silverfrost.com

[wahorger]

I have run across a problem using TRANSPARENT to create a file. I have two different methods of creating the file (shown below) but one of these has an "occasional" problem.

The file contains printer command codes for driving a graphic printer directly. The data are generated by the remainder of the code (too big to post) which creates an in-memory image of the rasterized data. I chose TRANSPARENT to allow the CRLF characters to NOT be transmitted unless needed.

And one byte is missing from the file (actually, many, but the first one can be easily found). I ran both methods of file generation (below), and the one that does not use the building of a character string in memory containing the raster data fails.

The binary comparison of the two files shows the following first error occurrence.

[JohnCampbell]

The extra character looks to be a hex 20, which is a space character, probably associated with the format statement. Have you written a zero-length string, which may provide a minimum of 1 space character ?

Why do you open it as formatted ?
You could open the file as unformatted and then write the info, omitting the format statement number. I'd expect this would produce the same file. ( checking that I >=1)

John

[wahorger]

It's a pain, but the fact that this occurrence is a SPACE character may be incidental. Note that the format is all 99A1. There are a LOT of other characters missing from the file (difference in byte counts).

Looking at the two sections of code, there is nothing substantially different. The non-working version was supposed to be transitional to the working code in any case, except that it should work as well. Perhaps there is something with trailing spaces that this is affecting (?).

If you open it as formatted, then you ALWAYS get the CRLF combination at the end, and that is NOT necessarily what one needs when doing raster graphics to a print device. The CRLF combination may lead to spaces (blank sections) in the displayed/printed graphics. TRANSPARENT is supposed to remove the CRLF at the end; if it removes a trailing space, then that's probably the culprit for all the missing data. However, if it does, then it doesn't meet the definition of TRANSPARENT in the documentation (at least not the way I read it).

I'm getting pretty good at the "C" to FTN95 interface, and if I have to, I can make sure to get around a trailing SPACE problem as well. But, I'd prefer not to!

[JohnCampbell]

I have only used TRANSPARENT with UNFORMATTED. I have not found the problems you are describing.

Try changing to UNFORMATTED in the OPEN. All you need to do is remove the format number in the WRITE and I'd recommend checking as:

IF ( I >= 1) then
WRITE (99) raster_master(1:i)
else
write (*,*) 'zero length string request'
end if

Also find all use of unit 99, you never know !

John

[wahorger]

I am going to give the UNFORMATTED version a shot. More investigation to follow.

The only unit I open explicitly as 99 is for this usage. All other FTN units are opened/closed in a common routine that returns a FTN unit number as transparently as possible. That way, on different platforms, I need only to change the one routine. Unit 99 is convenient for me because it is not in the list of possible units for other portions of the software.

Eventually, even 99 will disappear as I will incorporate this TRANSPARENT open into the common utility for even this narrow usage, and use the transparently assigned unit number.

[mecej4]

Rather than using the nonstandard extension TRANSPARENT, please consider using ACCESS='STREAM', which is covered by the Fortran standard and would make your code portable.

[wahorger]

Great idea using STREAM.

However, this yields a compiler error that STREAM is not a valid option for the keywords ACCESS. FTN 2003?