Re: C and faxes

[George]

On Sun, 02 Nov 2008 20:09:29 -0600, Jack Klein wrote:

>Grateful for any hints,

Perhaps you should visit the C Unleashed page on my web site:

http://jk-technology.com/C_Unleashed/code_list.html

One of the source files linked is:

"text2bin.c 240,894 This program generates binary pixel image files,
suitable for encoding by encode.c, from ASCII text files (see
Chap18.txt for more information). Note size, contains large character
generator arrays!"

I've gotten farther on this, now that I have a C compiler and have had time
to get my head around the T.4 encoding. What I don't see now is a
relationship between hello.txt, which simply contains the 5 characters of
hello, the encoding in text2bin.c, which is not the T.4 encoding, and the
output, bin2.dat:
C:\MinGW\sourcegcc -o t2b text2bin.c

C:\MinGW\source>t2b hello.txt bin2.dat
t2b processing
Finished converting 1 lines

C:\MinGW\source>

/* character 48 = H */
{
0xFFFF, /* 1111111111111111 **************** */
0xFFFF, /* 1111111111111111 **************** */
0x0FC3, /* 0000111111000011 ....******....** */
0x0FC3, /* 0000111111000011 ....******....** */
0x0FC3, /* 0000111111000011 ....******....** */
0x0FC3, /* 0000111111000011 ....******....** */
0x0003, /* 0000000000000011 ..............** */
0x0FC3, /* 0000111111000011 ....******....** */
0x0FC3, /* 0000111111000011 ....******....** */
0x0FC3, /* 0000111111000011 ....******....** */
0x0FC3, /* 0000111111000011 ....******....** */
0x0FC3, /* 0000111111000011 ....******....** */
0xFFFF, /* 1111111111111111 **************** */
0xFFFF, /* 1111111111111111 **************** */
0xFFFF, /* 1111111111111111 **************** */
0xFFFF, /* 1111111111111111 **************** */
},

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ*ÿÿÿü ?ü?ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÃÿÿÿü?ü?ÿÿÿÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÃÿÿÿü?ü?ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÀÀü?ü?Àÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÃÃÃü?ü?Ãÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ÃÃÃü?ü?Ãÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÃÃ
--

George

The momentum of freedom in our world is unmistakable - and it is not
carried forward by our power alone. We can trust in that greater power Who
guides the unfolding of the years. And in all that is to come, we can know
that His purposes are just and true.
George W. Bush

Picture of the Day http://apod.nasa.gov/apod/

[Ben Bacarisse]

George <ge****@example.invalidwrites:
<snip>

I've gotten farther on this, now that I have a C compiler and have had time
to get my head around the T.4 encoding. What I don't see now is a
relationship between hello.txt, which simply contains the 5 characters of
hello, the encoding in text2bin.c, which is not the T.4 encoding, and the
output, bin2.dat:
C:\MinGW\sourcegcc -o t2b text2bin.c

C:\MinGW\source>t2b hello.txt bin2.dat
t2b processing
Finished converting 1 lines

ÿÿÿÿÿÿÿÿÿÿÿ...

<snip binary data>

This is not really a C question, is it? The output should be 16*216
bytes in size (216 is 1728/8 and 1728 is the width of the image) and
will only make sense if you look at it as 2D bit array. At the least
you need to line up each of the 16 216-byte rows to see any pattern.

To bring it back to C (rather than what is in essence a file format)
try this "reverse" program that shows the first 80 bits of each line
from such a file. It might help explain what text2bin has done.

#include <stdio.h>
#include <stdlib.h>

#define OCTETS_PER_LINE 216
#define OCTETS_TO_SHOW 10

void show(unsigned char *bits)
{
int i;
for (i = 0; i < OCTETS_TO_SHOW; i++) {
unsigned int mask;
for (mask = 1 << 7; mask; mask >>= 1)
putchar(bits[i] & mask ? ' ' : '#');
}
putchar('\n');
}

int main(int argc, char **argv)
{
FILE *fp;
if (argc == 2 && (fp = fopen(argv[1], "rb"))) {
unsigned char line[216];
while (fread(line, sizeof line, 1, fp) == 1)
show(line);
return EXIT_SUCCESS;
}
else fprintf(stderr, "No file name, or it could not be opened.\n");
return EXIT_FAILURE;
}
--
Ben.

[George]

On Thu, 13 Nov 2008 03:57:34 +0000, Ben Bacarisse wrote:

George <ge****@example.invalidwrites:
<snip>

>I've gotten farther on this, now that I have a C compiler and have had time
to get my head around the T.4 encoding. What I don't see now is a
relationship between hello.txt, which simply contains the 5 characters of
hello, the encoding in text2bin.c, which is not the T.4 encoding, and the
output, bin2.dat:
C:\MinGW\sourcegcc -o t2b text2bin.c

