Converting PDF user units in PDF Extract API's output to browser compatible pixel values

[Inqutec]

What formula can be used to convert PDF user units into browser-compatible measurement units (for eg: pixels)?

For eg: `TextDecorationThickness`'s value is in PDF user units, how should this be translated into pixels or any other browser compatible value?

[Joel Geraci]

Generally, the units are 72 points per inch. Also, note that the coordinate system has it's origin (0,0) at the bottom left of the page. The values are already browser compatible in that you can use "xx pt" to represent points in CSS.

[Inqutec]

That makes republishing simpler! Thanks for the clarity @Joel Geraci. So, would it be correct to assume that the co-ordinates mentioned in BBox can be represented as "xx pt" without any conversion?

While I will refer to the schema here when required, is there anything else one needs to consider when using the co-ordinate values?

[Joel Geraci]

With the BBox, you will need take into consideration that the coordinate system origin points for PDF and HTML canvas are flipped. As I mentioned, the origin for a PDF page is at the bottom left, HTML canvas is at the top left. What you can do is use the BBox to calculate the height and width and simply use the "pt" units for setting those dimensions.

[Inqutec]

Yes, you had mentioned earlier. Thanks for reiterating the same.

Not a frontend expert here, but in my experience `pt` are usually used for print purposes and `px` for screens. While browsers have been known to make the conversion between `pt` to `px` automatically, not sure if email clients will make the same conversion. Any recommendations on how to use these values for browsers and email clients?

Would using the formula `0.75pt = 1px`, work?

[Joel Geraci]

Would using the formula `0.75pt = 1px`, work?

Not really. A point is a fixed size. Pixel sizes are relative to the pixel density of the monitor.

[Inqutec]

Hmm, yes. Conversion between absolute units and relative units is not usually advisable and device dependent.

Can you confirm if using `pt` for styling in email templates had been tested to see if it works well?

It is understandable that this is tricky, because PDFs are for read-only or, printing purposes which explains the choice of using absolute units. Wanting to understand from Adobe's experience to know what works best for use for on-screen purposes. especially when the W3 specs advice using relative units.

[Joel Geraci]

HTML email isn't something I have any expertise in. 

[Inqutec]

Assuming HTML on the web, as shown during demos by Adobe, should work well with `pt`, shouldn't it?

[Inqutec]

*for HTML

[Inqutec]

@Joel Geraci Would appreciate it if clarity can be added for the above.

`Assuming for HTML on the web, as shown during demos by Adobe, should work well with `pt`, shouldn't it?`

[Test Screen Name]

There's no right answer, because this is not a standardised or recognised process. Adobe's demos just demo technology, they aren't necessarily good models for production. You need to do your own tests in as many use cases as possible. Be sure to test in mobile browsers, and on high pixel density monitors.

[Inqutec]

Yes, this is not a standardized or recognised process. However, was looking to see if Adobe or @Joel Geraci had some insights to share here.

[Joel Geraci]

All I can suggest it to try some stuff and see if it works for your use case. When I convert PDF to HTML using the output from Extract, I'm generally not trying to replicate the PDF layout, I'm republishing it so I don't expect the measurements to be even close. If I want the exact layout in an HTML page without it being a PDF viewer experience, I use our Embed API in IN_LINE mode so the PDF just acts like an image.

[Inqutec]

Using Embed API is an interesting approach. Thanks for sharing. 

I'm republishing it so I don't expect the measurements to be even close.

Until now was assuming republishing to be as reproducing the PDF in a different file format. Thanks for adding g