[comp.sys.ibm.pc] Laserjet font downloading problem

mikey@shuksan.UUCP (Mike Fields) (11/16/89)

I am having a problem talking to a laserjet on the parallel port.   I
know the system is ok since word5 etc etc are able to download fonts
to the beast.  I think I am being "helped" by DOS.  The configuration
is a AST 286 with the LJII hooked to LPT1.  I have a simple program which
fopens an output file in the mode write|binary.  I send the escape
sequence to tell the LJ to expect a font, copy a font file to the output,
send another escape sequence telling the LJ that is the primary font and
then sending a test string to the printer.  See the sample program 
following (no nasty comments about efficiency- please!).  The strange
behaviour is that if the output file I open is a valid file ie: junk.dat,
all works well (the data looks good in  the file) and if I copy the
file to the printer in the binary mode ie "COPY /b junk.dat prn", the
test message comes out in the new font.  If I open the file "PRN" to
talk to the printer direct, I get a line of garbage at the top of a page
and no text.  No other changes to the program other than the file name!
(I have tried setting the output file to raw mode without fixing the problem).

Is DOS "helping" me to death or am I doing something stupid?? (call me 
stupid only if you have a fix!).  The behaviour is almost identical under
both Turbo C 2.0 and MS Quick C 1.0

Sample program:

main()
   {
   int c,x;
   infile=fopen("namefont.glx","rb");
   outfile=fopen("junk.dat","wb");
   fprintf(outfile,"%c*c100D",0x1b);	/* tell lj font #100 comming */
   while((c=fgetc(infile)) != EOF) fprintf(outfile,"%c",c); /* copy fonts */
   fclose(infile);
   fprintf(outfile,"%c(100X",0x1b));    /* make this primary font */
   fprintf(outfile,"This is a test of the new font\f");
   fclose(outfile);
   }

nothing fancy but it should work (I think).  The only thing i change is the
name of the file opened for the outfile.  What is the difference between
my opening the file in binary mode and doing the copy /b ????

any and all input will be accepted.  (I am going to try doing this with
the biosprint() call BUT I want to know what (if anything) I am doing 
wrong trying to talk to the stream!!

thanks 

Mikey (yes "he likes it!")
=======================================================   Mike Fields
uw-beaver!ssc-vax!shuksan!mikey  (206) 393-3768 [work]    12022 NE 138th Pl.
                                 (206) 821-3492 [home]    Kirkland, Wa. 98034

-- 
Mikey (yes "he likes it!")
=======================================================   Mike Fields
uw-beaver!ssc-vax!shuksan!mikey  (206) 393-3768 [work]    12022 NE 138th Pl.
                                 (206) 821-3492 [home]    Kirkland, Wa. 98034

harper@rigel.uucp (David Harper) (11/17/89)

In article <1624@shuksan.UUCP> mikey@shuksan.UUCP (Mike Fields) writes:
>I am having a problem talking to a laserjet on the parallel port.   I
>know the system is ok since word5 etc etc are able to download fonts
>to the beast.  I think I am being "helped" by DOS.
>          *rest of problem description deleted*

For what it's worth, you are not alone.  I had the exact same problem
and tried basically everything you have tried so far.  I never did
solve the problem.  I finally ended up with a kludge way around the
problem - I have a PD download program and I invoke this with a system
call from my C program.  Like I say, it's a kludge but it does seem to
work okay.  I still would be interested to find out why the stuff we
have tried did not work.  BTW, my printer is a Panasonic Laser Partner,
but it has a Laserjet II emulation mode and that is what I mostly use.


Dave Harper    -     Convex Computer Corp.            E-mail address:
3000 Waterview Pky.  Richardson, TX 75081             harper@convex.COM
(214) 497-4525 (W)   (214) 727-4206 (H)

press@venice.SEDD.TRW.COM (Barry Press) (11/18/89)

<A bunch of stuff about output to a file works, to PRN does not>

You might want to try setmode.  I know the fopen call should work, but
I also know that I have a font downloader I wrote that, for some reason, I
had to use setmode instead (but it was 4 years ago, and I forgot why it ended
up that way).  I do recall something about similar behavior.  I also recall
that under DOS 2, setmode for a device tends to fail.
-- 
Barry Press                                 Internet: press@venice.sedd.trw.com

bmarsh@cod.NOSC.MIL (William C. Marsh) (11/18/89)

In article <3148@convex.UUCP> harper@convex.COM (David Harper) writes:
>In article <1624@shuksan.UUCP> mikey@shuksan.UUCP (Mike Fields) writes:
>>I am having a problem talking to a laserjet on the parallel port.   I
>>          *rest of problem description deleted*
>
>For what it's worth, you are not alone.  I had the exact same problem
>and tried basically everything you have tried so far.  I never did
>solve the problem.  I finally ended up with a kludge way around the

The problem is the difference between opening a file and a device under
DOS.  (I'm not talking about the open() C call here, but the DOS interrupt).
DOS files are opened in 'RAW' mode, while devices are opened in 'TEXT' mode.
You need to use the function 44h (IOCTL) to change the 'mode' to RAW mode
to output binary data to devices.  (Note:  This also speeds up console
output, since DOS won't look for ^S, ^C, ^P, etc.).

A simple example (in Microsoft 'C'):

#include <dos.h>
#include <fcntl.h>

int fd;
union REGS in, out;
unsigned char old_mode;

fd = open("prn", O_WRONLY | O_BINARY);	/* O_BINARY needed for C library */

in.x.bx = fd;
in.x.ax = 0x4400;		/* read device mode */
intdos(&in, &out);

in.x.ax = 0x4401;		/* set device mode */
old_mode = out.h.dl;		/* save old mode for later */
in.h.dl = out.h.dl | 0x20;	/* turn on RAW bit */
in.h.dh = 0;			/* Important! */
intdos(&in, &out);

/* do your stuff here */

in.x.ax = 0x4401;		/* set mode again */
in.x.bx = fd;
in.h.dl = old_mode;
intdos(&in, &out);		/* reset to old mode */

Hope this helps!

Bill Marsh, Naval Ocean Systems Center, San Diego, CA
{arpa,mil}net: bmarsh@cod.nosc.mil
uucp: {ihnp4,akgua,decvax,dcdwest,ucbvax}!sdcsvax!nosc!bmarsh

"If everything seems to be coming your way, you're probably in the wrong lane."