Incorrect output & printer lock-up - PT-2430PC

[vintagepc]

Describe the bug

I've encountered two issues attempting to use this driver:

1. If I have disabled 'Auto-cut' in the options, the printer will not print at all. It completely locks up and becomes unresponsive, although CUPS reports the job has completed and the data was sent to the printer. I have to pull the battery - it will not respond to the power button or cut button anymore.

2. Secondarily, if I have enabled auto-cut, then the results are very oddly spaced/scaled.

I created a simple 12x40mm page in Inkscape for printing on 12mm tape.

I have tried the following things in an attempt to resolve this: In Inkscape:

• Lay out document vertically
  • Using 'Vector' for rendering
  • Using 'Bitpmap' with a resolution of 180dpi as rendering in the print tab
• Lay out document horizontally.
  • Using 'Vector' for rendering
  • Using 'Bitpmap' with a resolution of 180dpi as rendering in the print tab
• Pre-render to a png at 180DPI, and print it via GwenView
  • Portrait orientation
  • Landscape orientation

These are the results I got, as well as a successful print which was done using the blabel program to confirm the printer is in working order:

Expected behavior A label that looks like the PNG, as well as the auto-cut functionality to not lock up the printer if it is disabled.

Screenshots If applicable, add screenshots to help explain your problem.

Operating system and platform (please complete the following information):

• Operating system and distribution OpenSuSE x64
• OS version 15.4
• printer-driver-ptouch version Built from GitHub, v1.7
• What software are you using to create and send the print job? Inkscape, GwenView
• If you are using a QL series (paper label) printer with continuous (not pre-cut or die-cut) labels: Have you set up a custom page size for the label size you want? N/A - PT

If you are reporting a print issue (See above, let me know if you need more/additional resources)

Additional context

• I built the from source .zip. I had to manually remove the QL-600 model from the makefile, because it threw compile errors. (./configure && make)
• I then did make install which copied the files.
• I ran foomatic-compiledb to generate PPDs
• I added a printer in the CUPS GUI and manually selected the generated 2430PC ppd from the previous step.
• This resulted in rastertopt: not found which was fixed by copying this file to /usr/lib/cups/filter (bad configure option on my part, my system does not use /usr/local)

No errors were reported by CUPS at any point after the incorrectly located filter was resolved.

Appreciate any help or advice you can offer.

[vintagepc]

Good news - some of my issues were due to a partial PPD generation/import - turns out for some reason it was set to Letter in the CUPS interface with none of the tape sizes available. Re-building and re-importing the PPD fixed that and it at least prints legibly, though with some sort of interpolation I've not yet managed to get rid of - the quality of the upper 3 vs the results generated by ptouch-print both via --text "MEAS" or supplying it the same PNG, In all cases I'm printing a PNG that has already been downsampled to 1bpp in GIMP

Additionally, does still lock up hard when both AutoCut and AutoEject are set to continuous/chainprinting.

[philpem]

I've just merged #35 which should fix the QL-600 build issue.

The stairstepping distortion around the text is a CUPS / GS issue, sadly, and there's not much that can be done about it. I think I mentioned it on another issue.

You mention that the Autocut / Autoeject features work as expected in Windows; can you set the driver to "print to file" and upload the print files? And if possible do the same for the non-working ones from CUPS?

There's a tool called "ptexplain" in the repository which analyses P-Touch dump files and should be able to tell what the Windows driver is doing differently which is making this work. Sadly we might have to iterate around and test a few things as I don't have a PT-2430PC to test with.

[vintagepc]

Thanks for the reply :)

I do recall reading an issue regarding the poor rasterizing of greyscale images as a result of the CUPS stack, apologies if I missed you already explaining this particular aspect somewhere.

I'd done some exploration involving the command line already whereby I was manually setting up a series of pipes - namely a cups call for converting a PNG to CUPS raster, piped into rastertopt, and then into ptexplain -w writing back to a PNG - and this output came back looking like the original image. I'm guessing ghostscript may not have been involved in that chain, but now that you mention it it tickles a memory about seeing something similar with a dymo printer via CUPS as well - though I can no longer remember the circumstances or exactly what I did to cause it as it was years ago. I think I played with the half-toning settings for that driver (it has "error difusion" and "nonlinear dithering" as choices with one of those two producing a similar result - For information purposes I may run a test again when time permits)

