Does anybody know what is the resolution that will be used to render a printed HTML page. I'd like to know what size (in centimeters or inches) will be a printed image of say 500x500pixels. I know this value will change if I set the zoom value (IE and FF), but I am interested in the default value (when zoom is at 100%).
Also, is there any way of controlling this resolution from CSS?
Thanks
either 72ppi or 96ppi, depending on combination of OS/browser. Margins are an issue too.
If this is for a site with login users, get them to set their resolution, or try to guess from the browser. Remember that anyone can change this setting on their computer.
I think you can control the size, but not the resolution, of the printed page. Relevant units of size, for print css, would include
Centimetres (cm)
Millimetres (mm)
Points (pt)
Pica (pc)
Inches (in)
M (em)
X (ex)
Related
I've followed the answer in this post Cesium label blurred but have had no luck.
I've made sure that viewer.scene.fxaa = false and nothing seems to change. Please see my screenshot attached.
Does anyone have a fix for this?
Thanks so much!
Be wary of hard-coding something like viewer.resolutionScale = 2. There's a baked-in assumption on this line of code that the user probably has a high-DPI screen, and their browser is scaling up the webpage accordingly. Running this line of code on a system that is already using a 1:1 pixel ratio may cause it to render twice as wide and twice as tall as what the device can actually display.
Here's an alternate suggestion:
viewer.resolutionScale = window.devicePixelRatio
It's not perfect, but better than a hard-coded 2. It will attempt to get the Cesium viewer to exactly match the device's native pixels, which may not be the same size as "CSS pixels", particularly on high-DPI screens.
A value of "1" here (the default) means that Cesium's viewer canvas pixels are the same size as the webpage's idea of CSS pixels, which may be larger and chunkier than the screen's own native pixels. Higher numbers act as a multiplier on the WebGL canvas resolution, taking more graphics memory and performance. You may find that the machine you're testing this on already has a window.devicePixelRatio of 1.5 or 2.0, so the line above may not act any differently from a hard-coded 2 on your particular machine. But checking the local devicePixelRatio is better than making assumptions.
This can be fixed by adding:
viewer.resolutionScale = 2
May impact performance, but it seems fine so far.
I'm try to use modesty/pdf2json and the output is very useful, but i'm try to figuring the measure units that the library uses. They call it "Page Units", and according to the pdf specs, this is'nt equal to the 1/72 (point), because an entire page has 51 Page Units on height
Anybody knows what is this Page Unit? Where i can find info about this measurement?
Many thanks in advance.
TL;DR
The important thing to understand is that x,y and element width/height are relative units that are related to page width/height by a ratio that can be translated to any destination ratio by dividing by the existing units and multiplying by the desired units.
Here are the boring details:
PDF's don't have a standard "size" -- you can print anything you like to PDF which may include landscape or portrait orientation, different page sizes (Standard, A0-A5, Legal, Tabloid, Custom), etc. The size of a PDF is in inches so the translation to pixels (including with pdf2json) is not a fixed "24px" as indicated in #async5's answer.
The key to programmatically getting the results you want is to utilize the parsed PDF information (page width and page height) along with how you need to render it (pixel count varies by density of display resolution but an "inch" is always an "inch") and how that translates to the destination resolution you're targeting.
Since the same physical device often supports multiple resolutions (changing the logical DPI) - there may be a difference between the native pixel density and the synthesized density set by the user and so the basis for translating from PDF Units to a local display is going to be a scale factor that's made up of the difference between the PDF file and the target dpi of the physically rendered version of it. This same idea applies with PDF parsing libraries which may use a different DPI than the native "72dpi" of the pdf file itself.
While 96dpi is the Microsoft standard size (72dpi is Apple's standard), the choice of either doesn't give you a correct pixel offset b/c pdf2json or pdf.js don't know anything about the end-user display. For pdf2json coordinates (x/y) they are simply relative measurements between a position on a plane (which is defined by a width/height). So standardized to a 8.5"x11" position with 72dpi would be done as follows:
pdfRect.x = pdfRect.x * ((8.5 * 72) / parsedPdf.formImage.Width);
pdfRect.y = pdfRect.y * ((11 * 72) / parsedPdf.formImage.Pages[0].Height);
This kind of formula would work no matter what pdf2json's internal DPI is -- or frankly whatever other PDF parsing library you choose to use. That's because it cancels out those units by division and multiplying using whatever units you need. Even if today pdf2json internally uses 96dpi and downscales by 1/4 and later changes to 72dpi and downscaling by 1/2 the math above for converting to the pixel offset and dpi would work independent of that code change.
Hope this is helpful. When I was dealing with the problem it seemed the Internet was missing a spelled out version of this. Many people solving specific concrete source/destination resolution issues (including specific to a library) or talking about it in the abstract but not explaining the relationship very clearly.
Whatever pdf2json produces is not related to the PDF.js (PDF.js uses standard PDF space unit as a base)
So based on https://github.com/modesty/pdf2json/blob/3fe724db05659ad12c2c0f1b019530c906ad23de/lib/pdfunit.js :
pdf2json gets data from PDF.js in 96dpi units
scales every unit by 1/4
So page unit equal (96px/inch * 1inch / 4) = 24px.
In your example height is equal 51 * 24px = 1,224px, or 51 * 0.25inch = 12.72inch
Let's say I want to use the pt unit to make sure that my html pages look consistent across device/browser/os. My understanding of the pt is that it's supposed to be equal to 1/72 of an inch on the screen.
Codepen
HTML
<html>
<body>
<div></div>
</body>
</html>
CSS
div {
background-color:black;
height: 72pt;
width: 72pt;
}
This produces more or less what looks like a 1" x 1" square on my screen (this is just a screenshot of what I see). However, I can physically put a ruler up to my display and measure it, and the result is more like 1 3/16".
My browser zoom level is 100%, so that is not affecting things. I'm using Chrome on Windows 8.1 with the default font size set (16 in Chrome). My OS scaling level is 100%. I have a 24" monitor set to 1920x1080 resolution. Also of note, Chrome reports that the square is exactly 96x96 px.
This leads me to believe that what I have have heard, that 72pt = 1 physical inch in the real world on any given display/browser/OS combo, is NOT accurate. Is this correct?
Given this behavior, I assume that if I had a 22" monitor with the same resolution, the pixel density would be greater, and thus the square would appear smaller (perhaps closer to being exactly 1" as measured by a physical ruler).
How do Retina displays work with all of this? I assume the square will not appear twice as small (that would be silly). Is the browser doing some kind of internal handling of super high DPI displays? For instance, Chrome seems to have some concept of "device pixel ratio (DPR)" so that it can treat an iPad with a "true" resolution of 2048 x 1536 (DPR 2) as a more standard 1024 x 768. So I assume DPR ends up somewhat normalizing screens of drastically different DPI, but after that has been accounted for, different devices with different DPI/PPI will still see slightly different physical sizes of our square.
Is it true that the pt unit will ALWAYS physically measure consistently?
No, CSS abandoned that requirement in 2011 as most ignored it anyway.
https://www.w3.org/Style/Examples/007/units.en.html has more detailed explanation
The so-called absolute units (cm, mm, in, pt and pc) mean the same in CSS as everywhere else, but only if your output device has a high enough resolution. On a laser printer, 1cm should be exactly 1 centimeter. But on low-resolution devices, such as computer screens, CSS doesn't require that. And indeed, the result tends to be different from one device to another and from one CSS implementation to another. It's better to reserve these units for high-resolution devices and in particular for printed output. On computer screens and handheld devices, you'll probably not get what you expect.
In the past, CSS required that implementations display absolute units correctly even on computer screens. But as the number of incorrect implementations outnumbered correct ones and the situation didn't seem to improve, CSS abandoned that requirement in 2011. Currently, absolute units must work correctly only on printed output and on high-resolution devices.
CSS doesn't define what “high resolution” means. But as low-end printers nowadays start at 300 dpi and high-end screens are at 200 dpi, the cut-off is probably somewhere in between.
My website, for the most part, uses relative fonts and fluid layout techniques, so our site layout will scale based on what the browser's default font size is set to. But there are certain elements that have fixed widths, and our layout past a certain font size just doesn't work well or look good. It's not feasible at this point to go back and change all of those elements.
So, I want to allow the site to adjust based on the user's chosen default font size in the browser--within certain limits. For example, things start to look a bit wonky at a browser fontsize of 22px; I'd love to have the site be relative, up until it hits a maximum base size of 22px.
From what I can gather, there doesn't seem to be any easy way to specify this purely in CSS. I was thinking the best approach is to use Javascript to detect the base fontsize on page load, and if it's >22px then I'll set a style on my body tag to fix font-size to 22px. If it's less than 22px, I won't do anything (and leave our default relative style in place). I don't care as much about handling font size changes while the page is loaded, as that seems like an edge case (that would get corrected on next page load).
Is this the best approach, or are there better ways?
You cannot prevent users from increasing font size (even if you set the size in pixels, users can just Ctrl +), and many people think this is good – people may need larger font size than you expect, and breaking layout somewhat may be better than not being able to read at all. So what you can do is to make any reasonable effort to ensure that the page works reasonably for a wide range of font sizes.
I've just gotten into web development seriously, and I'm trying to make a page that appears the same physical size ( in inches ) across all browsers and platforms
I believe a combination of percentage values and inch values can make a consistent UI.
my own system is a 15.4 inch screen with 1920x1200 pixels i.e. 144 DPI.
Here is the most simple HTML code that fails to appear the right size on any browser except FireFox (Tried on Chrome 3, 4, Opera 10.5, IE7)
<html><head>
<body>
<div
style="position:absolute; width:2in; height:1in; border:1px solid" >
hello world</div>
</body></html>
Chrome, Opera and IE render a .67 inch box ( They seem to be assuming a 96 DPI screen )
I am running Windows XP, but I see no reason why that would make a difference. Similar incorrect rendering on other machines I have tested.
I thought when I say "1in" in HTML it means one actual inch in the real world....
How do I handle this?
Thanks in advance,
Vivek
Edit :
in 2006 I developed an activex control which did live video editing for a website, in 2008 we started seeing lots of Vista use and higher DPI screens which made the UI unusable, I reworked the application so that everything scaled according to DPI, since then everyones happy that they don't need glasses to use the feature....
The whole reason that Win7 and Vista have this "DPI scaling" mode is to allow non-DPI aware apps to display ( but since it basically scales up the app's canvas, the apps look blurry ).
I can't believe that calling GetDeviceCaps() or the X-Windows equivalent is harder than hardcoding 96 DPI. Anyway it wouldnt affect any page that measures in pixels....
Can't be done. Period.
Screens are a grid of pixels and that is the only unit recognized by the physical display. Any other measurement must be converted to pixels for display.
This conversion is done by the operating system's graphics subsystem, which has an internal "DPI" setting - quoted because it's arbitrary and does not necessarily correspond to the actual physical DPI of any real-world device. Windows, for example, defaults to 96 DPI regardless of the display that it's connected to.
When you look at a page with something with a height of "1in", your machine looks at it, calculates that, since it's set for 144 DPI, "1in" means 144 pixels and makes it 144 pixels tall, regardless of the physical distance that those 144 pixels will occupy on your display.
When the typical Windows user with the default 96 DPI setting looks at it, their computer calculates that "1in" = 96px and makes it 96 pixels tall, again regardless of the physical distance that will correspond to those 96 pixels.
And you know what? This is a good thing. It means that a user with poor vision can lower their video driver's DPI setting and everything sized in inches, cm, point, em, or other 'real-world' units (i.e., basically anything other than percent or pixels) will get bigger so that they can see it more easily. Conversely, those of us who don't mind small text can artificially increase our DPI settings to shrink it all and get more onto our screens.
The tyranny of the printed page, forcing things to be a certain size whether we like it or not, is no more. Embrace the power this gives your users over their experience. Don't try to take that away - you won't succeed and you'll just annoy people in the process.
Instead of giving the size in px you just give it in percentage . so that it can fit on any screen based on the percentage .
I don't really think you can, to be honest.
The DPI of the screen is determined in hardware, i.e. a 15.4" Screen with 1920x1080 resolution = 144DPI.
Why do you need the site to appear as the same physical dimensions? Surely the same size, proportional to the screen is enough? i.e. if my resolution is 1920x1080, your site should take up 50% of the wide. If I'm using 1600x1050, it should take up 60%?
In short — you can't, at least for use on screen.
Using real world units depends on having clients knowing the correct DPI for the system. Between clients that don't bother, and systems which are not configured correctly, it is a hopeless situation.
If you want something to scale so it is a reasonable size for the users system, then you are likely best off using em units to scale based on the user's font size. This still has problems where the defaults are not suitable and the user hasn't changed them, but it is right more often than physical units.