cupstestppd syntax failure

[Stoatwblr]

ref #5379 - ppdc JCLui error

cupstestppd passed the broken asymetric closure syntax emitted by ppdc, so this needs fixing as well.

NB: There may be other asymetric closures/ends being passed too.

The issue isn't just ppdi/ppdc - but trying to make vendor-supplied PPDs work

Some manufacturer PPDs (most notably Kyocera) are full of obvious errors when eyeballed/compared with the Adobe spec, but are passed by cuptestppd - and then failed by cupsaddsmb - which is what started me on this wild goose chase in the first place.

Despite ppds being deprecated, this is one particular problem which will stay around for a long time:

Most makers are not stepping into line with ppd-everywhere yet - and those who have, seem to have borked it in a number of ways anyway (Canon, Ricoh, Kyocera) whilst others appear to have abandoned IPP/IPPS (HP) along the way.

Also, given that higher end or special-purpose printers frequently have service lives in excess of 15 years, older PPD-based systems will probably be with us for an extended period. Abandoning a very large in-use fleet is tantamount to encouraging code forking.

[michaelrsweet]

I will look to see if we can add this check without breaking things too much. But understand that this is a very low priority issue for us - CUPS 2.3.x is the end of the line for printer drivers and PPD files. We will probably have some limited support for printing to generic PCL/PS laser printers but I don't see us using PPD files as they require a LOT of hacks and compromises (as you have personally seen). I spent the first 10 years of CUPS development trying to get vendors to make better PPD files...

cupsaddsmb has been deprecated for a long time now. Samba support for the old Windows 2000-style drivers (not to mention support from Microsoft) has likewise been on life support since Microsoft started pushing for XPS-based print drivers (XPS being Microsoft's answer to PDF). You should expect that Windows client driver support will disappear completely after CUPS 2.3.x, and that the current solution will break for random reasons (driver code signing on Windows, PPD/PostScript issues, etc.)

Basically all HP printers sold in the last 10 years (except for a few sign/fabric printers) support IPP and AirPrint, and many (currently 272 models over the last 4 years) support IPP Everywhere. I don't know what HP printers you are referring to, but the current chair of the Printer Working Group (that is responsible for IPP) is an HP employee. Likewise, Canon, Ricoh, and Kyocera are members of the PWG and all sell mostly IPP/AirPrint printers with IPP Everywhere support being a formality of running the self-certification tools and posting the results...

As of 2014 (the last time I did a full sweep of printers being sold), more than 98% of all printers sold supported IPP and AirPrint (that's including USB-only printers, which use IPP over USB). About half supported PDF. That doesn't sound like companies are not "stepping into line", that sounds like they are all working very hard to support IPP so that their products can be used from any client device. (more clients == more printing == more sales).

[michaelrsweet]

[master bac967ae5] Add checks for missing/bad CloseUI/JCLCloseUI keywords (Issue #5381)

[branch-2.2 7882a850a] Add checks for missing/bad CloseUI/JCLCloseUI keywords (Issue #5381)

[Stoatwblr]

I wish your claim about HP printers was true. The sad fact is that it isn't - and in fact in some of their recent printers they've deleted IPP entirely. (EG CP5225 A3 color laser and Z5200 designjet)

On top of that they've never fixed their problem of "interpreter breaks if PJL headers exceed 1024 characters" despite being informed about it in 2003 (I have the email exchange buried somewhere) nor have they fixed the "interpreter breaks on certain PS L3 commands" (at least this can be mitigated by forcing it back to PS L2

If anything, the problems with network printing appear to be getting worse, not better. A lot of stuff is clearly only ever tested in a single segment LAN and routed network testing is something that never crosses the tester's minds - Even for supposedly enterprise level printers. Several makers are STILL shipping enterprise/workgroup printers that don't support IPP authentication - including members of the PWG you mentioned above. Self-certification only works when the self-certifiers are honest.

As for XPS/PDF - I can understand Microsoft's motivation on this. As with AVI, PDF is a standardised container format, but what's inside the container can be (and frequently IS) as mad as a box of frogs.

[michaelrsweet]

The CP5225 and Z5200 are NOT new printers - they were both first sold in 2010!

The CP5225 is the ONLY A3 printer that HP still sells (in North America at least) that doesn't have IPP and AirPrint support.

The (newest) T520 and T930 DesignJet's both support IPP and AirPrint. I don't even see the Z5200 for sale on hp.com...

Finally, in defense of printer manufacturers networking is hard and most enterprise environments push the limits of what is possible/allowed. IPv6 has only made things worse as the default link-local address cannot be used on enterprise networks (although many users still try to do so...)

[Stoatwblr]

2010 is within "the last ten years" - and the CP5225 in question was only installed last year. The Z5200 went in 3 years ago - and was specifically pushed by the vendor over the T-series units.

The Ironic thing is that the Z5200 had IPP support when purchased and it went away on a firmware update - most likely because HP jetdirect interfaces with IPP (and not ipps) can be quite effectively DoSed with a couple of ipps requests sent to port 443.

Networking isn't particularly difficult, nor is IPv6.

Link-local is another single-segment LAN thing which should never exist on a properly maintained network (I can remember when that /16 was in IANA records as a Microsoft test laboratory network back in Win3.11/early Win95 days)

The primary requirement for enterprise networks is the ability to turn all the extraneous single-segment-related and multicast stuff OFF - but quite a few makers have made this impossible. As such they end up on our organisation's "Do not buy" list, but users insist on dodging channels and picking up junk printers anyway (the kind of users who we can't just refuse to connect or put the printer in the bin).

Perhaps you might like to ask Kyocera when they'll implement IPP authentication (as in user+password) on their $10k+ Taskalfas 7551 units? Isn't that one of the items on the "self-certification" list? How about asking Canon when they'll allow IPP auth to include user LDAP lookups (or at least multiple users) instead of being locked to a single user+password?

You get the idea. The "Networking is hard" mantra is usually spouted by those who've made things hard for themselves with broken implementations or trying to force their broken interpretation of standards onto everyone else instead of doing things correctly (which is why MS have made such an unholy mess of email and why SNMP is a nightmare, but those are other rants).

ipp-everywhere and airprint are good ideas, but never underestimate the ability of someone to (knowingly or unknowingly) undermine the intent(*) - and the willingness of self-certifiers to flat-out lie about their implementations unless they're carefully audited. ("Oh, wer'e not lieing, we'll just skip over that bit")

(*) I've seen stories of company coders screaming radfaced that their interpretations of various RFCs are the One True Meaning - in the faces of RFC authors saying "I wrote that and that's not what this clause means". The print world has it mild by comparison.