search

qzind / qz-print

Archive for legacy qz-print versions (1.8, 1.9). See https://github.com/qzind/tray for modern versions.
Other
141 stars 101 forks source link

PDFs not scaling on Mac #156

Closed tresf closed 8 years ago

tresf commented 8 years ago

In an attempt to workaround #155, I rendered a PDF at 300dpi, but it won't scale to the page. This seems to work fine on Windows (XPS, PDFCreator) and Linux

:no_entry: Apple OS X 10.7 (CUPS): image

:white_check_mark: Windows 10: image

:white_check_mark: Ubuntu 12.04 (CUPS) image

Trace logs:

Feb  2 00:50:17 Tress-Mac.local java[1414] <Error>: CGContextGetCTM: invalid context 0x0
Feb  2 00:50:17 Tress-Mac.local java[1414] <Error>: CGContextSetBaseCTM: invalid context 0x0
Feb  2 00:50:19 Tress-Mac.local java[1414] <Error>: CGContextGetCTM: invalid context 0x0
Feb  2 00:50:19 Tress-Mac.local java[1414] <Error>: CGContextSetBaseCTM: invalid context 0x0
[INFO] 2016-02-02 00:50:19,510 @ qz.common.TrayManager:?
    Allowed localhost to print to PDFwriter
[DEBUG] 2016-02-02 00:50:19,512 @ qz.printer.PrintServiceMatcher:?
    Searching for PrintService matching PDFwriter
[DEBUG] 2016-02-02 00:50:19,523 @ qz.printer.PrintServiceMatcher:?
    Found 1 printers
[DEBUG] 2016-02-02 00:50:19,593 @ qz.printer.PrintServiceMatcher:?
    Found match: PDFwriter
[WARN] 2016-02-02 00:50:19,603 @ qz.printer.PrintOptions:?
    Cannot read  as a valid value for interpolation, using default
[WARN] 2016-02-02 00:50:19,605 @ qz.printer.PrintOptions:?
    Cannot read  as a valid value for orientation, using default
[WARN] 2016-02-02 00:50:19,606 @ qz.printer.PrintOptions:?
    Cannot read  as a double for paperThickness, using default
[DEBUG] 2016-02-02 00:50:19,617 @ qz.ws.PrintSocketClient:?
    Using qz.printer.action.PrintPDF to print
[DEBUG] 2016-02-02 00:50:20,397 @ qz.printer.action.PrintPDF:?
    Parsed 1 files for printing
[TRACE] 2016-02-02 00:50:23,153 @ qz.printer.action.PrintPixel:?
    DPI: 300.0
[TRACE] 2016-02-02 00:50:23,155 @ qz.printer.action.PrintPixel:?
    Drawable area: 0.0,0.0:612.0,792.0
[TRACE] 2016-02-02 00:50:23,156 @ qz.printer.action.PrintPixel:?
    [30000x30000 dphi, color, 4A]
[INFO] 2016-02-02 00:50:23,169 @ qz.printer.action.PrintPixel:?
    Starting printing (1 copies)
[INFO] 2016-02-02 00:50:37,657 @ qz.ws.PrintSocketClient:?
    Printing complete
tresf commented 8 years ago

Closed via c7acaac.

image

tresf commented 8 years ago

This bug still exists for metric units, reopening. This is reproducible on Windows as well.

These two statements should yield near-identical results, but they do not.

A4, mm:

var config = qz.configs.create("PrimoPDF", {size: {width: 210, height: 297}, density: 11.811, units: 'mm'});

A4, inches:

var config = qz.configs.create("PDF", {size: {width: 8.27, height: 11.69}, density: 300, units: 'in'});

(blurring was done intentionally) image

akberenz commented 8 years ago

Do you have multiple PDF printers? Because you specify two different names in the configs, so it could be an issue of incorrect density on the second printer.

tresf commented 8 years ago

Do you have multiple PDF printers? Because you specify two different names in the configs, so it could be an issue of incorrect density on the second printer.

No, I just had the Mac line in the clipboard at the time. The test results were both done on the same machine with the same printer, despite the mistake you've noticed.

akberenz commented 8 years ago

I need logs then, because I cannot reproduce.

tresf commented 8 years ago

I need logs then, because I cannot reproduce.

Logs:

[DEBUG] 2016-02-12 10:04:00,314 @ qz.ws.PrintSocketClient:166
    Message: {"call":"print","promise":{},"params":{"printer":{"name":"PrimoPDF"},"options":{"colorType":"color","copies":1,"jobName":null,"density":11.811,"duplex":false,"interpolation":"bicubic","margins":0,"orientation":null,"paperThickness":null,"printerTray":null,"rotation":0,"scaleContent":true,"size":{"width":210,"height":297},"units":"mm","altPrinting":false,"encoding":null,"endOfDoc":null,"perSpool":1},"data":[{"type":"pdf","data":"file:///C:/Program%20Files/QZ%20Tray/demo/assets/pdf_sample.pdf"}]},"timestamp":1455289440312,"uid":"mdkhy0"}
[WARN] 2016-02-12 10:04:00,316 @ qz.ws.PrintSocketClient:204
    Bad signature on request
[INFO] 2016-02-12 10:04:02,436 @ qz.common.TrayManager:403
    Allowed localhost to print to PrimoPDF
[DEBUG] 2016-02-12 10:04:02,439 @ qz.printer.PrintServiceMatcher:42
    Searching for PrintService matching PrimoPDF
