Re: C and faxes

**Ben Bacarisse** · Nov 13 '08, 04:05 AM

Re: C and faxes

George <george@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\source gcc -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** · Nov 13 '08, 08:05 PM

Re: C and faxes

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

George <george@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\sourc egcc -o t2b text2bin.c
>>
>C:\MinGW\sourc e>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/qq15/george196884/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** · Nov 14 '08, 01:05 PM

Re: C and faxes

On Nov 13, 8:01 pm, George <geo...@example .invalidwrote:

<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** · Nov 18 '08, 06:05 AM

Re: C and faxes

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** · Nov 18 '08, 08:55 AM

Re: C and faxes

On 18 Nov, 05:55, George <geo...@example .invalidwrote:

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)

Re: C and faxes

Re: C and faxes

Comment

Comment

Comment

Comment

Comment