Dec 132017
 
Compresses data going to a HP Datajet. Good filter example with source.
File DJSQUASH.ZIP from The Programmer’s Corner in
Category Printer Utilities
Compresses data going to a HP Datajet. Good filter example with source.
File Name File Size Zip Size Zip Type
C_PART.C 8341 1619 deflated
C_TEST.C 354 222 deflated
C_TEST.PRJ 17 17 stored
DJSQUASH.C 1553 543 deflated
DJSQUASH.COM 3306 2207 deflated
DJSQUASH.DOC 4648 2100 deflated
MAKEFILE 221 96 deflated

Download File DJSQUASH.ZIP Here

Contents of the DJSQUASH.DOC file


DJSquash 1.0
Author: DHStraayer

Usage: C:\DJSquash

DJSquash is a Terminate-and-stay-resident program which
compresses printer data directed to PRN, with the assumption that
PRN is an HP DeskJet, and the program or programs writing to the
DeskJet sometimes send raster data without compressing it. It
has been tested with the DRI GEM (R) DeskJet driver.
Source code is provided so that users can write other useful
filters. This could, for example, "touch up" the data from an
application program that has a driver almost but not quite
appropriate for a particular printer. You know the problem, you
bought an XYZ printer that is supposed to emulate an Epson
mumble-mumble, but when you configure your application for an
Epson mumble-mumble, the application keeps putting out an
whatnot command that your XYZ printer doesn't understand.
You want to write a filter that checks for the whatnot
pattern and substitute an works-ok work-around. Well,
this source code will let you do that.

How it works:

DJSquash installs itself on interrupt 17H, the printer interrupt.
It examines data going to the printer (or print spooler, if one
has been installed). If the data is uncompressed raster data,
DJSquash intercepts it and compresses it with "Compression Mode
2", which is a rather clever hybrid of run-length coding and
straight raster data. This compression mode has considerably
better worst-case behavior than regular run-length coding.
Regular run-length coding has a worst-case behavior of causing
the data to expand 2X. This happens when the data is very
"noisy" and all of the runs are of length 1. Mode 2 consists of
two kinds of data interspersed. The data types are length>, pairs, and ,{uncompressed data}
sets. A single bit in the introducer byte indicates whether the
piece of data is a run or straight data. This leaves seven bits
to give either the run length or the number of uncompressed data
bytes.


Files in archive:

DJSquash.com
The TSR executable
DJSquash.doc
This documentation you are reading
DJSquash.c
The part of the C source code that manages TSR
stuff.
C_Part.c


The Compression algorithm in C code.
C_Test.C:
This corresponds to DJSquash.C, but provides a
non-TSR testing environment so you can use Turbo C
debugger to debug other printer filters.
C_Test.prj
Project file for non-TSR debugging
Makefile.
Makefile to make DJSquash.COM


How to modify it:

The source code is broken into two parts, the TSR management code
and the filter itself. The filter is in C_part.c. C_part
consists of three public names. C_init() is called by the TSR
part to initialize things. It should establish starting values
for globals, and may actually send some initialization code to
the printer. Pchar(c) is in the TSR management (or debugging
driver), and it is used by the filter to actually send one
character to the printer, or spooler. Finally, c_filt(c) is the
filter itself. It is called for each unfiltered character that
your application program wants to send to the printer. Of
course, it is hard to detect patterns of characters in a one-at-
a-time situation. Therefore, c_filt is a "state machine" which
keeps track of what is going on via a "state variable" called
(interestingly enough) "state". For further details, read the
source code.

Known problems:

After running the non-TSR debugging, a C_Part.obj may be left
behind which wasn't compiled in -mT and may not work with
DJSquash.obj. After running non-TSR debugging, be sure to delete
c_part.obj. Then make will cause MAKE to re-compile properly.

DJSquash doesn't handle downloading fonts to DeskJet. Probably
will be OK, but if raster data as a part of the font definitions
going to the printer just happens to contain bytes which are the
DeskJet command we are parsing for (like *r[0|1|NULL]A) it
could get confused. What to do? Well, it could parse for the
commands that download data for font defs, and carefully ignore
the "guts" data. It does this something very much like this when
it parses and ignores raster data that may have already been
compressed. In point of fact, the odds of this bug triggering
are VERY slim, since it takes 32 bits of match to trigger the
minimum 4 byte hit, and the odds are therefor in the parts-per-
billion. And font definitions aren't run-of-the-mill random
data, either. But if you are either a compulsive worrier, or
suspect problems, you've got the source code!


 December 13, 2017  Add comments

Leave a Reply