Prevent PT printers from printing first empty label

[mkildemaa]

On every print command the PT printer with endless pt12 label always first prints out about an inch of empty label before anything else.

I am trying to make this program work with my fully automated printing system but since the buffer size limits on these PT printers are so low I can send only 2-3 images per command / print cycle. More than that then the printer's light starts blinking red and needs manual intervention. With this method there is tons of label tape that goes to waste.

In the official Windows P-Touch program I can send queues of multiple hundreds of labels to printer and it prints them all out at once with only the initial first empty label. I wonder how is it solved there?

It would be extremely helpful (and eco-friendly) if there is somehow a way to prevent printer from feeding the inch of empty tape every time.

I have done my best to optimize the image file generations that are being sent with brother_ql so that I can send as many at once as possible but still can't get over 2-3 files.

[chruetli]

Same issue here!

pklaus#114

[vulpes2]

There are two separate issues we need to address to be able to fix this properly. I'll look into this and see what I can do in the upcoming weeks.

1. Unlike P-Touch, brother-ql cannot cope with any temporary error conditions (buffer full or print head overheating) due to the lack of proper error handling routines (back off, wait until printer is ready again, and resend). The current print job serialization and sending code is in desperate need for some clean-up and refactoring, it's likely I will have to write replacements for them and mark the original as deprecated.
2. I can definitely add an option to not terminate print jobs, but it comes with a caveat: you have to ensure absolutely nothing else is talking to the printer. brother_ql is not a daemon, so it doesn't know about the printer's current state, which is why every print job starts with those null bytes and an init command to get the printer back to a known initial state. When the printer is in the middle of processing a print job, I don't think it will respond to status queries, so you have to assume it's still able to do it and send more pages blindly.

On a side note, the blank piece of tape is fundamentally a firmware design issue on Brother's side. A new print job means a new blank piece, and there is no way to disable this behavior. Not sure what their intention is, it could be a malicious design to waste the arguably pretty expensive consumables, or it could be a poorly implemented workaround to ensure the printed label always come out perfect no matter what. Personally I think it's more of the latter, since Brother never bothered to implement DRM in their label printer consumables. The lack of DRM is the main reason I prefer Brother label printers over Dymo, despite the fact that their XML label formats are easier to work with compared to this binary raster stuff.

[vulpes2]

I'm able to produce a workaround but it's pretty fiddly to use. Expect a pull request soon, feedback would be welcome because at this point it's quite confusing for people who don't understand how these printers work under the hood.

[karlmuuga]

Would be my pleasure to check out the PR. Good job!! 👏

[mkdsolutions-admin]

I'm able to produce a workaround but it's pretty fiddly to use. Expect a pull request soon, feedback would be welcome because at this point it's quite confusing for people who don't understand how these printers work under the hood.

That functionality would save us so much headache! Fingers crossed!

[vulpes2]

Been busy for the past month so this fell off the radar, will be able to finish this up before the end of the month. Need to verify this against P-Touch's behavior by comparing the USB traffic before I can post it.

[vulpes2]

Decided to implement a basic print queue to solve the root problem first. This will not get rid of the first blank piece, but it will allow you to print as many labels as you want, without ever running into buffer overflow issues. More advanced functions like resuming the print queue after errors occured are difficult to implement within the constraints of this codebase, let's just stick with the basics for now. The code is mostly done, just need to tidy some stuff up and it should be ready soon.

[vulpes2]

Give #74 a shot, everything should be working properly now. This does not get rid of the initial blank piece, but it does let you queue unlimited amount of labels for batch printing.

[mkildemaa]

Bravo! The initial blank piece is not that much of a problem indeed if a near unlimited queue is supported. I hope to find a time window in the next week to check it out!

[vulpes2]

Let's leave this open since #74 only gets us up to the same level as P-Touch. Note that error handling and resumption support are present but not implemented in the CLI, a minimal sample snippet has been provided to demonstrate how to queue additional images and resume a queue.