C:\MinGW\source>t2b hello.txt bin2.dat
t2b processing
Finished converting 1 lines

ÿÿÿÿÿÿÿÿÿÿÿ...

<snip binary data>

This is not really a C question, is it? The output should be 16*216
bytes in size (216 is 1728/8 and 1728 is the width of the image) and
will only make sense if you look at it as 2D bit array. At the least
you need to line up each of the 16 216-byte rows to see any pattern.

To bring it back to C (rather than what is in essence a file format)
try this "reverse" program that shows the first 80 bits of each line
from such a file. It might help explain what text2bin has done.

I can't believe it!

// gcc -o out ben1.c
// out bin2.dat

http://i429.photobucket.com/albums/q.../fortran28.jpg

I'll need more time to pick through this along with encode.c and decode.c,
but this is progress. Thanks for your interest.

One question at this point. I don't fully understand the relationship
between unsigned shorts, octets, and the number of bits. Is it fixed by
the following in limits.h?

#define CHAR_BIT 8
#define MB_LEN_MAX 2

#define SCHAR_MIN (-128)
#define SCHAR_MAX 127

#define UCHAR_MAX 255
--
George

Natural gas is hemispheric. I like to call it hemispheric in nature because
it is a product that we can find in our neighborhoods.
George W. Bush

Picture of the Day http://apod.nasa.gov/apod/

[Nick Keighley]

On Nov 13, 8:01*pm, George <[e-mail]:

<snip>

One question at this point. *I don't fully understand the relationship
between unsigned shorts, octets, and the number of bits.

An unsigned short holds an unsigned value of at least 16-bits.
It is greater or equal in size to a [unsigned] char. It is less than
or equal to a [unsigned] int.

A [unsigned] char must be at least 8-bits. In the C language it is
always
one byte in size (or byte may be greater than 8-bits in C).

An octet is not mentioned in the C Standard but is usually defined to
be exactly 8-bits. Communication protocols often specify things in
octets as it it less potentially ambiguous than the term byte.

Hence a short may be 1, 2 or even more bytes. But it cannot be less
than two octets.

Note the above assumes there are no non-representaional bits (eg.
padding)
all bits are used for representing the value. Most, but not all,
implementations
do this.

>*Is it fixed by
the following in limits.h?

the size of unsigned short (more properly the range) for a perticular
implementaion is fixed by this header. Octet, of course, is not
described
by this header.

#define CHAR_BIT * * * *8
#define MB_LEN_MAX * * *2

#define SCHAR_MIN * * * (-128)
#define SCHAR_MAX * * * 127

#define UCHAR_MAX * * * 255

so ***on this implementation*** an unsigned char has a range
from [0..255]. The bit you have quoted doesn't restrain unsigned short
it any way

<snip>
--
Nick Keighley

[George]

On Fri, 14 Nov 2008 05:01:34 -0800 (PST), Nick Keighley wrote:

An octet is not mentioned in the C Standard but is usually defined to
be exactly 8-bits. Communication protocols often specify things in
octets as it it less potentially ambiguous than the term byte.

Hence a short may be 1, 2 or even more bytes. But it cannot be less
than two octets.

I had to sleep on this a bit to understand. With Jack's treatment of
faxes, if char_bits were 9, you would say "nontet" where you read octet,
and (I think), you would still be guaranteed to have two of them in an
unsigned short.

sextet--impossible in C
63-tet--possible
--
George

Some folks look at me and see a certain swagger, which in Texas is called
"walking."
George W. Bush

Picture of the Day http://apod.nasa.gov/apod/

[Nick Keighley]

On 18 Nov, 05:55, George <[e-mail]:

On Fri, 14 Nov 2008 05:01:34 -0800 (PST), Nick Keighley wrote:

An octet is not mentioned in the C Standard but is usually defined to
be exactly 8-bits. Communication protocols often specify things in
octets as it it less potentially ambiguous than the term byte.

Hence a short may be 1, 2 or even more bytes. But it cannot be less
than two octets.

I had to sleep on this a bit to understand.

this is usually because people think a byte has to be 8 bits.
On modern implementations it nearly always is. Thank IBM!
Some DSPs address 32 bit words and cannot access individual
octets.

I use octet when I want to unambiguously specify an 8 bit
quantity.

With Jack's treatment of
faxes, if char_bits were 9, you would say "nontet"

well I don't find that a useful term. I'd probably still
say octet and live with the fact that a char was slightly bigger
than an octet.

where you read octet,
and (I think), you would still be guaranteed to have two of them in an
unsigned short.

two or more

sextet--impossible in C

again I don't find that a useful term

63-tet--possible

63-bit bytes (chars) are possible.

32-bit bytes (chars) actually exist (on DSPs)

--
Nick Keighley
In a sense, there is no such thing as a random number;
for example, is 2 a random number?
(D.E.Knuth)