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.
Now your customers can view pages inside a PDF at a lightning speed!
Find out how one company did it with BuildVu
BuildVu allows you to
| View PDF files in a Web app |
| Convert PDF documents to HTML5 |
| Parse PDF documents as HTML |