I haven't actually tried the printer on Windows, the other prints I did were using the linux "blabel" program and "ptouch-print" tool which bypass CUPS and do user-land (lib)USB directly to the printer. I've forgotten which combinations of settings I used with those but at one point I did get a label it did not fully advance before cutting as well as one that did not auto-cut.

As one fellow FOSS dev to another I'm more than happy to lend my time and printer for debugging/investigative purposes to get you the info you need - I'll confirm the behaviour on Windows and get back to you with some dumps and whatever else interesting I find, hopefully tomorrow.

I've meddled in printer driver code a bit before to fix up a Pixma inkjet driver so I know how, well... "fun" that can be ;)

[vintagepc]

Further update after some experimentation: The wavy edges are indeed attributable to how CUPS handles the bitmap stack. Printing as e.g. vector from Inkscape doesn't suffer from this, whereas bitmap does.

The Dymo I mentioned produces the same effect when printing a bitmap with its halftoning set to "Nonlinear Dithering" or "Default". "Error diffusion" produces a better result on vertical lines and a more consistent pattern on horizontal ones. Picture below.

"ME" printed using "default", BE is "Error diffusion' and "BN" is Nonlinear dithering"

Here are the relevant snippets from the Dymo PPD:

*OpenUI *DymoHalftoning/Halftoning: PickOne
*OrderDependency: 20 AnySetup *DymoHalftoning
*DefaultDymoHalftoning: ErrorDiffusion
*DymoHalftoning Default/Default: "<</cupsColorOrder 0/cupsColorSpace 3/cupsBitsPerColor 1/cupsBitsPerPixel 1>>setpagedevice"
*DymoHalftoning ErrorDiffusion/Error Diffusion: "<</cupsColorOrder 0/cupsColorSpace 1/cupsBitsPerColor 8>>setpagedevice"
*DymoHalftoning NLL/Nonlinear Dithering: "<</cupsColorOrder 0/cupsColorSpace 1/cupsBitsPerColor 8>>setpagedevice"
*CloseUI *DymoHalftoning

I looked into Dymo's sources for their linux filter and the halftoning code they've added is GPL-v2 so it could potentially be adapted and integrated here too... :thinking:

The "Lite" software on the printer does indeed work with auto-cut disabled, but it does not have the option to print to file, and I'm currently having issues getting the driver to install into a VM, so that will require some work/digging from me this weekend.

I'll keep you posted.

[philpem]

If the Dymo stuff is licence compatible, I'd be up for including it. Looking at the PPD

If you can feed the output of blabel and ptouch-print into a file, then ptexplain should be able to process them and tell you what's being sent. It doesn't necessarily have to be the Windows driver (though I

Thanks for the kind offer to lend me the printer but I've been suffering a lack of time and energy which means I probably wouldn't be able to dedicate much time to it. If I can find the time and energy I can probably run the driver myself and compare the output, but I wouldn't expect too many differences. This is probably some silly error which needs a PPD and driver fudge to work around printer firmware, or yet another edge case.

As I'm sure you'll appreciate from your Pixma work, this is sometimes a bit of a minefield. I have a Canon Pixma, so on the off chance I'm using your driver, thank you for your hard work! I once looked at the GIMP-Print code for that and it nearly drove me to drink...

[vintagepc]

No worries. I have projects of my own which are also very time-consuming so I completely understand and I want to be clear here- I don't have any expectations going in to this discussion that things will necessarily get fixed or that I'm demanding anything, and I already appreciate just the discourse to help me understand how it all works more quickly than if I'd started poking at it cold. If time permits I will gladly do the legwork myself and submit a PR for consideration.

I also apologize if my replies are verbose, I tend to use issues like this as a running log of findings to help spread knowledge rather than just "here's the fix"

Looks like some of your sentences in the reply got cut off.

I'll keep poking at things over the weekend to understand what's going on and read into the Dymo driver a bit more. I can't say I'm overly familiar with the Foomatic middleware here and what it brings to the table, the Dymo just uses CUPS' internal raster generator instead of GhostScript and pipes it directly into raster2lm, but offhand it looks like the Dymo software is telling CUPS to send it a greyscale image at a few BPP for use in its own halftoning implementation rather than the problematic pure black and white bitmap.

I'll see if it's not too time consuming for me to understand the Foomatic stuff and if not I'll share the Dymo code here for you to have a look.

Unfortunately I never got around to publishing my pixma hackery, it was rather poor quality work in the interest of just "getting it working" and mostly centered around a) fixing the cnij_usb handling because CUPS doesn't like undescores in the protocol name, and b) hacking up the UI application that would draw the ink levels based on the breaking CUPS/gtk api changes sometime after it was released. This was for the IP4200 printer which is probably close to 18 years old now so there's probably very few of them still in operation to dig it up and make it publishable, assuming Canon's licensing of their binaries even allows that 🤣 I still have the printer and a couple spare heads for it because it's a great machine, but it's definitely been a while since I had to print anything.

