Inconsistent HTML printing #32
Comments
|
May be a duplicate of https://bugs.openjdk.java.net/browse/JDK-8073710 (unresolved). One work-around is to set the look and feel to https://github.com/qzind/tray/blob/2.0/src/qz/utils/SystemUtilities.java#L178 - UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
+ UIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName());@klabarge can you see if the problem disappears when you force the Metal look and feel? If so, we may want to shim a L&F workaround for this HTML window on Ubuntu. |
Unfortunately, this doesn't remedy this problem, HTML printing is still inconsistently sized on Ubuntu 14.04 + Java 8u25, or Java 8u77. I don't believe this is related to https://bugs.openjdk.java.net/browse/JDK-8073710.
What does seem to work is changing
@bberenz thoughts? |
You state this and I'm reminded of setting layouts in swing. So it shouldn't hurt to set both pref and min (and we probably should), especially if it fixes problems with linux. |
|
👍 51 successful prints, closing as resolved. |
|
This issue resurfaces when using a custom page I am using A4 size (8.3in x 11.7in) and sometimes my results are 35.5kb, 16.5kb, or 135.5kb. |
|
@klabarge actually I believe it was never fixed.
First print:
Second print (same default settings):
Change paper size (US Letter):
|
|
There's definitely something hairy going on and it's relatively consistent... @bberenz any thoughts here? You should be able to reproduce this in VM.
If I change:
This yields different results, the content doesn't seem to be getting cut off at the same place... So I had to make the content taller to reproduce the cutoff... First print (fresh load of QZ Tray): Second print (same exact settings): And then with the following code...
First print (frest load of QZ Tray): Second print (same exact settings): |
|
Hmm... I commented out the @bberenz new question... why aren't we doing this... Platform.runLater(new Thread() {
public void run() {
try {
pageWidth = width;
pageHeight = height;
pageZoom = zoom;
+ webView.setMinSize(zoom * width, zoom * height);
+ webView.setPrefSize(zoom * width, zoom * height);
+ webView.autosize(); |
|
Because we don't know what values we can use at that point in the capture. |
|
Well, FWIW, the above logic seems to "fix" it on Linux. Without it, the height is shortened the first go-round. |
Unless I'm doing something wrong, I could not reproduce this on a VM running ubuntu 15.10, 14.04, or 12.04. (running without your alteration, just what currently sits in the repo)
Are you supplying the |
Hmm... I just fired up a different 12.04 x64 VM...
Some things Kyle and I may have in common:
|
|
Ok....
@klabarge, can you confirm this? |
|
After running updates and rebooting I am still able to reproduce this issue. I used the Software Updater and also ran a I sent 20 print jobs: 10 without setting a page size and 10 with setting a page size.
The desired file size is
|
|
Testing on hardware on 2 Unbutu-based computers: Ubuntu 14.04 LTS - AMD FX 8320 - 24GB RAM - 12 tests - no flaws, no partial prints Linux Mint 17.3 - Intel i5 - 6GB RAM - 10 tests - no flaws, no partial prints |
|
Recreated Kyle's symptoms in 16.04 LTS in Virtual Box using Oracle Java 8 from the webupd8team. Note: VM was struggling to keep up, and I had to wait several seconds for each print job. VM specs: 8GB virtual hard drive, 768MB RAM, 1 processor |
|
Bumping up Video memory to 128MB and RAM to 2048MB produces zero errors and no partial prints in above VM. (recommended video memory was 4MB) Brought video memory back down to 4MB, still produced zero errors. Brought RAM back down to 1024MB, zero errors. Brought RAM down to 512MB and got this (expected):
|
|
I have an Ubuntu 14.04 laptop that I've done some testing on - unable to reproduce this on physical hardware. I think it's worth mentioning that I used Oracle Java 8 from the webupd8team 30 prints and all are the same size... 😕 |
|
@klabarge thanks. That's an overwhelming amount of "it an't broke", so we'll close this one out and monitor it from support perspective. P.S. Thanks for getting that UEFI/Chromebook working today. The test results are much appreciated. Thanks to the rest as well. This is a very sporadic bug and I have a feeling it will rear its head again, and we can reopen it then. 👍 |
|
Just reproduced this on Mac, reopening (happened first time only).
|
|
Marking as upstream bug. If we can get a Short, Self Contained, Correct Example of this it will make it much easier to escalate to Oracle. |
|
Interesting write-up here, especially the http://java-no-makanaikata.blogspot.com/2012/10/javafx-webview-size-trick.html Mirror: |
|
@klabarge when I run the software with Note, Java recommends replacing this command with |
|
I launched the software via
|
|
I also tested with Here's a snippet of what the 8.6kb PDF is, a black bar at the top right-hand corner.
|
|
I'm closing this since we can't reproduce on physical hardware and its upstream anyway. I have a feeling this will resurface since Mac has already shown some blank pages but we can open a dedicated issue on that once 2.1 QA starts. Closing, marking as |
|
Sorry. I know this is an old, closed ticket. My team was having this issue with partial prints on the first job. I resolved it entirely by increasing the time before the HTML snapshot. In "src/qz/printer/action/WebApp.java", I arbitrarily changed: I figured I'd mention this in case the issue persists into future versions of QZ Tray. |
I sent 10 identical print jobs to a PDF printer on Ubuntu 14.04. I used complete defaults from https://demo.qz.io/ except I changed the job name for each print.
I don't see any difference in the console between the three different outcomes, but I have provided the stacktraces anyway. I have not provided logs for
rasterize : falsebut can be provided if needed.Here are the results:
I then sent an additional 10 jobs with
rasterize : falseWith Rastorize
17.9kb
36.3kb
136.7kb
Without Rasterize
Result:
Result:
Result:
The text was updated successfully, but these errors were encountered: