A PDF file are designed to be resolution independent – they are defined using resolution independent units so that the page will always appear the same size whether it is printed or displayed on any device (regardless of the dpi of the output device). So what happens if you use these units when outputting to HTML canvas and CSS?
It turns out that the page is actually smaller than the PDF page when displayed at 100%. Infact the HTML page needs the values scaled to 133% to match the size of the PDF file at 100%. Then it all works correctly.
It is actually the same issue that forces us to correct for dpi between platforms in our PDF viewer. Some computers use 96 dpi and some use 72 dpi (which is where the value 1.33 comes from as it is 96 divided by 72). Printers can use values from 72 to pretty much infinity. This matters because it you draw a line which is 96 pixels on a 72 dpi display it will be 1.3 inches long but only 1 inch on a 96 dpi display.
Adobe made the very sensible decision that a PDF page should appear the same on whatever platform you use so it adjusts the page size to ‘mimic’ 96dpi as the default setting.
So if you are using HTML, 1.33 is the magical scaling to ensure things appear the same size as they would in PDF when drawn onscreen. If you are using our PDF to HTML convertor, the fix is in friday’s release.
This post is part of our “HTML5 Article index” in these articles, we aim to help you understand the world of HTML5.
IDRsolutions develop a Java PDF library, a PDF forms to HTML5 converter, a PDF to HTML5 or SVG converter and a Java Image Library that doubles as an ImageIO replacement. On the blog our team post about anything interesting they learn about.