[vintagepc]

I've found the lockup problem after analyzing some ptexplain output from blabel's jobs.

There are three conditions that must be met to cause the lockup:

• It must be the first label being printed (i.e. not in chain mode - this makes sense as auto-cut tickbox only affects trimming the leading edge of the label)
• You must have auto-cut disabled
• You must have an extra margin value set to 0 or 1mm.

I suspect we are running afoul of some minimum requirement when in auto-cut mode. blabel always sets the margin to 20 lines and therefore does not run afoul of this:

  # Specify automatic margins
  # 1st parameter = pixels
  # 2nd parameters = pixels * 256
  $output=$output.chr(0x1B).'id'.chr(0x14).chr(0x00);

Unfortunately, this is a stateful problem with respect to a non-stateful driver so I don't think there is a resolution for it that can be done easily in the code unless you are able to query the printer and determine whether it is in the middle of a chain job or not - in which case it might be possible to adjust the margin appropriately.

It seems to not be affected by the label's real length (in other words, making the label more than 2mm longer does not prevent it locking up).

I intend to have a crack at the halftoning implementation this weekend. Alas it is written in C++ and so not as straightforward an integration with this C code as one might like, but it doesn't seem too onerous. It does provide a generic half-toning interface which is rather nice as it would allow anyone else to easily contribute additional conversion algorithms which may perform better in specific situations.

[vintagepc]

I managed to put together a proof-of-concept job with promising results. the Error diffusion processor works line-by-line and therefore is relatively straightforward to insert. The NLL option requires the entire image at once, and therefore requires some additional thought and handling to implement. I am not sure of its value since at least on text error diffusion seems to produce superior results anyway.

I will probably require some assistance on the argument passing front as I'm not familiar enough with the Foomatic/XML syntax to understand how to get new options passed through - both the CUPS colour space must be altered in addition to the new parameter supplied to rastertoptch

Default half-toning method:

Error diffusion:

though what's interesting is that on the command line, CUPS' default rasterizer really isn't that bad. For example, with this greyscale input image:

 /usr/sbin/cupsfilter  -o "PageSize=tz-9" -m application/vnd.cups-raster -p Brother-PT-2430PC-ptouch-pt-hack.ppd text.png | ./a.out 'PT  PixelXfer=RLE  Align=Center  Margin=0 Halftone=-1' | ./ptexplain -w text

produces (cropped):

and the error diffusion (Halftone=0) actually makes it worse:

which leads me to believe at least a significant portion of the issue may lie in the re-conversion of already-raster data back into postscript as required by foomatic-rip

[vintagepc]

I've filed a PR with the portion of the work I was able to figure out today. It is not complete yet but this is because there are some aspects I am not familiar with and I'm not sure I'll have more time this weekend.

[philpem]

Thanks for your work on this - it looks good :)

Please let me know when it's ready for review and I'll take a look.

[vintagepc]

I've marked the draft PR as ready for review, I did not end up making additional changes as I wasn't able to wrap my head around the XML side to get it generating right.