Trouble with A0 Byte in Bitmap Generation [Fortran]

Prev: access pointer to pointer from Fortran
Next: gnuplot-x2tics

From: ken qaws on 19 Feb 2010 13:20

I'm trying to generate a .bmp file using g77. Assuming I've opened a
formatted file on unit 20, I could write the byte 0B (for example)
with

write (20, '(a1, $)') char(11)

This approach works great with char(0), . . . , char(9) and
char(11), . . . , char(255). It fails for char(10): Instead of 0A, I
get the pair of bytes 0D 0A (It looks like a CRLF character). I've
tried various approaches; no matter how I attempt to write 0A, the
result is always 0D 0A.

I can solve this problem by using an unformatted file, but I get a
different issue: Four undesired leading and trailing bytes, which seem
to contain the number of records in the file. (I also have a strange
slowness issue which I haven't investigated yet.)

I'd appreciate suggestions on how to write a bitmap file which doesn't
require ugly post-processing with a hex editor.

From: e p chandler on 19 Feb 2010 14:36

From: Arjan on 19 Feb 2010 14:38

> I'd appreciate suggestions on how to write a bitmap file which doesn't
> require ugly post-processing with a hex editor.

I can send you some sample code based on fortran-90.
At least it shows how to solve your problem in Fortran, albeit a
different version.
Contact me at arjan.van.dijk [at] RIVM.nl.

A.

From: e p chandler on 19 Feb 2010 14:49

On Feb 19, 1:20 pm, ken qaws <kenq...(a)gmail.com> wrote:
> I'm trying to generate a .bmp file using g77. Assuming I've opened a
> formatted file on unit 20, I could write the byte 0B (for example)
> with
>
> write (20, '(a1, $)') char(11)
>
> This approach works great with char(0), . . . , char(9) and
> char(11), . . . , char(255). It fails for char(10): Instead of 0A, I
> get the pair of bytes 0D 0A (It looks like a CRLF character). I've
> tried various approaches; no matter how I attempt to write 0A, the
> result is always 0D 0A.
>
> I can solve this problem by using an unformatted file, but I get a
> different issue: Four undesired leading and trailing bytes, which seem
> to contain the number of records in the file. (I also have a strange
> slowness issue which I haven't investigated yet.)
>
> I'd appreciate suggestions on how to write a bitmap file which doesn't
> require ugly post-processing with a hex editor.

Follow up:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\temp>type x.f90
implicit none
integer i

open(10,file='foo.dat',form='unformatted',access='stream')
do i=0,255
write(10) achar(i)
end do
close(10)

end

C:\temp>g95 x.f90

C:\temp>a

C:\temp>debug foo.dat
-d 100 l100
0B03:0100 00 01 02 03 04 05 06 07-08 09 0A 0B 0C 0D 0E
0F ................
0B03:0110 10 11 12 13 14 15 16 17-18 19 1A 1B 1C 1D 1E
1F ................
0B03:0120 20 21 22 23 24 25 26 27-28 29 2A 2B 2C 2D 2E 2F !"#$
%&'()*+,-./
0B03:0130 30 31 32 33 34 35 36 37-38 39 3A 3B 3C 3D 3E 3F
0123456789:;<=>?
0B03:0140 40 41 42 43 44 45 46 47-48 49 4A 4B 4C 4D 4E 4F
@ABCDEFGHIJKLMNO
0B03:0150 50 51 52 53 54 55 56 57-58 59 5A 5B 5C 5D 5E 5F
PQRSTUVWXYZ[\]^_
0B03:0160 60 61 62 63 64 65 66 67-68 69 6A 6B 6C 6D 6E 6F
`abcdefghijklmno
0B03:0170 70 71 72 73 74 75 76 77-78 79 7A 7B 7C 7D 7E 7F
pqrstuvwxyz{|}~.
0B03:0180 80 81 82 83 84 85 86 87-88 89 8A 8B 8C 8D 8E
8F ................
0B03:0190 90 91 92 93 94 95 96 97-98 99 9A 9B 9C 9D 9E
9F ................
0B03:01A0 A0 A1 A2 A3 A4 A5 A6 A7-A8 A9 AA AB AC AD AE
AF ................
0B03:01B0 B0 B1 B2 B3 B4 B5 B6 B7-B8 B9 BA BB BC BD BE
BF ................
0B03:01C0 C0 C1 C2 C3 C4 C5 C6 C7-C8 C9 CA CB CC CD CE
CF ................
0B03:01D0 D0 D1 D2 D3 D4 D5 D6 D7-D8 D9 DA DB DC DD DE
DF ................
0B03:01E0 E0 E1 E2 E3 E4 E5 E6 E7-E8 E9 EA EB EC ED EE
EF ................
0B03:01F0 F0 F1 F2 F3 F4 F5 F6 F7-F8 F9 FA FB FC FD FE
FF ................
-q

C:\temp>

--- e

From: Richard Maine on 19 Feb 2010 15:39

e p chandler <epc8(a)juno.com> wrote:

> Maybe. A formatted file is a file of text records. LF is being
> translated to CR/LF on output in this case even though you specify '$'
> which is a non-standard edit descriptor for suppress end-of-line.

That would be normal. Of course, as noted, the $ edit descriptor is
non-standard, so pretty much nothing can be guaranteed, but the "normal"
expectation would be that it just act like advance='no', which
suppresses the otherwise automatic end-of-record that you get at the end
of the write. It does not suppress record ends generated for any other
reason, including / edit descriptors, format reversion, or writing
newline characters to the file as data.

The OP is trying to write what is inherently unformatted data. Using
formatted I/O for that is full of problems, this being only one of them.

> Before trying to answer your question directly, let me suggest that
> you upgrade to g95 or gfortran. They both support "stream" I/O - a
> Fortran 2003 construct - which allows reading and writing single raw
> bytes. (access='stream'). Other compilers have other non-standard ways
> of accomplishing this as well.

Yes. I strongly recommend that as the preferred general direction -
either the f2003 standard stream I/O or one of the earlier
compiler-specific variants.

> If you are restricted to G77, you could try a direct access file with
> a record length of 1 byte. I think it's formatted but I don't use this
> feature.

Direct access is either formatted or unformatted, whichever you specify,
just like sequential. Unformatted is what you want.

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

| Next | Last
Pages: 1 2
Prev: access pointer to pointer from Fortran
Next: gnuplot-x2tics