[DEBUG] 2016-02-12 10:04:02,470 @ qz.printer.PrintServiceMatcher:27
    Found 13 printers
[DEBUG] 2016-02-12 10:04:02,471 @ qz.printer.PrintServiceMatcher:72
    Found match: PrimoPDF
[DEBUG] 2016-02-12 10:04:02,481 @ qz.ws.PrintSocketClient:441
    Using qz.printer.action.PrintPDF to print
[DEBUG] 2016-02-12 10:04:02,589 @ qz.printer.action.PrintPDF:66
    Parsed 1 files for printing
[TRACE] 2016-02-12 10:04:02,608 @ qz.printer.action.PrintPixel:59
    DPI: 299.9994
[TRACE] 2016-02-12 10:04:02,609 @ qz.printer.action.PrintPixel:88
    Drawable area: 0.0,0.0:595.2744,841.88806
[TRACE] 2016-02-12 10:04:02,609 @ qz.printer.action.PrintPixel:96
    [iso-a7, 29900x29900 dphi, color]
[INFO] 2016-02-12 10:04:02,613 @ qz.printer.action.PrintPixel:103
    Starting printing (1 copies)
[INFO] 2016-02-12 10:04:03,864 @ qz.ws.PrintSocketClient:445
    Printing complete
tresf commented 8 years ago

I could also reproduce this on the XPS document writer so as long as I use mm for a measurement. It seems to ignore the scaling.

tresf commented 8 years ago

@bberenz I found something.... 

Width: 210.0, Height: 297.0, Converted Width: 74.08348, Converted Height: 104.77521, Units: Size2DSyntax.MM

It appears width and height are never getting converted to pixels, so the conversion causes some incorrect scaling to occur.

Edit: Is Size supposed to be a measurement of pixels or a measurement of units?

akberenz commented 8 years ago

It is a measurement of units. This way users can just pass us "8.5" and "11" without having to multiply it by the correct dpi first. You can see it converted to pixels as the drawable area, Drawable area: 0.0,0.0:595.2744,841.88806

tresf commented 8 years ago

It is a measurement of units. This way users can just pass us "8.5" and "11" without having to multiply it by the correct dpi first.

Ok, that makes sense... I guess what doesn't though is the way we're handing conversion. Shouldn't Size do that for us? For example, if we want pixels, shouldn't we be able to do something like Size.getPixelWidth(), Size.getPixelHeight(). As you pointed out yesterday, that CONVERT is definitely misplaced, but that starts to bring light to other places it is used, such as:

pageW = (float)pxlOpts.getSize().getWidth() * CONVERT;

Furthermore, why doesn't pageW take density into consideration? CONVERT assumes 72 dpi, so it never takes the 11.811 mm/pixel into consideration, so it never sets the pageW properly.

Edit: Another few items... 

float DENSITY ...
// ...
float pageW ...
float pageH ...

In my opinion, these should be rounded to the nearest whole number after calculations have been performed rather than casting them to double.

I took a swing at the code for about an hour, but keep getting different places that it crashes (overflow caused by stuff being too big or out of bounds caused by something in AWT), so I'm giving up for now.

akberenz commented 8 years ago

CONVERT (and subsequently pageW) uses 72 because java wants page size provided as if it was using inches at 72dpi. The 11.811 is handled in the new PrinterResolution(...) call (after being converted from dpmm to dpi). This attribute is handled entirely by the printer to scale the content to the proper size, after we've drawn it at 72. This is why there tends to be empty space if the density provided is smaller than the printer density.

In my opinion, these should be rounded to the nearest whole number after calculations have been performed rather than casting them to double.

Not sure I understand why. The paper's imageable area only takes doubles as parameters.

akberenz commented 8 years ago

This issue also appears printer related. Have you tried printing with a density of 23.633 ?

tresf commented 8 years ago

This issue also appears printer related

The logs suggest otherwise.

[rounded to the nearest whole number] Not sure I understand why. The paper's imageable area only takes doubles as parameters.

Sorry, mistake on my part.

CONVERT (and subsequently pageW) uses 72 because java wants page size provided as if it was using inches at 72dpi.

Sure, but that still makes PrintPixel.java#L50 incorrect which hasn't been patched yet.

Furthermore, that makes PrintPixel.java#L74 wrong too. You can't calculate the resolution at 72dpi (essentially the pixel resolution) with the same logic used to calculate the mm's.

I suggest echoing these values out metric and you'll see they're wrong. From what I'm reading pageW and pageH should be larger than what I'm seeing and since it works for inches, the calculations are wrong. But even inches are broken when selecting a custom page size. All of this logic needs to be revisited.

akberenz commented 8 years ago

I suggest echoing these values out metric and you'll see they're wrong.

Ok, well I know, 210mm ~ 8.27in ~ 595.44pxl @ 72dpi and 297mm ~ 11.69in ~ 841.68pxl @ 72dpi, and a glance at the logs you posted, 

[TRACE] 2016-02-12 10:04:02,609 @ qz.printer.action.PrintPixel:88
    Drawable area: 0.0,0.0:595.2744,841.88806

These do not look wrong to me. Did I calculate something wrong, or are you performing a different ops on the numbers?

tresf commented 8 years ago

In this example I try the metric equivalent of 300 dpi

https://github.com/qzind/qz-print/issues/156#issuecomment-183349840

akberenz commented 8 years ago

It doesn't matter what the DPI you specified was, the pixel dimension have to be in 72dpi.

tresf commented 8 years ago

Was unable to reproduce when attempted last night (several PCs, inches and mm). Closing.