okarmazin / escpos4k Goto Github PK

ESC/POS includes barcode commands. Let's start with the ubiquitous QR code first.

1. Our Bluetooth connectivity implementation on Android is buggy.
2. We don't implement BT scanning, therefore we can only connect to devices that are already paired with the operating system.

Bluetooth on Android is notoriously unreliable and a hassle to work with. Android 8 introduced the CompanionDeviceManager to help applications pair with and connect to Bluetooth devices in a more sane manner.

Investigate whether we could use this technology for connecting to Bluetooth printers.

2D:

• PDF417
• QR Code
• MaxiCode
• Aztec
• DataMatrix
• GS1 DataBar Omnidirectional Stacked
• GS1 DataBar Expanded Stacked

1D:

• UPC-A
• UPC-E
• EAN13
• EAN8
• ITF
• Codabar
• Code39
• Code93
• Code128
• GS1-128
• GS1 DataBar Omnidirectional
• GS1 DataBar Expanded

We need a testing application to test the connectors.

This application should also serve as a showcase for library users.

We already have builders for setting a single style - withTextSize, withUnderline, withBold ....

Task: Add a builder called withStyle that allows setting multiple styles at once.

Add a configurable test print method for diagnostic purposes.

Ideas:

• A 100-character line sized 1x1 with repeated 0-9 pattern
  • Helps the user determine the line length of their printer
• Barcodes
  • Helps the user determine which barcode commands are supported by their printer. Not all printers support all barcodes natively

Every printer has own list supported charsets with difference Id.
For example: one printer has Windows1252 with id - 16 and other has Windows1252 with - 87.

Idea:
enum of charsetNames

enum class Charset(
    CP437("IBM437")
    CP850("IBM850")
    CP860("IBM860")
    ...
)

and charset data class

data class CharsetEncoding(
    val charsetId: Byte,
    val charsetName/charset: String/Charset,
)

And ktor has charset class
import io.ktor.utils.io.charsets.Charset

We instantiate a benign Command that ultimately does nothing, but it would be better if we didn't emit the Command in the first place.

The printer correctly reserves the blank space at the specified HRI position - if instructed to do so - but does not actually print the digits in there.

Observed behavior so far:

• EAN-13 and UPC-A: the reserved space is empty
• EAN-8: "noise-like" structured dots printed instead of digits

We have to get back the Epson TM-P20 printer and investigate where the problem lies. If our implementation is correct, the Epson printer is guaranteed to print the HRI.

It is strongly suspected that the PTP-II printer firmware is just broken.

There is no reason to apply and immediately revert a style if there was no content to be affected by the style.

The following pattern currently blindly emits the surrounding Command.TextSize(2,2), Command.TextSize(1,1).

// current text size: 1x1
withTextSize(2, 2) {
  // This does nothing, so why not avoid 
  // setting the temporary 2x2 text size as well?
}

While emitting the commands is benign, it would be nice if we didn't send unnecessary commands to the printer.

Task: If the content lambda of temporary style builders didn't do anything, do not apply the surrounding style either.

I've tried to implement this lib in an android project without success. Is there a sample app?

Unblocks #32

When applying styles such as bold, italics, textSize, do not emit any commands if the new style is the same as the currently set style.

https://developer.android.com/about/versions/14/behavior-changes-14#runtime-receivers-exported

Copy the CI setup from another library if possible.

We can get the current character width from the command list, just like withSize does it.

On API 31+ listing paired Bluetooth devices requires the BLUETOOTH_CONNECT runtime permission.

On lower API levels this was not the case and paired devices were available with the BLUETOOTH permission (normal level, automatically granted).

Currently we are accessing Bluetooth without checking for BLUETOOTH_CONNECT which leads to an exception if the permission is not granted.

Also there are several lurking NullPointerExceptions due to unchecked access to platform types returned by Android APIs.

This is the current implementation:

override fun onReceive(context: Context, intent: Intent) {
    context.unregisterReceiver(this)
    if (!cont.isActive) {
        throw CancellationException()
    }
    ...
}

We don't need to check for the continuation job active state, we can just resume regardless of its state.

We assume a character width of 1 which breaks down when the current text size is larger.

Command: GS(L