Re: Reading BMP graphic file

Jan Vorbrüggen <Jan.Vorbrueggen@xxxxxxxxxxxxxxx> wrote:

It seems that ACCESS='transparent' is not supported.
I tried FORM='UNFORMATTED', since I saw no other specifyer in the
above call for opening the file as unformatted/binary, but that didn't
work.

UNFORMATTED won't do because the file still contains or the RTL still
expects record markers.

Odd. I don't recall the details, but is BMP really a text file format?
That would seem surprising. In particular, I wonder what the nature of
the record markers is. Are they the normal text record markers for
whatever system you are running on? If that is the case, then the file
format would be non-portable without transofmation. You would have lf
for some systems, cr/lf for others, cr for others, and a completely
different scheme for yet others.

If the format has "record markers" whose form is defined as part of the
format rather than being whatever the host system happens to use for
text files, then that would be something most appropriately and portably
dealt with as unformatted - not formatted. Just because the file has
something called a record marker, that doesn't automatically translate
into "formatted access".

"Formatted" is for text files; that's really all. Using it for anything
other than text is fraught with "issues". I've done it on rare occasion,
but it has many portability complications and is best avoided. I can't
even recall all the different kinds of complications I've seen with it.
This posting would get long and side-tracked if I tried.

I'll just repeat and summarize a point mentioned by others in the
thread. Prior to f2003, there is no portable way to deal with files hat
are arbitrary byte streams defined by non-Fortran means. Most pre-f2003
compilers have some extension for the purpose. It has been quite a while
since I've run into an exception. There are early f77 compilers that
can't do it, but I can't off-hand name one. I think I recall Lahey ELF90
as being an exception of sorts, but then that didn't actually claim to
be a Fortran compiler; rather it compiled a subset of Fortran that Lahey
called ELF. The Lahey Fortran (as opposed to ELF) compilers could do it
fine.

The extensions in various compilers even have structural similarities,
and there are groups of compilers that share the same syntax for them.
But you won't find a form that works unchanged on all compilers. You
might possibly find one that works on a sufficiently large subset to fit
some particular need, but it won't work on others.

So you can do the job pre-f2003. I have quite a lot of experience in
such things, as do others here. But don't expect to do it portably.

That's a lot of why f2003 standardized the feature. There is a lot of
debate about some things in the standards process, but this one fits
most people's criterion for the kinds of things that beg for
standardization. It was a feature widely regarded as important enough
for all current compilers to implement, but the implementations were
different in syntax from compiler to compiler.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
.

Relevant Pages

  • Re: Interpretation of literal reals
    ... Do note, however, that in f77 this does *NOT* apply to internal I/O, as used in your example. ... List-directed formatting is not allowed for internal files in standard f77, and there used to be f77 compilers that didn't do it. ... In cases where the input data is always generated by a formatted write, I might relent and allow the same format to be used for reading, even though it has something other than ".0". ...
    (comp.lang.fortran)
  • Re: Many small programs vs. one large program?
    ... code format, etc... ... format, not the input or output data files... ... many compilers, I believe Intel's are among them, ... Many DEC-heritage compilers, including CVF and IVF, allowed "tab ...
    (comp.lang.fortran)
  • Re: reading variably sized floats
    ... the nX or An) format field specifier. ... While that is a likely behavior with most compilers, ... it is *NOT* behavior specified by the standard. ... number of replacements blanks, or the definition of tab points, to be ...
    (comp.lang.fortran)
  • Re: OpenVMS I64 Compilers (was: Re: Intel to chip away at Itanium prices <- or ... )
    ... :object files as UNIX, so keeping the compilers current should be a lot ... OpenVMS is using the Intel Itanium Executable and Linkable Format ...
    (comp.os.vms)
  • Re: <ctype.h> toLower()
    ... See the C Standard. ... >> creating and your code includes your implementations tolower function ... It may be portable within a limited amout of compilers that you think are ... portability however the identifier is not portable as it only works on ...
    (alt.comp.lang.learn.c-cpp)