Brother PT/QL questions and improvements - #217

The PT-series path emits raw (uncompressed) 'G' raster lines but never
sends the 'M' select-compression-mode command, leaving the printer in
whatever mode it was already in.
On a Brother PT-E720BT, ESC @ does NOT reset this to uncompressed: the
printer sits in TIFF/PackBits mode, so the raw lines are fed to a
PackBits decoder. A raster line is mostly 0x00, and a leading 0x00 in
PackBits means "copy the next 1 byte literally", so 16 raw bytes decode
to almost nothing and the printer zero-fills the rest of the line.
The result is a label of the correct length, cut in the correct place,
with a clean status packet -- and completely blank. Sending "M 0x00"
before the raster data fixes it; verified on a PT-E720BT (24mm TZe).
When the PackBits TODO in lprint_brother_rwriteline() is implemented,
the last byte should become 0x02 (TIFF).
This fixes michaelrsweet#214.

This was done in the if for PT only and then again after the if for both
printer types.

PAPPL 1.x uses the int type for num_media, PAPPL 2.x uses the size_t
type, so this code produced a warning with PAPPL 2.x. Cast to the
biggest of the two types and adapt the format string accordingly.

After sending the request, the first couple of reads return no result
yet, so do a couple of repeated reads to get the result.
If no reply is received, log a failure but do not abort. Reading a
partial reply is diagnosed separately (it probably never occurs, but if
it does we can now find out and investigate).
This also improves the printing of the status reply.
Tested on PT-E550W.

In lprint_brother_rstartjob(), give up when we don't have a driver name. (Not
sure if this can even happen.)

According to the manuals, different Brother printer models require a different
amount of zeroes in their initialization sequences; instead of always sending
the maximum, we try to be somewhat smart here.

According to various Raster Command Reference manuals, printers should be
initialized before requesting status information.

It should be obvious enough how to add a new printer even without this comment.

Encode the printer base resolution in the driver name.

We could encode printer specific information like the resolution in the driver
name. However, the driver name is specified in .config/lprint.state, so
whenever the driver name changes, the existing configurations will break. In
addition, parsing parameters out of the driver name will soon become unwieldy.
So instead, put driver specific parameters into pappl_pr_driver_s::extension.
Right now, only the resolution is stored in pappl_pr_driver_s::extension, but
it would make sense to move other parameters like the printer family (PT vs.
QL), support for high-resolution printing and automatic label cutting, etc.
there as well.

The PT (P-touch) series printers only support laminated and non-laminated tape,
as well as two kinds of head-shrink tube. All these tapes are continuous.

XXX With this patch, PT-E560BT printers are recognized, but I haven't tested
how well the driver actually works so far.

The PT-P900 and PT-P950NW models should work exactly as the PT-P900W model,
even though I cannot test them.
The PT-P910BT printer is described in the same Raster Command Reference manual
as the other three models, but it doesn't support high-resolution printing and
differs in a few other minor ways, so I'm leaving it out for now.
XXX With this patch, PT-P900W printers are recognized, but I haven't tested
how well the driver actually works so far.

It is unclear to me what the output gamma correction value should be set to for
different resolutions, especially for non-uniform resolutions like 180x360 dpi
and 360x720 dpi.