C and faxes

I have projects that I keep as hobbies with C, and election time being upon
us, I wanted to have enough that I wouldn't run out anytime soon.

So it is that I re-read parts of chp 18 of unleashed having to do with
faxes.

There's 2 parts that I don't think get covered in the treatment that a
person would need in order to see some output. The first is how to create
a fax file in the absence of a scanner. The second is how to send raw
binary data to the printer.

I think I can solve the first with a little elbow grease, but I have no
idea how to do the second. All I know is that it's a lexmark 1300 on winxp
32, which is a popular printer on a popular OS.

Grateful for any hints,
--
George

We can't allow the world's worst leaders to blackmail, threaten, hold
freedom-loving nations hostage with the world's worst weapons.
George W. Bush

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

George

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

> On Sat, 1 Nov 2008 20:37:24 -0700, George <>
> wrote in comp.lang.c:


[slightly re-ordered]

>> 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

I'm only half done with it. That you credit only jaysome with correcting
your Hamming code is your choice. No single entity *can* in a lot of ways.
In some sense, every value is triangulated by concurrent errors.

>
> 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!"
>
> The next one you want to look at is:
>
> "lj300.c 3,213 This program will generate files for an HP
> LaserJet or compatible printer to output the images from encode.c,
> decode.c, and test2bin.c (see Chap18.txt for more information)"


I've got these both on disc and a couple tricks up my sleeve here.

>
> In fact, I used these two programs extensively in testing the T4
> encoding and decoding programs. I generated image files with
> text2bin, and used lj300 to generate files I could send to the
> printer. Then I encoded and decoded them, and printed them to make
> sure I got back the same thing I put in.
>
> If your printer has PCL emulation, and many do, you should be able to
> use lj300. If not, you should be able to get information on your
> printer and use lj300.c as a starting point for a program to generate
> binary files suitable for your printer.
>
> As for sending the PCL 300 DPI image to the printer, I was running
> Win98 SE in those days, and my Laser Jet 4 was attached to a parallel
> printer port. The command line:
>
> "copy /b filename.ext lpt1"
>
> ...worked just fine.
>
> Of course, the Laser Jet and the computer that used to run Windows 98
> have long ago been recycled.
>

Thanks, Jack. Right off the bat that dos command needs updating with my
setup. Keith has posted an ng before that could address it: comp.os -
ms-dos.progammer.something ?

> Good luck with your project.

What I'm struggling with now is my C setup. I've taken steps to enter
gcc's mailing list, but I want a c compiler when I stumble home from the
pub tonight.

I get gcc to execute, but gcc can't find the headers when these are my
compiler complaints and configuration:

C:\Program Files\gfortran\source>gcc -o out text2bin.c
text2bin.c:33:19: error: stdio.h: No such file or directory
text2bin.c:34:20: error: stdlib.h: No such file or directory
text2bin.c:35:20: error: string.h: No such file or directory
text2bin.c: In function 'main':
text2bin.c:4957: error: 'FILE' undeclared (first use in this function)
text2bin.c:4957: error: (Each undeclared identifier is reported only once
text2bin.c:4957: error: for each function it appears in.)
text2bin.c:4957: error: 'input' undeclared (first use in this function)
text2bin.c:4958: error: 'output' undeclared (first use in this function)
text2bin.c:4983: error: 'stderr' undeclared (first use in this function)
text2bin.c:4984: error: 'EXIT_FAILURE' undeclared (first use in this
function)
text2bin.c:4986: error: 'NULL' undeclared (first use in this function)
text2bin.c:4988: warning: incompatible implicit declaration of built-in
function
'fprintf'
text2bin.c:4993: warning: incompatible implicit declaration of built-in
function
'fprintf'
text2bin.c:4999: warning: incompatible implicit declaration of built-in
function
'fprintf'
text2bin.c:5012: warning: incompatible implicit declaration of built-in
function
'memset'
text2bin.c:5026: warning: incompatible implicit declaration of built-in
function
'strchr'
text2bin.c:5039: warning: incompatible implicit declaration of built-in
function
'fwrite'
text2bin.c:5051: warning: incompatible implicit declaration of built-in
function
'printf'
text2bin.c:5052: error: 'EXIT_SUCCESS' undeclared (first use in this
function)

C:\Program Files\gfortran\source>cd ..

C:\Program Files\gfortran>dir
Volume in drive C has no label.
Volume Serial Number is 942A-AD55

Directory of C:\Program Files\gfortran

11/03/2008 01:09 PM <DIR> .
11/03/2008 01:09 PM <DIR> ..
11/03/2008 01:08 PM <DIR> bin
11/03/2008 01:08 PM <DIR> doc
06/03/2008 04:11 PM 35,819 GPL.txt
11/03/2008 01:08 PM <DIR> include
11/03/2008 01:08 PM <DIR> lib
11/03/2008 01:08 PM <DIR> libexec
11/05/2007 04:37 PM 1,315 perl3.lnk
06/03/2008 04:11 PM 4,845 README.html
11/03/2008 01:12 PM <DIR> source
11/03/2008 01:08 PM 34,851 uninstaller.exe
4 File(s) 76,830 bytes
8 Dir(s) 75,307,155,456 bytes free

C:\Program Files\gfortran>

Good grief. How can dos find gcc and gcc not find stdio.h?
--
George

Freedom itself was attacked this morning by a faceless coward, and freedom
will be defended.
George W. Bush

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

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\source> gcc -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/

George

George <> writes:
<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.

Ben Bacarisse

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

> George <> writes:
> <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.


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 (-12
#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/

George

On Nov 13, 8:01*pm, George <geo...@example.invalid> wrote:

<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 * * * (-12
> #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

Nick Keighley

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/

George

On 18 Nov, 05:55, George <geo...@example.invalid> wrote:
> 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)

Nick Keighley