Guy,
> On Jun 3, 2026, at 11:04 AM, Tucker, Guy <Guy.Tucker at lrs.com> wrote:
>> Michael and all,
> I am not sure exactly when my membership in PWG lapses, but it may have done so already.
No worries, the PWG is an open standards body - you only need to be a member to vote, not to participate...
> That being said, I read with interest the specifications for thermal / Label devices. There is one attribute that I suggest you consider.
> Labels come out of high-speed label printers in a direction that, when many labels are printed as a stream, appear to the operator to be printed backwards. Vendors provide a way to simply flip the labels 180 degrees and this “fixes” the perception problem. In ZPL, that is ^POI. DPL and IPL have similar bits, but if these mime-types are not in play, perhaps an attribute at the IPP level might be considered.
IPP has the "orientation-requested" attribute that serves this purpose. I can add a note in the implementation guidance section that explains this kind of mapping to vendor PDLs.
> Another common situation we see is “job interweaving”. Zebra devices are multi threaded, and can accept two or more jobs simultaneously. The problem is that there is no concept of a job. If I have two ZPL data streams coming at the same time, labels from one stream may print between labels of the second stream. ZPL has no concept of a job, so anything between the initial ^XA and ^XZ which constitutes a single label is the only thing that is considered. I am not sure that this is fodder for a specification, but it is a problem in many high-speed environment where labels are generated from multiple sources.
IPP enforces a job model, regardless of PDL. Zebra printers are actually pretty unique in that they allow multiple simultaneous print connections (most printers only accept a single port 9100/LPR connection at a time), but I can certainly add a note about this for print servers providing an IPP front-end to these "legacy" devices - basically only one system/service should be talking to a printer to avoid this situation. IPP/1.1 (STD92) also talks a bit about interactions with non-IPP protocols being "implementation-defined" with potential side-effects...
________________________
Michael Sweet