Media boxes get distorted

[didac-printify]

Heya there!

Our team recently tried to switch from version 0.7.0 and we've noticed that in the latest versions the values of boxes in the PDF file get rounded to integer values, seems the change happens here: https://github.com/fschutt/printpdf/blob/0.8.2/src/graphics.rs#L124

Below is a sample of the results of parsing the generated file with https://fschutt.github.io/printpdf/ using data generated in the version we were using and the latest version.

Box data with version 0.7.0:

"mediaBox": {
  "x": 0,
  "y": 0,
  "width": 31.304373,
  "height": 31.304373
},
"trimBox": {
  "x": 0,
  "y": 0,
  "width": 31.304373,
  "height": 31.304373
},
"cropBox": {
  "x": 0,
  "y": 0,
  "width": 31.304373,
  "height": 31.304373
},

Box data with version 0.8.2:

"mediaBox": {
  "x": 0,
  "y": 0,
  "width": 31,
  "height": 31
},
"trimBox": {
  "x": 0,
  "y": 0,
  "width": 31,
  "height": 31
},
"cropBox": {
  "x": 0,
  "y": 0,
  "width": 31
  "height": 31
},

My question is the following: Is this rounding expected behaviour or would it be possible to again serialize the box sizes as real numbers instead?

[fschutt]

I don't quite remember, I think it was because I didn't expect "sub-millimeter page widths / heights", so I thought it would be better that people don't get it confused for other floating-point values and get a compilation error instead. I don't see the use-case, but okay.

It should do whatever the PDF spec says, so if sub-millimeter page widths are allowed, then okay. But the idea is that parsing just parses the page operations and that "round-tripping" works without changing the original file.

It would be best to not upgrade yet, I know that the font encoding was broken a bit in 0.8.x (fixed on master) and the 0.9.x should be released this week with proper font shaping, CSS2.1 HTML support, etc. so I'll add it in the next release.