[Printing-architecture] Automatic printer setup with Printer Applications

Till Kamppeter till.kamppeter at gmail.com
Wed Feb 24 17:23:51 UTC 2021


On 24/02/2021 15:01, Johannes Meixner wrote:
> I had experienced in the past some overenthusiastic
> "let's simply just collect printer IEEE1284 IDs" or
> "let's simply just collect printer USB VID/PIDs"
> attempts by overenthusiastic wishful-thinkers
> that appeared every now and then but never ever it
> resulted really useful data - only duplicates for
> well know printer devices like some HP LaserJets
> but basically nothing for all those zillions of
> printer devices that manufacturers continuously spill out
> and unexperienced end-users "just buy" in the next shop.
> 
> I took me some longer time of experience what works
> reasonably well in practice out there in real world
> how to auto-match based on the manufacturer & model
> strings which is the only data that is always there.
> 
> So a 90% working auto-match based on the manufacturer & model
> works in 90% of the cases in practice out there in real world
> while a 100% working auto-match based on IEEE1284 IDs or
> USB VID/PIDs works only in less than about 20% of the
> cases in practice out there in real world.
> 
> My auto-match based on the manufacturer & model strings
> is in SUSE's YaST2 printer module in somewhat human readable
> form only in my old YCP code (the new autogenerated Ruby code
> is no longer actually human readable - at least not for me).
> 
> I could try to dig that out but I fear what comes out is a pile
> of hacks that I just somehow put together to make that stuff
> work reasonably well in practice out there in real world.
> 

I go a similar way, matching by make and model, as we do not have device 
IDs and VID/PID for all printers (and there is a bunch of older Epsons 
all having the same VID/PID despite being different models).

What I do is taking the observed make and model, normalizing it to some 
form how a human would read it: all lowercase, any amount of 
non-alphanumeric characters replaced by a single separator character, a 
separator character between words, where a word boundary is any group of 
non-alphanumeric characters, a transition between letter and digit or 
digit and letter, and '+' is replaced by the word "plus", as model names 
often differ by an added '+'. The separator usually is space or '-', 
ending up that the resulting string only contains letters, digits, and 
the separator character. We also add mssing manufacturer names by known 
model names, remove different representations of the same manufacturer, ...

Examples:

HP LaserJet 4500 -> hp--lasejet-4500
Hewlett Packard laserjet 2+ -> hp--laserjet-2-plus
ecosys 1800s -> kyocera--ecosys-1800-s

The names in the list of supported models I normalize the same way.

So if we do not have the exact writing of a make/model name as of a 
device ID but a less exact writing of a third-party driver developer for 
example, the normalized strings will most probably match, but false 
matches are not very probable, as manufacturers would not market two 
different models whose names sound the same, for example names only 
differing by upper/lowercase or by non-alphanumeric characters.

The code for this, as I use it in the PostScript Printer Application 
(https://github.com/OpenPrinting/ps-printer-app) is in the 
libcupsfilters library:

https://github.com/OpenPrinting/cups-filters/blob/26770bc5690e950767e3dffc70b5231937e0a2ca/cupsfilters/ieee1284.c#L618

It has also functionality to normalize for sorted lists, replacing each 
group of digits by a number zero-padded to 6 digits.

My algorithm work for prioritizing drivers is in scp-dbus-service, of 
system-config-printer:

https://github.com/OpenPrinting/system-config-printer/blob/master/scp-dbus-service.py

    Till


More information about the Printing-architecture mailing list