Initial page size support

[tresf]

Adds page size information to qz.printers.details()

TODO:

• Test on Windows, Mac, Linux
• Measure the time impact on a large list of printers

Closes #1121

[akberenz]

Can I suggest a change to the json structure for this? I don't like that we're adding two objects for every one size.
And I see we're also getting the size's name during this, so why not include it?

sizes: [
  {
    name: "iso-a4",
    inches: { width: 8.267716407775879, height: 11.692913055419922},
    millimeters: { width: 210, height: 297 }
  },
  {
    name: "na-letter",
    inches: { width: 8.5, height: 11 },
    millimeters: { width: 215.89999389648438, height: 279.3999938964844 }
  },
  // ... etc
]

[tresf]

Do you know how to get the name?

[akberenz]

In the custom hashset's add function, should be able to call toString on the MediaSizeName object (or alternatively mediaSizeName.getStringTable()[mediaSizeName.getValue()] if we want a more robust way of getting it)

[tresf]

Updated:

MacOS:

[tresf]

Ubuntu 20.04:

[tresf]

Windows 11:

[tresf]

Windows Server 2012 with 1,402 printers shows no significant delay when page size is added.

[tresf]

In the custom hashset's add function, should be able to call toString on the MediaSizeName object (or alternatively mediaSizeName.getStringTable()[mediaSizeName.getValue()] if we want a more robust way of getting it)

Ok, in Ubuntu, I have a case where this toString() is misbehaving, but choiceName is OK:

[tresf]

Ok, in Ubuntu, I have a case where this toString() is misbehaving, but choiceName is OK:

Filed a dedicated bug report: #1197