JavaFX did not start #622
Comments
|
We haven't tried Java 14 yet, so there might be a bug. I assume this is on x86_64? I have to ask because we don't yet provide Java FX for Linux ARM64 with our installer. |
|
It is x86_64, what version of Java would you recommend for the current version of QZ? |
|
AdoptOpenJDK11 will work on 18.04. Note, although this will fix your issue it's still on us to find out why Java 14 is failing. |
|
I'll swap that on my server and give it a go and report back. |
|
Great. Note:
|
|
Getting the same issue. How would I go about starting the JVM in a virtual framebuffer?
|
|
I haven't done it in ages, but |
|
A quick test produced the same results, I saw there were more complex setups for xvfb but haven't tried them yet. This yielded the same result unfortunately.
|
|
I've had some success with this setup, however it takes about 1s per page. Is that what I should expect? The page contains text, 2 tables, base64 encoded jpg logo, svg barcode. |
Possibly. We completely reworked the timing over on #623 if you're interested in testing it. We're a bit backlogged and haven't tested it yet, but it's expected to be merged for 2.1.1 or possibly 2.1.2. |
Well, that was much faster, it printed the proper number of pages, but every page after the first one was blank. |
|
Thanks, can you provide your feedback over there and we'll take a look. |
|
@designgears as we attempt to fix the behavior for the 2.1.1 release, we're also finalizing the 2.0.12 release which also adds performance improvements. If interested, a build is available for download here. Note, this uses the older, slower |
|
This is working well headless, but I'm unable to control the content zoom, it blows everything up to x4.166666666666667 The text below is; |
|
Can you use |
|
That corrected the scaling issue, isn't that reverse of what it's supposed to do? |
|
2.0 defaulted to true whereas 2.1 defaulted to false. Of course 2.1 uses a different technique so it's not the same result. I'm looking into it but @bberenz says this is how it's always behaved so it may be a nuance of 2.0 that we can't fix. I'll know more as our testers run regression tests. |
|
To add a bit more context, 2.1's sample defaults to false, so if you're switching back and forth that would explain it. |
|
I swapped from 2.1 to 2.0 test build you posted, scaleContent has always been set to false, pretty sure the only version I've used until now has been 2.1. So the switching certainly explains it if that has always been that way on 2.0. Totally fine with that, I had to make some code tweaks to make |
|
I'm closing this as resolved for two reasons:
So I think this is good to close. Please request a reopen if you believe it was closed incorrectly or prematurely. |
|
Sounds good, HTML rendering is pretty intense, doing around 94 pages around 100+ times a day. Even with a 4cores at 2.3ghz per it takes about 30 seconds to hit the printer. Ultimately went back to passing the HTML off to wkhtmltopdf on the webserver to generate a base64encoded pdf, pass that back to the tablet, and send that off to qz. Not sure if it's possible but I would love to see an wkhtmltopdf/wkhtmltoimage implementation down the road. :) |
|
2.0 is pretty taxing because it has to snapshot the webpage each time and for higher dpi printers, that's a lot. 2.1 fixes that by sending vector data to the printer, but the performance improvements won't land there until early next week. wkhtmltopdf actually uses WebKit (as does JavaFX) to perform the PDF conversion, it's likely a better long-term solution (per #558) but replacing it would be quite the undertaking. |
Simplest way I was able to reproduce the issue was using the demo page pixel printing tab and clicking the print html button.
It works fine when using my windows 10 dev env with the same versions of QZ and Java.
I also tried compiling from source, but got the same results, works in windows, fails in ubuntu.
OS Version:
QZ Tray Version:
Java Version:
Log:
The text was updated successfully, but these errors were encountered: