qzind/qz-print

Archive for legacy qz-print versions (1.8, 1.9). See https://github.com/qzind/tray for modern versions.

qz-print's Issues

RC-Branch: Serial Data not making it to browser

@robertcasto this is what I'm seeing from the IntelliJ console:

Nov 25, 2014 11:39:05 PM qz.ws.PrintSocket sendResponse
INFO: Response: {"method":"send","params":["COM3","\nW\n"],"callback":"qzSerialReturned","init":false,"result":"[\"COM3\",\"\u0002000.25\"]"}
Nov 25, 2014 11:39:05 PM qz.common.SerialIO serialEvent
INFO: �000.25

However, the weight value from the scale doesn't appear to be making it to the web browser.

Applet: NoClassDefFoundError, pdfrenderer/jssc

Running through some final testing and having a problem with the applet deployment when using PDF or Serial functionality. It appears the library/JAR isn't being found by the applet.

Probably a resurfacing of #9 as the symptom is identical. This time, we can reproduce. Just run sample.html from out\dist\applet\demo and try either the PDF for Serial options.

Exception in thread "Thread-17" java.lang.NoClassDefFoundError: com/sun/pdfview/PDFFile
    at qz.PrintPostScript.getPDFFile(Unknown Source)
    at qz.PrintPostScript.print(Unknown Source)
    at qz.PrintFunction.logAndPrint(Unknown Source)
    at qz.PrintFunction.printPS(Unknown Source)
    at qz.PrintApplet.startJavaScriptListener(Unknown Source)
    at qz.PrintApplet.access$000(Unknown Source)
    at qz.PrintApplet$1.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at qz.PrintApplet.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: com.sun.pdfview.PDFFile
    at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
    at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
    at sun.plugin2.applet.JNLP2ClassLoader.findClass(Unknown Source)
    at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
    at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
    at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    ... 10 more

Tagging @robertcasto @bberenz

Null printer name

Steps to reproduce:

1. Run QZ-Tray
2. Open sample_ws.html
3. Click "Allow" if prompted
4. Click "Find Printer" button
5. Click "List all printers" button
6. Click "Print EPL"

qz-tray deployment

This is a placeholder for some thoughts around qz-print deployment.

In version 1.8, the methods of deployment are:

• Via <applet> tag in the browser utilizing the Java plugin for the web browser (known as IcedTea on OpenJDK platforms)
  • Deployment is managed using deployJava.js, an Oracle JavaScript file.
  • If Java is not installed, the user is redirected to the Java download page
  • If Java is installed, the user is prompted to run the Java Plugin once, always, or block. (or IcedTea Plugin respectively) via NPAPI -- a technology soon to be disabled in Google Chrome.
  • If the plugin is granted permission the applet displays a digital signature dialog certifying the software is signed by a Trusted Publisher prompting if it is ok to run the software.
  • If the dialog is accepted, the applet runs with full user permission on the machine.

In version 1.9, in addition to that above, we will introduce a new deployment method, local installation:

• Deployment to the PC is yet to be determined.
  • Should we redirect to Java anymore? How will Oracle's script treat the disabling of NPAPI? (@lite1979 We can test this on Linux)
  • For the short term, should we provide a Windows-only installer? (i.e. NSIS installer?)
    • Chrome on OSX has historically not supported Java 7 anyway
    • Chrome/Chromium on Ubuntu generally does not automatically update as it does on Windows, existing users may be unaffected.
    • The latest Chrome on Ubuntu has already blocked NPAPI, so Linux users are actively working around this limitation anyway.
• Deployment should be initiated using a script to:
  1. Detect if HTML5 is enabled in the browser.
  2. Detect if a socket is open on a pre-defined port.
  3. (No HTML5, No Socket?) Detect if the Java Plugin is available for the browser, attempt classic deployment.
  4. (Yes HTML5, Yes Socket?) Start the applet using a websocket using modern deployment)
  5. (Yes HTML5, No Socket?) Prompt user to download and install plugin locally for local installation.

This is a work-in-progress.

Linux Installer Cleanup

The Linux installer is finally working with secure websockets. This thread is to track a few enhancements:

• Determine permanent location to install on Linux (done via b1968d7)
• Check for certutil prior to install on Linux, or else Chrome certs won't work (done via b1968d7)
  • Possibly add yum/apt-get commands for installing (partially done via b1968d7)
• Check for root prior to install on Linux (done via b1968d7)
• Optionally wrap installer in .deb file

Asynchronous Requests Bug

Edit: This should be fixed via 1b8c7fe

@robertcasto @bberenz

We're experiencing issues with only the premium customers where the signed requests are causing some intermittent issues.

I suspect that our asynchronous use of signRequest() is the culprit.

This is a pretty major bug as it breaks printing for those who've subscribed.

I think we may be able to solve this by using async: false within our $.ajax calls. Does that sound reasonable, or should we instead queue them up?

In the case of the one client, append64 is getting fired after print despite them being called the the opposite order.

-Tres

Print job mangled in qz.print() but not in qz.printToFile()

I have worked with the applet printing a good bit and have run into a wall with actual device printing. I use the append64() function to load a previously base64 encoded print job for transfer/printing thru the applet. If I send the print job to the print using qz.print(), it sends a mangled print job to the printer. It sends unreadable binary gibberish. If I use the qz.printToFile() function on that same base64 encoded/appended data, it decodes it perfectly in the file that is saved. I saw some previous bugs where the character set affected the print job decoding so I tried all of the recommended character set with qz.setencoding(). It seemed to change what the gibberish looked like but did not solve the problem. In my testing environment, the workstation running the applet is ubuntu 14.04. It has a working CUPS setup so I tried the alternate CUPS printing method but get the same gibberish results. Had hoped that if print to file worked that lpr -P printer filename might use that output but that does not seem to be the case. This is not just a result of the qz.append64(), this happens from all output of the qz.print() command no matter which of the qz.append*() functions are used to build the print job. The qz.printPS() called by the Print PDF demo button works correctly for this test environment. Has anyone else encountered this? I am using version 1.9.2.

Unable to access jarfile (Apple)

Reported by an Apple beta tester:

 /Applications/QZ\ Tray.app/Contents/MacOS/QZ\ Tray ; exit;
Error: Unable to access jarfile /Applications/QZ Tray.app/Contents/MacOS/QZ Tray/../../../qz-tray.jar

[Process completed]

setPrinter(index) not syncronous

@robertcasto @bberenz we seem to have another bug where qz.setPrinter(index) followed by qz.getPrinter(); results in the printer being undefined.

The old behavior was to use the qz.setPrinter(index) as a synchronous replacement to the qz.findPrinter() call.

-Tres

Default Printer Not Found

@robertcasto @bberenz I'm not sure what causes this, but want to open a placholder for it. The bug submitter claims this does not occur with the applet version (assuming they are using 1.8 branch for the applet as we haven't released any 1.9 branch versions).

Halt Firefox Cert Install in Enterprise Environment

Per Mike Kaply:

an enterprise environment, you'll want to make sure that AutoConfig is not already configured...

So the task is to check to see if AutoConfig is not already configured for Firefox prior to certificate installation.

qz-tray GUI enhancements

• Log viewer should periodically self-update
• Site manager should resize better
• Rephrase tray message "Blocked xyz from ever being able to print"

Timeout on read

@robertcasto is this normal, or related to serial support? I would assume we wouldn't ever want the socket to shut itself down.

SEVERE: Server error: Timeout on Read
Nov 25, 2014 11:44:27 PM qz.ws.PrintSocket onClose
INFO: WebSocket close: 1001 - Idle Timeout

Safari 5.1.7 does not work

When attempting to use QZ Tray on OSX Lion, Safari 5.1.7 never establishes a socket connection and Jetty shows the following error:

2015-04-17 18:21:13.157:WARN:oejws.WebSocketServerFactory:qtp1956710488-25: Client 0:0:0:0:0:0:0:1 (:49256) User Agent: [unset] requested WebSocket version [-1], Jetty supports version: [13]
2015-04-17 18:21:13.348:WARN:oejh.HttpParser:qtp1956710488-25: badMessage: 400 for HttpChannelOverHttp@30a8f8d8{r=1,c=false,a=IDLE,uri=-}

About free version

First of all thank you for this great plugin.

I tried your applet for seamless prints from browser but saw warning messages on every single print job. Is it possible to remove warnings in free version?

QZ-Print fallback not working properly

@bberenz @robertcasto,

I've setup https://demo.qz.io but the applet fall-back logic seems to have a problem.

The error, which is expected is Websocket connection failed, however it should have a way to catch this and call deployQZApplet.

qzSocketError and qzNoConnection don't seem to be getting called either.

I'd like to add that this behaves slightly different between HTTP and HTTPS.

Cert import Firefox

@robertcasto @bberenz Mozilla has no way of using the OSs Trusted Root certificate store.

This means certificate imports into Firefox are only possible by using the mozilla certutil command. This utility is not distributed with the Firefox browser.

For secure websockets to work in Firefox, we need a way of utilizing a trusted certificate. In the case of a self-signed certificate, we will need a way of manipulating the certificate database in use by Firefox via something like:

1. We distribute the certutil binaries with our installers and execute them against the built in certificate database (cert8.db, cert9.db, key3.db, key4.db, etc).
   • These binaries are not easy to find as pre-compiled on Apple and Windows.
   • What type of track-record does Mozilla have keeping the certutil API forward-compatible with Firefox upgrades?
2. We overwrite the certX.db with one we've created
   • How would we create this? This approach seems risky and unorthodox.
3. We find 3rd-party utilities to do this for us...
   • Windows: NSIS
   • Mac: TBD
   • Linux: TBD

Or perhaps we don't offer this out of the gate and instead...

1. We display an error to the user with instructions for installing the certificate
2. We consider not offering secure websockets support for Mozilla

This is a pretty big bummer for the project as Firefox is the default browser for Ubuntu machines and even on Ubuntu, the certutil command isn't included on a default install leaving us no easy way to automate this for our Desktop installers.

async:false is deprecated on main thread

Since signRequest() requires async:false, we need to use it to prevent race conditions, however Chrome displays a deprecation warning.

@bberenz do we have the ability to workaround this to prevent breaking down the road or is this a ticking time bomb?

Disconnect after printer rename

From a beta tester

Ok, here's the use case that causes qz tray to disconnect.

1. qz.findPrinter(name); And print to this printer. This step isn't necessary. You can just do it to make sure everything works.
2. Change the name of the printer.
3. Do another qz.findPrinter(name); And search for the new name of the printer (a partial match is fine) and then print.

QZ Tray should disconnect even though the printer is found.

Restarting qz tray after changing the name fixes this, as you've already pointed out.

printToHost() bug

After printToHost is used, the applet won't print raw to anything else.

Fixed via d7259bb.

This fix is staged for QZ Tray 1.9.1.

Edit: Related 793c61c

Provide paper size hints for PostScript printing

PrintRequestAttributeSet attributes = new HashPrintRequestAttributeSet();
attributes.add(MediaSizeName.ISO_A4);

Now, qz-print defaults to the document size specified by the printer. This is not ideal because many customers want to print to custom paper sizes without having client reconfigure each printer's default paper size via the OS.

Linux Installer

Started via 595767c

The installation of 'QZ Tray' failed on OS X

Hi, I couldn't install 'QZ Tray'.

The version of client: 1.1.9-1
The version of OS X: 10.10.3

Please see screens.

IE11 SecurityError, Websocket connection failed

Update: A workaround is available, please see qzind/tray#6

---

IE11 blocks websocket connections to localhost by default.

To unblock, click the Gear, Internet Options, Security, Local Intranet, Sites, Uncheck the first checkbox.

Edit: Domain networks have been fixed in 2.0.2 and higher via DNS workaround per qzind/tray@b30beb7

OSX 10.8 Mountain Lion / JRE6 Problem

OSX 10.8 "Mountain Lion" prompts to install Java 6 when installing QZ Tray. When the user clicks "Yes", it prevents QZ Tray from ever running as upgrading to Java 7 does not fix the issue.

One temporary fix seems to be installing Oracle JDK 8, which seems to update the java path properly so that java -version yields Java 8, not Java 6.

CRL support

This is a placeholder for CRL support via WebSockets implementation.

• Fetch CRL asyncronously
• Move CRL to Amazon Web Services / CDN
  • Done 5/29 via https://crl.qz.io --> https://d394qbcjy82lwe.cloudfront.net/

CB: undefined()

Reported by beta tester. Needs investigation.

 qz-websocket.js?r=6eb3579dd4a0f83:294 Calling setEndOfDocument(<p>) --> CB: undefined() 

Support for secure websockets

Firefox by default blocks non-secure websockets connections from HTTPS locations. This is meant to be a placeholder for secure websockets (wss://) support.

Current design includes: (please check off items as they are completed):

• Generating a jself-signed Java Keystore
• Windows
• MacOS
• Ubuntu
• Exporting an OS certificate
• Windows
• MacOS
• Ubuntu
• Installing/import OS certificate
• Windows
  • Chrome (via System Store)
  • Firefox (via NSIS + AutoConfig)
  • Firefox (via System Store)
• MacOS
  • Chrome (via System Store)
  • Firefox (via certutil or AutoConfig)
  • Safari (via System Store)
• Ubuntu
  • Chrome (??)
  • Firefox (via certutil or AutoConfig)
• Add secure websocket support to QZ-Tray/Jetty
• Add HTTP fallback support
• Fallback method for when secure websockets fails
• Can Jetty listen on an alternate port for non-secure connections?

PDFs fail on Applet

@robertcasto @bberenz

It appears something is broken with the new applet (non-websockets) as when I build and try to print a PDF or anything in the PostScript column, it throws an exception.

#content background-color

Placeholder to add enhancement to use a more specific container ID for the background color statuses as "content" has too much potential for client code conflict. This wasn't a problem in sample.html because the javascript code was strictly for example only. Now we have a redistributable JS, we should change it to something less likely to be in someone's DOM....

Recommendation: <body id="qz-status" ...> (instead of id="content")

Also, the readiness logic should check for this element before trying to change the background color to prevent the websocket script from crashing on something rudimentary such as an optional id tag.

-Tres

Are secure websockets possible?

So I'm growing increasingly concerned with the feasibility of secure websockets

The current obstacles:

• Generating a self-signed CA certificate that works with Firefox
  • From research, Endpoint Entitiy cert can't be a CA cert
  • Jetty must start using the Endpoint Entity cert
  • Firefox must import the CA cert
  • How can we script this for all platforms at install time?
• Import the CA certificate into Firefox
  • Is there an existing C++ API we can talk to? (I think so, per #18 (comment))
  • If we leverage the NSS tools, how do we compile and distribute them with the installers?
  • Firefox certs are stored in the user profile.
  • What if Firefox is installed AFTER QZ Tray?
  • Can we import the certificate every time the software is started?
• Fallback method for when secure websockets fails
  • Can Jetty listen on an alternate port for non-secure connections?
  • Moving this to #15

WARNING: Error executing certutil

On Linux when starting QZ Tray you may receive the following error:

WARNING: Error executing certutil.  Ensure it is installed properly with write access to
sql:$HOME/.pki/nssdb. Secure websockets will not function on certain browsers.

The exact cause is unknown, but a valid workaround seems to be to delete the certificate manually via:

certutil -d sql:$HOME/.pki/nssdb -D -n "QZ Industries, LLC"

Run this above command over and over until the following message appears:

certutil: could not find certificate named "QZ Industries, LLC": 
SEC_ERROR_UNRECOGNIZED_OID: Unrecognized Object Identifier.

Then try launching QZ Tray again.

QZ Tray remembers sites after deleted from Site Manager

1. Launch QZ Tray
2. Launch sample.html
3. When prompted by GatewayDialog, click "Always allow"
4. Open site manager, delete (Demo) localhost
5. Refresh sample.html
6. Notice the GatewayDialog never reappears

Expected behavior is to re-show the GatewayDialog after a site has been deleted.

NSIS - Add firewall exception

It looks like a 3rd party plugin allows this via http://nsis.sourceforge.net/NSIS_Simple_Firewall_Plugin.

The idea is to prevent users from seeing this dialog on first load:

Firefox intermittently works with HTTPS

HTTPS pages require a special certificate installation into Firefox. Currently QZ Tray installs or deletes the certificate at launch time, depending on the current install state of QZ Tray (uninstall forces certificate removal).

There seems to be a race condition on the loading of Firefox which causes the browser to start before the certificate has completed being uninstalled and reinstalled. This race condition is likely to affect all Firefox versions on all platforms (Mac, Windows, Linux).

A temporary solution is to delete C:\Program Files (x86)\Mozilla Firefox\defaults\pref\firefox-prefs.js after Firefox has loaded the first time.

A permanent solution will require some more elaborate logic in terms of when to install and when to delete the certificate. Should be ready by the time 1.9.2 is released.

Edit: 1.9.2 is released, grab it here: https://qz.io/download

deleted

wrong tracker

expiration warning for certificates

We need to add expiration warning support for qz-tray when certificates are close to expiration.

Open File Location not working on Apple

The About dialog button to open the QZ Tray working directory "Open File Location" doesn't work.

Ideally, this would open the Finder application to the /Applications/QZ Tray/ directory. This button is offered as a convenience to quickly get to the demo folder.

Steps to reproduce:

1. Install QZ Tray on a Mac (OS 10.7 or higher)
2. Once the icon goes from Red/Yellow to Green, right click, advanced, open file location

Temporary work-around:

1. Open Finder
2. Click Applications
3. Locate the QZ Tray application
4. Right click, Show Package Contents

Signing .pkg files on Apple

Apple blocks the plugin installation on Yosemite (and possibly others) because it is not a "signed" application.

It appears any key in the default keyring can sign, I'm not sure if our code-signing certificate will do the trick or not. Will try via:

http://thegreyblog.blogspot.com/2014/06/os-x-creating-packages-from-command_2.html

For now, the work-around is to browse to the Download folder, Right Click, Open on the PKG and click Open on the warning dialog.

Enhanced ESCP Image Support

This bug report has been migrated to qzind/tray#10

---

Better image support for the following ESCP printers:

• Epson TMU220
• Star (model unknown, see below)

Epson TMU220

We use appendEpsonSlices via ImageWrapper.java#L467 but pass in an m value of 33, but the TMU220 only supports values of m=1, m=2 via: (screenshot attached)

[1] This image is Copyright (C) 2002 Seiko Epson Corporation and depicted here as an educational example, reproduced under US Fair Use, §107.1

---

Star (model unknown)

It appears Star's ESCP standard differs slightly from Epson's preventing images from appending properly...

The format seems to use
http://www.starmicronics.com/support/mannualfolder/escpos_cm_en.pdf#page=158

J# returns wrong signature

When using UTF8Encoding the signature won't validate. This seems to be fixed by switching the code to use ASCIIEncoding. If this fixes the issue, it will need to be corrected in our C# sample.

module sample

open System
open System.Security.Cryptography
open System.Security.Cryptography.X509Certificates
open System.IO
open System.Text

let request = "test data"

let cert = new X509Certificate2("converted-private-key.pfx", String.Empty)

let sha1 = new SHA1CryptoServiceProvider()

let csp = cert.PrivateKey :?> RSACryptoServiceProvider
let encoder = new ASCIIEncoding()
//                ^-------------  HERE 

let data = encoder.GetBytes(request)
let binaryData = csp.SignData(data, sha1)
let output = Convert.ToBase64String(binaryData)

Console.WriteLine output

Notification when QZ Tray is not running

@bberenz @robertcasto can we put in logic to display an alert when QZ Tray is not running?

Page Refresh/GatewayDialog

The Gateway dialog doesn't behave properly with page refreshes... It displays for the first WebSocket connection and the refreshed page doesn't receive the "Allow".

Steps to reproduce:

1. Run QZ Tray
2. Load sample_ws.html in a Web Browser.
3. Click the tray to display the GatewayDialog
4. Leave the GatewayDialog open and refresh the page on the browser
5. Switch to the GatewayDialog, click Allow.
6. Switch back to the web page, it is still yellow.

Autostart by default

This bug has been migrated here:
qzind/tray#4

---

A placeholder to make QZ Tray auto-start by default, configurable at install time.

• Windows
  • Determine permanent home for autostart (registry, etc)
  • Add option to NSIS
  • Provide mechanism for disabling via GUI
• Linux
  • Determine permanent home for autostart
  • Add option to makeself scripts
  • Provide mechanism for disabling via GUI
• Mac
  • Determine permanent home for autostart (AppleScript, etc)
  • Add option to pkgbuild scripts
  • Provide mechanism for disabling via GUI

Remove or refactor plugin directories

@robertcasto @bberenz do we still need the source code for pdf-renderer or jssc as part of our project source code?

Can we easily refactor the code to just be a single qz-print directory?

Fedora Support

QZ Tray Fedora Tasks

• Add proper Firefox detection / cert installation
• Draw tray icon in correct area of OS (possible upstream bug per redhat#1014448, gnome#648773) upstream bug, won't fix.
• Allow interaction with System Tray icon on Gnome3 / Gnome Shell
• Software fails to auto-launch due to permission issues with /opt/qz-tray

The first issue is caused by the Firefox detection script assuming /usr/bin/firefox is a symlink (this is how Ubuntu does it). Instead on Fedora, Firefox is launched by a shell script which does on-the-fly platform detection. We are still investigating the best method for determine he Firefox installation path.

The second and third issues are more of a mystery. Depicted below is the behavior we're seeing after adding some compat code for the menu placement per df8e40e. The menu appears under the mouse cursor now, however the menu is not selectable and the icon placement is still incorrect.

Printers with \E in their name break findPrinter()

This bug is for qz-print versions 1.9.x and older (1.8.0 included) and breaks printer searching for search parameters containing backslash E (\E or JavaScript "\\E" also "\\\\E").

---

Example

If a printer shared on a Windows or Samba network with "E" as part of the host name, for example:

\\Elephant\printer

And you perform a search like this:

findPrinter("\\\\Elephant\\printer");

You will receive the following exception:

Exception in thread "Thread-26" java.util.regex.PatternSyntaxException: Illegal/unsupported escape sequence near index x ...
\b\Q\\Elephant\printer\E\b
      ^

This is caused by the special RegEx character \E being used within a Pattern match.

---

Work-around 1
Replace uppercase \E with lowercase \e:

   findPrinter(printerName.toLowerCase());

Reason

\e is not a reserved character, which allows printer searching to succeed

Work-around 2
Perform JavaRegex pattern escaping:

if (printerName.indexOf("\E") != -1) {
   printerName = printerName.replace(/\\E/, "\\E\\\\E\\Q");
}

Reason

This complicated combination of E's and Q's is the proper escaping technique and is a work-around until the applet is written to do this automatically

More information on these E's and Q's here:

http://stackoverflow.com/questions/11927452/what-does-these-special-characters-mean-in-java

---

Permanent Fix

The long term fix to this is to use Pattern.quote(printerName); internal to the applet, which will be corrected with 2.0.0.

-Tres

Signing Preemptive Functions

@robertcasto @bberenz

One of our customers is inquiring why we sign the preemptive function calls (ones that work without signing), i.e.

preemptive: {isActive: '', getVersion: '', getPrinter: '', getIP: '', getMac: '', getLogPostScriptFeatures: ''},

His argument is that initial load requires 6 signings to occur weighing in a 500ms load time on page refresh.

I tend to agree... If the untrusted version doesn't require a signature on these functions, why would the trusted version require a signature?

"Open File Location" not working on Widows XP

The "Open File Location" option does not work on Windows XP. The following error is displayed:

Sorry, unable to open the browser. Failed to open file file:/C:/Program%2520Files/QZ%2520Tray/ The system cannot find the path specified.

Minimum Java Version

@robertcasto @bberenz

I see we have the javac.target=1.6 (true for the applet version), but the WebSocket version requires 1.7.

I'm improving the WebSocket installers to do Java version checking, so I'd like to have the correct minimum version as part of the ant build for the WebSocket end of things, which I'll use as part of my installer checks as well via linux-installer.sh.in#L39