PyTouch-Cube should support Linux rfcomm ports

[wildy]

Hi.

I had to modify the code slightly for your GUI to support /dev/rfcomm*. Leaving this here as a reminder that device nodes are dynamic, and not necessarily conform to /dev/tty.PT-*.

[piksel]

No, I know. The current code was basically just a hack to get it working on macOS. The port selection has been totally rewritten, but I havent pushed it yet.

[wildy]

I'm curious what will be required to make the Cube work with the existing CUPS 'ptouch' driver. I was using a desktop P-Touch with CUPS and blabel at my previous workplace with no issues.

Also we should try to make it use shorter margins (does Cube honor print chaining?) - the current margin length is enough to land a space shuttle on! So print settings support (chain print and/or narrow margins) is a must.

I'll be glad to help with this code too, a lot of people needs something like this.

[piksel]

They might not use the same protocols at all, the P-Touch branding is just a marketing name. But I haven't looked into it.

Do you mean the margin after the print, or the margins above and beneath? I mean to rewrite the serial communications code soon to make it easier to tweak the settings. It's basically using this:
http://etc.nkadesign.com/uploads/Printers/95CRRASE.pdf

[dogtopus]

I'm curious what will be required to make the Cube work with the existing CUPS 'ptouch' driver. I was using a desktop P-Touch with CUPS and blabel at my previous workplace with no issues.

I hacked something together before but can't get it to work as reliably as the labelmaker gist so I gave up. Basically everything sorta worked (including native RFCOMM socket support without the deprecated serial emulator) but it disconnects regularily on larger prints and sometimes a print job would make the printer halt. The protocol is very similar to other PTouch label printers but with some platform-specific differences on printer status stuff (e.g. a lot of fields were reserved).

With CUPS you do get some perks though like a monochrome pixel renderer that doesn't randomly go subpixel nor renders disconnected curves (a big problem on other image processors without hard tweaking).

---

Also checkout pybluez which offers RFCOMM sockets on all big 3 platforms. My fork of labelmaker gist uses it.

---

Also we should try to make it use shorter margins (does Cube honor print chaining?) - the current margin length is enough to land a space shuttle on! So print settings support (chain print and/or narrow margins) is a must.

I'll be glad to help with this code too, a lot of people needs something like this.

Print chaining is indeed supported. Just make sure the last print job doesn't have it enabled or the printed label will stuck inside.

In addition Cube also "supports" auto-cut. In case it was set the finished tape will have 2 dots printed on it to indicate the label boundary. Something useful when doing print chaining.

[piksel]

What benefits does it offer to use "native RFCOMM sockets"? Isn't RFCOMM just serial emulation over bluetooth? Or are you just referring to using the /dev/rfcomm* char devices?

Do you still have any of the CUPS work? I would love to take a look!

[dogtopus]

What benefits does it offer to use "native RFCOMM sockets"? Isn't RFCOMM just serial emulation over bluetooth? Or are you just referring to using the /dev/rfcomm* char devices?

As I said the rfcomm tool that is required to set up the character device is deprecated (new bluez command line tools doesn't even ship with rfcomm command anymore). Also RFCOMM socket is easier to program for (e.g. doesn't require root to set up. Just open a connection directly in python with bdaddr and use it like a TCP socket).

Do you still have any of the CUPS work? I would love to take a look!

Not really sure. I might deleted it at some point but I can keep looking on my backups, etc.

[dogtopus]

Found it. pt-p300bt-support.patch.gz

Note the code might rot enough to be completely useless since I haven't touched this for years.