Bring forward 2.0 html raster refactoring

[tresf]

Bring forward all race condition fixes (and performance improvement fixes) from #580.

[designgears]

Just gave this a test run, things are much faster now. If I send a single page, works great, if I send an array of pages over only the first page has content, the rest end up blank.

qz.print(config, [printData1])

vs

qz.print(config, [printData1, printData2, printData3, printData4, printData5])

[akberenz]

Fix is up for blanks on vector prints. However in retesting raster prints I'm seeing the first print show up blank (second+ prints are successful).
This appears to exist before the vector fix too and will need some further investigation before we can merge.

[designgears]

Looking good! All pages appear to be rendering now! However, it looks like all of the options are being ignored.

[tresf]

it looks like all of the options are being ignored.

Can you please be more specific? The code you've provided didn't show any options.

[designgears]

None of these options are used, I dropped grayscale and rotation in there just to be completely sure.

var printConfig = qz.configs.create(printer, {
	colorType: "grayscale",
	interpolation: "nearest-neighbor",
	scaleContent: false,
	units: "in",
	density: "600",
	rotation: 90,
	size: {
		width: 8.5,
		height: 11
	},
	density: "draft"
})

return qz.print(printConfig, [printData1, printData2, printData3, printData4, printData5])

[tresf]

Thanks, I've added some comments by each parameter. If the feature works with PDF and rasterize: false, it should work with HTML and rasterize: false and if it doesn't, it's a bug. We'll take a look.

{
   colorType: "grayscale", // Many drivers ignore this.  Does it work with PDF?
   interpolation: "nearest-neighbor", // HTML ignores this unfortunately
   scaleContent: false, // This should work
   units: "in", // This should work
   density: "600", // This should work but it will only select a known density from the printer
   rotation: 90, // We'll have to test this
   size: { // This should work, but some drivers require you set the default option too
      width: 8.5,
      height: 11
}

[designgears]

I just switched from PDF to plain html, I'll remove the options you said don't work. I know scaleContent isn't working, I can use that snippet of code with v2.1.0 and the content isn't scaled, but on this branch it's scaled.

That's a 100% crop from the output

Left side: this PR
Right side: v2.1.0

[akberenz]

rotation: 90, // We'll have to test this

This property currently only works if "rasterize" is set to true, this is a pre-exisiting limitation.

@designgears, not sure I understand the problem you are having with scaling, are you saying part of your print is being cut off?

[designgears]

@designgears, not sure I understand the problem you are having with scaling, are you saying part of your print is being cut off?

It's not being cut off, it's just zoomed in making the text huge and the images blurry.

[tresf]

It's not being cut off, it's just zoomed in making the text huge and the images blurry.

I believe this statement is in regards to { rasterize: true } only. This was default true in 2.0 (only option) and is default to false in 2.1 and can be re-enabled via configuration.

I tested this branch against 2.0 and -- although zoomed and ugly as described -- the scaleContent: false behaves the same. Whether or not that's desired is uncertain at this point but for historical reasons we're leaving that for now.

To that point, 2.1 will results in smaller (e.g. KB) print jobs and thus faster printing, so if this branch is viable, it's a better option. Assuming some other options (such as rotate) are required, it may not be possible to use this branch in your exact use-case. We'll file a bug report for rotation so that it's not lost. Edit: Bug report: #529

[tresf]

Closing as superseded by #632 which is testing very well.