Problem with HTML printing in version 2.0.0-alpha3

dave.r...@gmail.com

unread,

Jan 20, 2016, 4:17:41 PM1/20/16

to qz-print

We have a test environment that is sucessfully printing PDF files using the QZ-Tray 2.0.0-alpha3 version.

Upon attempting to print HTML content, the following error is encountered:

JavaFX libraries not found

The same error is reported when using the sample.html program that came with the QZ-Tray 2.0.0-alpha3 version download.

How do we resolve this situation?

Dave Eland

Tres Finocchiaro

unread,

Jan 20, 2016, 4:34:51 PM1/20/16

to Dave Eland, qz-print

Dave,

This should only occur on a Java flavor which doesn't ship with JavaFX by default.

For example, OpenJDK 7 is a version which has no JavaFX available. (on the contrary, Oracle JDK7 DOES have JavaFX, but you probably still don't want to use it... here's why... )

For HTML printing to work a bare minimum of Java 7 + JavaFX is required (Oracle-provided only)
For hires HTML printing to work, a bare minimum of Java 8 + JavaFX is required (Oracle or OpenJDK provided).

We've started to document these details on our code dependencies page, but haven't yet copied them to the Pixel Printing tutorial. We'll do that right now.

Depending on the system, the installation method can vary. For Ubuntu-based systems, this WebUpd8 approach is the fastest I'm aware of, and it is what we are currently testing against for our Ubuntu machines:

http://www.webupd8.org/2012/09/install-oracle-java-8-in-ubuntu-via-ppa.html

If you're ok with OpenJFX, this is the documentation I can currently find on it is here: http://stackoverflow.com/questions/18547362/javafx-and-openjdk#comment40581145_19529820

If you're on a platform such as Windows or Mac and are still experiencing this problem, let us know the specifics and we'll reproduce on our end and offer a resolution.

-Tres

- Tres.Fin...@gmail.com

Dave Eland

--
You received this message because you are subscribed to the Google Groups "qz-print" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qz-print+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

dave.r...@gmail.com

unread,

Jan 20, 2016, 5:24:59 PM1/20/16

to qz-print, dave.r...@gmail.com

Tres:

Sure enough -- I was running under Java 7, and upon updating to Java 8 the reported problem has gone away.

Thanks for you help!

Dave

Dave Eland

unread,

Jan 20, 2016, 6:35:50 PM1/20/16

to qz-print

Tres:

The attached image file illustrates problems that are showing up in the HTML print feature of the QZ-Tray 2.0.0-alpha3 version.

On the left is the output we were able to obtain in the QZ-Tray 1.9.5 version, and on the right is the corresponding result for the 2.0.0-alpha3 version. As you can see, the receipt fails to show the image, the date/time stamp, and the barcode. The Label fails to show everything except the barcode (part of this may be a problem in how the label is aligned for printing).

In addition to the problems mentioned above, upon attempting to print on my HP Deskjet Pro 8600 printer an 8.5x11 page that contained an invoice the following error was reported:

Error: Image or Density is too large for HTML printing

When we saw the improvements made in rendering PDF outputs (e.g. our test PDF documents were showing misaligned outputs in the 1.9.5 version, but were OK in the 2.0.0-alpha3 version) we considered abandoning our HTML capability. Part of this was driven by the following problems with the HTML approach:

1. Proper pagination of a document that spans multiple pages is quite a challenge.

2. The HTML must be scaled up behind the scenes in order to ultimately get a readable barcode.

The PDF approach solves both of these problems. The problem with the PDF approach is that we need to use a PHP program on the server to convert the HTML already generated for use in the web application. This extra time spent on the server may or may not become an issue as we support more and more customers.

So, the problems with the HTML printing are not deal breakers for us, but I thought you might want to be aware of these issues.

Dave

P.S.

The information below shows the HTML that was being rendered.

The receipt is a fabricated example that contains text, an image, and a barcode. The label is an actual excerpt of HTML generated in our web application.

In both examples, the HTML content in the "htmlContent" <div> is what was passed to the HTML print rendering process.

receipt_1.html

--------------

<!DOCTYPE HTML>

<html>

<head>

<style>

.print-block

{

display: block !important;

}

.center

{

margin: auto;

text-align: center;

}

.pull-left

{

float: left;

}

.pull-right

{

float: right;

}

#receiptDiv

{

width: 3.0in;

padding-left: 0.0in;

padding-right: 0.0in;

fontSize: 12pt;

}

