Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2.1 API not backwards compatible with 2.0 executable #311

Closed
tresf opened this issue Apr 20, 2018 · 4 comments
Closed

2.1 API not backwards compatible with 2.0 executable #311

tresf opened this issue Apr 20, 2018 · 4 comments
Assignees
Milestone

Comments

@tresf
Copy link
Contributor

tresf commented Apr 20, 2018

Quoting an email from a beta user:

We're trying to integrate qz-tray.js@version 2.1.0 [... with the ...] Tray 2.0 executable for receipt printing. All the characters are getting printed, but control commands such as Bold, Double font, etc... are not working.

We're using the code like this, ex: for Bold ON

function chr(i) {
    return String.fromCharCode(i);
} 
var cmd_on = chr(27)+ chr(33) + chr(8);
var cmd_off = chr(27)+ chr(33) + chr(0);
var printData = [
   { type: 'raw', format:'plain', data: cmd_on },
   { type: 'raw', format:'plain', data: "Text to print" },
   { type: 'raw', format:'plain', data: cmd_off) }
];

2.1 has modified the API a bit... namely, 2.1 uses "type", "format" and "flavor" parameters as explained here: https://qz.io/wiki/2.1-Raw-Printing#escpos.

@tresf tresf changed the title RAW API is not backwards compatible 2.1 API not backwards compatible with 2.0 executable Aug 10, 2018
@akberenz
Copy link
Member

Ready to test under bba7e5e on compat branch.

Also possibly related to the user's problem and worth noting:
That sample code uses format:'plain' which only exists as such in 2.0's data format. Using that with the 2.1 javascript has undefined results (since 2.1 js expects 2.1 data format, regardless of what version executable its talking to).
This change will make it appear to work correctly, but that is only because of the lossy conversion process required to support 2.0's data format coupled with the default format for the 'raw' type.

@tresf
Copy link
Contributor Author

tresf commented Aug 24, 2018

@bberenz can we shim in base64 raw support as well? The 2.1 API allows this to be provided as a flavor, but back in 2.0 it was hacked into the URL.

@akberenz
Copy link
Member

Base64 changes available under f27a562

@tresf
Copy link
Contributor Author

tresf commented Aug 30, 2018

Closed via #348.

@tresf tresf closed this as completed Aug 30, 2018
@tresf tresf added this to the 2.1 milestone Aug 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants