Display Two Object Same Real Distance (E.G. Inches) Apart Across Different Browers/Screen Sizes

var ctx = document.querySelector("canvas").getContext("2d"),
    rng = document.querySelector("input");

ctx.translate(0.5, 0.5);
ctx.font = "16px sans-serif";
ctx.fillStyle = "#c00";
render(+rng.value);

rng.onchange = rng.oninput = function() {render(+this.value)}; // update on change

function render(v) {
  ctx.clearRect(-0.5, -0.5, 600, 300);
  ctx.strokeRect(0, 0, v, v);
  ctx.fillText(v + " PPI", 10, 20);
  
  // draw marks which should be 4 inches apart
  ctx.fillRect(0, 0, 3, 150);
  ctx.fillRect(96*4 * (v / 96), 0, 3, 150);      // assuming 96 DPI base resolution
  ctx.fillText("------  Should be 4 inches apart ------", 50, 140);
}

<label>Adjust so square below equals 1 inch:
<input type=range value=96 min=72 max=145></label>
<canvas width=600 height=300></canvas>

canvas.toDataURL() does not alter image quality. How comes?

How is it possible to refer to a print resolution when there is no printing involved?

The quote from MDN is wrong in the sense it refers to DPI as resolution for the image.

(Side note: PPI vs DPI differs in physical properties - but not really important in this context. You'll see me using DPI for PPI as it has been so ingrained since I started using it in the early 90s).

The (somewhat) short answer to your question would be:

Images are only measured in pixels and has no concept of real-world sizes. DPI is purely arbitrarily when saved as meta in/with images and function as a hint when transferred to physical medium such as a screen or to paper (and the entire pipe-line displaying the image considers its DPI).

As to why: The 96 DPI refers to the "standard" (but inaccurate and a bit outdated) screen pixel density so that if you do print your image to paper as-is and hold the paper up against your screen the content on paper should somewhat match in size with that you see on the screen (most people don't calibrate theirs screens for actual DPI, and manufacturers are sometimes sloppy with their drivers, if not a generic driver is used, so there will be a small error margin).

The browser doesn't actually store this information in the image files it produces either (not that it need to, see below).

And just to document, lets first look at the binaries of a JPEG file:

^{Hex-dump of JPEG saved from Firefox, but the case is the same for Chrome.}

Nope, no unit defined (0) at position 0x0D. This must be either 1 (inch) or 2 (cm) (and of course no EXIF (0xffe1/APP1) as there is no camera/scanner producing the image).

How about PNG then?

^{Hex-dump of PNG saved from Firefox, but the case is the same for Chrome.}

Nope, neither here. No pHYs chunk and IHDR only contains actual pixel resolution.

And that's OK as an image is assumed to be 96 DPI on most systems nowadays so it doesn't have any consequences (where DPI is actually used to affect the image, and no other DPI/PPI is defined).

For you and me in most cases though, a 1920x1080 image will be 1920x1080 on a 15" as well as on a 50" screen. Just ignore...

So in conclusion: When you pass the image through the canvas the image may have a hint embedded that indicates for example 300 DPI. This is stripped off of course when saving out canvas, but it does not alter the image resolution (provided the canvas is of the same pixel resolution as the original image) so there will be no drop in print quality (compression via JPEG can of course affect general quality, but for actual resolution there is no change).

Why em instead of px?

The reason I asked this question was that I forgot how to use em's as it was a while I was hacking happily in CSS. People didn't notice that I kept the question general as I wasn't talking about sizing fonts per se. I was more interested in how to define styles on any given block element on the page.

As Henrik Paul and others pointed out em is proportional to the font-size used in the element. It's a common practice to define sizes on block elements in px, however, sizing up fonts in browsers usually breaks this design. Resizing fonts is commonly done with the shortcut keys Ctrl++ or Ctrl+-. So a good practice is to use em's instead.

Using px to define the width

Here is an illustrating example. Say we have a div-tag that we want to turn into a stylish date box, we may have HTML-code that looks like this:

<div class="date-box">
    <p class="month">July</p>
    <p class="day">4</p>
</div>

A simple implementation would defining the width of the date-box class in px:

* { margin: 0; padding: 0; }

p.month { font-size: 10pt; }

p.day { font-size: 24pt; font-weight: bold; }

div.date-box {
    background-color: #DD2222;
    font-family: Arial, sans-serif;
    color: white;
    width: 50px;
}

The problem

However, if we want to size the text up in our browser the design will break. The text will also bleed outside the box which is almost the same what happens with SO's design as flodin points out. This is because the box will remain the same size in width as it is locked to 50px.

Using em instead

A smarter way is to define the width in ems instead:

div.date-box {
    background-color: #DD2222;
    font-family: Arial, sans-serif;
    color: white;
    width: 2.5em;
}

* { margin: 0; padding: 0; font-size: 10pt; }

// Initial width of date-box = 10 pt x 2.5 em = 25 pt
// Will also work if you used px instead of pt

That way you have a fluid design on the date-box, i.e. the box will size up together with the text in proportion to the font-size defined for the date-box. In this example, the font-size is defined in * as 10pt and will size up 2.5 times to that font size. So when you're sizing the fonts in the browser, the box will have 2.5 times the size of that font-size.

How do I determine the true pixel size of my Monitor in .NET?

For the display size you'll want Screen.PrimaryScreen.Bounds.Size (or Screen.GetBounds(myform)).

If you want the DPI, use the DpiX and DpiY properties of Graphics:

PointF dpi = PointF.Empty;
using(Graphics g = this.CreateGraphics()){
    dpi.X = g.DpiX;
    dpi.Y = g.DpiY;
}

---

Oh, wait! You wanted actual, hold a ruler up to the monitor and measure, size?! No. Not possible using any OS services. The OS doesn't know the actual dimensions of the monitor, or how the user has it calibrated. Some of this information is theoretically detectable, but it's not deterministic enough for the OS to use it reliably, so it doesn't.

As a work around, you can try a couple of things.

• You can try to query the display string of the installed monitor device (I'm not sure how to do that) and see if you can parse out a sensible size out of that. For example, the monitor might be a "ValueBin E17p", and you might deduce that it's a 17" monitor from that. Of course, this display string is likely to be "Plug and Play Monitor". This scheme is pretty sketchy at best.
• You could ask the user what size monitor they have. Maybe they'll know.

Once you know (or think you know) the monitor's diagonal size, you need to find its physical aspect ratio. Again, a couple of things:

• Assume the current pixel aspect ratio matches the monitor's physical aspect ratio. This assumes that (A) the user has chosen a resolution that is ideal for their monitor, and that (B) the monitor has square pixels. I don't know of a current consumer-oriented computer monitor that doesn't have square pixels, but older ones did and newer ones might.
• Ask the user. Maybe they'll know.

Once you know (or think you know) what the monitor's diagonal size and physical aspect ratio are, then you you can calculate it's physical width and height. A² + B² = C², so a few calculations will give it to you good:

If you found out that it's a 17" monitor, and its current resolution is 1280 x 1024:

1280² + 1024² = 2686976

Sqrt(2686976) = 1639.1998047828092637409837247032

17" * 1280 / 1639.2 = 13.274768179599804782820888238165"

17" * 1024 / 1639.2 = 10.619814543679843826256710590532"

This puts the physical width at 13.27" and the physical height at 10.62". This makes the pixels 13.27" / 1280 = 10.62" / 1024 = 0.01037" or about 0.263 mm.

Of course, all of this is invalid if the user doesn't have a suitable resolution, the monitor has wacky non-square pixels, or it's an older analog monitor and the controls aren't adjusted properly for the display to fill the entire physical screen. Or worse, it could be a projector.

In the end, you may be best off performing a calibration step where you have the user actually hold a ruler up to the screen, and measure the size of something for you. You could:

• Have the user click the mouse on any two points an inch (or a centimeter) apart.
• Draw a box on the screen and have the user press the up and down arrows to adjust its height, and the left and right arrows to adjust its width, until the box is exactly one inch (or centimeter) square according to their ruler.
• Draw a box on the screen and have the user tell you how many inches/centimeters it is in each dimension.

No matter what you do, don't expect your results to be 100% accurate. There are way too many factors at play for you (or the user) to get this exactly correct, every time.

Be aware that 96 dpi is usually pretty close to accurate. Modern pixels on non-projected screens all tend to be about 0.25 mm, give or take, so you usually end up with about 100 physical pixels per inch, give or take, if the monitor is set to its native resolution. (Of course, this is a huge generalization and does not apply to all monitors. Eee PCs, for example, have pixels about 0.19 mm in size, if I remember the specs correctly.)

Is sizing fonts using em still relevant?

Do not specify the font-size in absolute length units for screen stylesheets. They render inconsistently across platforms and can't be resized by the User Agent (e.g browser). Keep the usage of such units for styling on media with fixed and known physical properties (e.g print)

If you will use this method, no need to calculate

You can set the font-size of the body to 62.5%(that is 62.5% of the default of 16px), which equates to 10px, or 0.625EMs. Now you can set your font-size in EMs with an easy to remember conversion, divide the px by 10.

* 12px = 1.2EMs
* 13px = 1.3EMs
* 16px = 1.6EMs
* 8px = 0.8EMs
* etc…

This makes everything SUPER easy to remember and eliminates the need for conversion tables. Of course, you will still need to use a conversion table for nested elements when using EMs, if you are not being specific in your CSS, which is a whole separate issue.

But 76% is much better and you can use this to calculate http://pxtoem.com/

Yes it's still relevant:

IE6 is still widely used and is unable to resize the fonts defined in px. => Usability issues. That alone is a no-no.

and

IE 7 and 8 don't resize text sized with pixels either, actually. They do have page zoom, but some people prefer to incease text size only.

Here's a summary of what's good and bad about font sizing in general.

Font size in css http://easycaptures.com/fs/uploaded/213/2470522253.png

I personally like ems. Others, like Chris Coyier over at CSS-Tricks.com likes pixels. (Chris has an excellent article on the different font units).

It really comes down to personal preference.

Almost similar or related questions on SO

Should we still use em and % for defining the font-size of the website elements?

Is there really any point to using relative font sizing in CSS?

Why em instead of px?

Font size in CSS - % or em?

CSS font size: relative vs. absolute values. Which to use?

Problem with EM

Using relative instead of fixed size in CSS

Helpful online tool for px to em

http://pxtoem.com/

http://riddle.pl/emcalc/

http://convert-to.com/pixels-px-to-em-conversion.html

Convert entire site from px to em (This tool is still in development)

http://converter.elementagency.com/

EM Calculator AIR application (will work on all os)

http://jameswhittaker.com/journal/em-based-layouts-vertical-rhythm-calculator/

http://jameswhittaker.com/projects/apps/em-calculator-air-application/

Windows apps

http://www.thebrightlines.com/2009/11/16/pixem-pixel-to-em-converter/

http://www.storkas.com/Projects.aspx(go at bottom)

Pixels to Ems Conversion Table for CSS

http://jontangerine.com/silo/css/pixels-to-ems/

http://reeddesign.co.uk/test/points-pixels.html

emchart

http://aloestudios.com/tools/emchart/

http://aloestudios.com/code/emchart/

Some more articles on this issue

http://www.d.umn.edu/itss/support/Training/Online/webdesign/type.html

---

Related Topics