#company

{

font-size: 20pt;

font-weight: bold;

}

#total

{

font-size: 14pt;

font-weight: bold;

}

</style>

function setDateTime()

{

var now,day,month,year,date,hour,min,sec,time;

now = new Date();

day = ("0" + now.getDate()).slice(-2);

month = ("0" + (now.getMonth() + 1)).slice(-2);

year = now.getFullYear();

date = month + "/" + day + "/" + year;

$("#date").html(date);

hour = ("0" + now.getHours()).slice(-2);

min = ("0" + now.getMinutes()).slice(-2);

sec = ("0" + now.getSeconds()).slice(-2);

time = hour + ":" + min + ":" + sec;

$("#time").html(time);

} // setDateTime

function loadBarcode()

{

$("#barcodeDiv").barcode

(

"123456",

"code39", // code39,code128,datamatrix

{

barWidth: 1,

barHeight: 30,

showHRI: true,

fontSize: 12,

output: "css" // css,svg,bmp,canvas(does not work)

}

);

} // loadBarcode

function initialize()

{

setDateTime();

loadBarcode();

} // initialize

</script>

</head>

<div>

</div>

<br>

ABC Company

</div>

<br>

<div>

</div>

<div>

<span class="pull-left">ABC widget</span>

</div>

<br>

<div>

</div>

<span class="pull-left">TOTAL</span>

</div>

</div>

</body>

</html>

label_1.html

------------

<!DOCTYPE HTML>

<html>

<head>

</head>

<body>

<div class="name">iPad Audio Flex Cable</div>

</div>

</div>

</body></html>

QZ1.9.5_vs_2.0.0-alpha3.jpg

Dave Eland

unread,

Jan 20, 2016, 6:41:41 PM1/20/16

to qz-print

Oops -- need to make a correction. At the present time, I am feeding in the content of the entire HTML file rather than just the information in the "htmlContent" div. I need to review exactly what is getting passed in to the qz print function as the HTML to render. I will get back to you on this issue.

Tres Finocchiaro

unread,

Jan 20, 2016, 6:51:54 PM1/20/16

to Dave Eland, qz-print

FYI, we patched a width problem today. Will have to send out an RC4.

Dave Eland

unread,

Jan 20, 2016, 7:02:17 PM1/20/16

to qz-print

Tres:

My apologies.

You made the HTML printing so simple compared to the previous work that had to be done that I forgot about the complexities of things in my code base that had to be properly in place to prepare the HTML in the first place. Once I got my act together, the HTML is printing correctly in the 2.0.0-alpha3 version (apart from some image scaling issues that can presumably be solved).

Sorry to stir up so much dust over a problem that turned out to be on my side of things.

Dave

Tres Finocchiaro

unread,

Jan 21, 2016, 2:25:55 AM1/21/16

to Dave Eland, qz-print

Dave,

Thanks again for the details.

HTML printing in Alpha3 is currently cutting off content due to a width calculation problem which we were able to resolve today via https://github.com/qzind/qz-print/commit/568ff9f7980786526a2878dc1655d37828593a9e#diff-13ef3a1c22e2ceeba6bb458a54243485R60

In addition, even after applying the patch, there seems to be some layout bugs we're still working out.

The reason I mention this is that your scaling problems may have to be tweaked again after we get these items ironed out.

-Tres

- Tres.Fin...@gmail.com

dave.r...@gmail.com

unread,

Jan 21, 2016, 6:15:11 PM1/21/16

to qz-print, dave.r...@gmail.com

Tres:

Today I had a conversation with the folks at BrickWire LLC (for whom I am doing the work in evaluating the QZ solution for printing from within the context of a web page browser).

They were intrigued by my remarks about the new capability of high resolution printing of HTML. This led to the following questions:

1. Is the following problem:

Error: Image or Density is too large for HTML printing

something that will be resolved by the time the 2.0 production release is in place, or is this an intrinsic limit to your HTML printing process? (this problem appeared in attempting to print an 8.5x11 page that contained invoice information)

2. Does your solution for rendering HTML content handle automated determination of page breaks? (if the HTML content is too large to fit on a page, do you "graciously" advance to a subsequent printed page as necessary?)

3. Is it correct to assume that a scanable barcode is produced when using the high resolution rendering of HTML content? (we want to print barcodes on a receipt printer, a label printer, and a "page" printer)

The motivation behind these questions is to determine which of the following paths to pursue:

1. Generate all printed output directly from our HTML content.

2. Convert all or our HTML content to PDF form in order to get reliable printed output.

3. Develop a hybrid approach where some output is from HTML content and some is from PDF files.

We appreciate all the work you are doing to help provide top notch solutions to the browser printing problem.

Dave

Tres Finocchiaro

unread,

Jan 22, 2016, 9:43:44 AM1/22/16

to Dave Eland, qz-print

Sorry for the delay. We've been unusually busy these past few days. Will have a thorough response as soon as possible.

Tres Finocchiaro

unread,

Jan 23, 2016, 11:10:10 PM1/23/16

to Dave Eland, qz-print

"Error: Image or Density is too large for HTML printing"

[is this] something that will be resolved by the time the 2.0 production release is in place, or is this an intrinsic limit to your HTML printing process? (this problem appeared in attempting to print an 8.5x11 page that contained invoice information)

Intrinsic per community discussion via upstream bug with the size of the webview window we're using. Our current logic makes the JavaFX WebView DPI * image width.

At 72-dpi, this crash generally doesn't occur because the image is 612 pixels @ US Letter size.
At 600-dpi, this crash generally does occur because the image is 5,100 pixels @ US Letter size.
On my machine, 300-dpi doesn't crash.
We haven't extensively tested the limitations of this.
We're willing to take recommendations on how to work-around this.

2. Does your solution for rendering HTML content handle automated determination of page breaks? (if the HTML content is too large to fit on a page, do you "graciously" advance to a subsequent printed page as necessary?)

Although this was part of the original design of 2.0, it never made it in. This would come in a future release.

3. Is it correct to assume that a scanable barcode is produced when using the high resolution rendering of HTML content? (we want to print barcodes on a receipt printer, a label printer, and a "page" printer)

In short, yes. Zebra printers default to 203 DPI and the HTML functionality has the capacity to render much above that so as long as the aforementioned page width bug is taken into consideration.

The motivation behind these questions is to determine which of the following paths to pursue:

1. Generate all printed output directly from our HTML content.
2. Convert all or our HTML content to PDF form in order to get reliable printed output.
3. Develop a hybrid approach where some output is from HTML content and some is from PDF files.

We appreciate all the work you are doing to help provide top notch solutions to the browser printing problem.

I cannot express enough how impressed I've been with the new PDF support. I can say this because it is solely the work of the Apache PDFBOX community.

Our density-zero patch, our PDFs render at the native printer DPI so as long as one isn't explicitly provided.

This yields higher resolution vector prints at a fraction of the bandwidth
While testing, don't test with the XPS printer driver as there seems to be a quality bug with that particular driver. PDFBOX team has confirmed this and they've also confirmed this doesn't affect CUPS virtual printer or PDFCreator (3rd party).

PDFs support multiple pages

So if you have a good server-side HTML-to-PDF library, that may yield the best results.

We're also open to ideas on universal label formats. We understand that this problem (support as many devices as possible) conflicts a bit with the conservative label printing market (existing market tends to best support printer-specific raw commands) so we'd be happy to entertain alternatives to what we're offering today if it makes printing easier.

Tres Finocchiaro

unread,

Feb 4, 2016, 12:06:10 AM2/4/16

to Dave Eland, qz-p...@googlegroups.com

Dave,

Some good news. We've resolved a major issue with our Pixel-Printing logic, which affects PDFs, HTML, Images.

https://github.com/qzind/qz-print/issues/145

The hard-crash printing PDFs on Mac still exists, but this latest patch allows Mac clients to use the DPI-workaround we discussed previously, making PDFs a possibility on Mac until Java or Apache fix the upstream bug.

This fix will be available in our first beta release, expected by the end of the week. We'll send a link once it's ready.

- Tres.Fin...@gmail.com

On Sun, Jan 24, 2016 at 7:35 PM, Dave Eland <dave.r...@gmail.com> wrote:

Tres:

Thanks for your thoughtful reply to my questions on HTML printing issues.

I will pass the information along to the folks at BrickWire and we will have some conversations on the issues that remain to be resolved.

We will wait until you release your "production" version of the QZ 2.0 release before making our decision of whether to go with a PDF based solution for our printing scenarios, or whether to include some HTML printing in the mix.

Again, thanks for all your helpful support in all of this.

Dave

Reply all

Reply to author

Forward