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.
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 am currently working on a project that involves using the Tess4j Tesseract OCR engine.
While working on this project I come along a lot of websites that state that Tesseract works best on images of at least 300 DPI (Dots per Inch).
My question is why is DPI mentioned so many times for images. I understand that when you scan an object that you want to scan it with at least 300 DPI. I just cannot figure out why this is relevant for pictures taken with a camera.
DPI is as far as I know a property for the printer. Based on this property the higher it is the smaller the image but with greater quality.
Now if DPI has nothing to do with these images than I am wondering why the results on my program differs when I change the DPI property of images between 72 & 300.
Is there a pre-process of Tesseract that I am unaware of?
Actually, it is the text size at a specific DPI.
Is there a Minimum Text Size? (It won't read screen text!)
There is a minimum text size for reasonable accuracy. You have to
consider resolution as well as point size. Accuracy drops off below
10pt x 300dpi, rapidly below 8pt x 300dpi. A quick check is to count
the pixels of the x-height of your characters. (X-height is the height
of the lower case x.) At 10pt x 300dpi x-heights are typically about
20 pixels, although this can vary dramatically from font to font.
Below an x-height of 10 pixels, you have very little chance of
accurate results, and below about 8 pixels, most of the text will be
"noise removed".
https://github.com/tesseract-ocr/tesseract/wiki/FAQ#is-there-a-minimum-text-size-it-wont-read-screen-text
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.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
When building mobile application for Android or iOS we must provide images for several resolutions (mdpi, hdpi, xhdpi..2x, 3x..etc), beacuse mobile devices do have different resolutions...
Why we don't have to do the same task when building responsive web site (provide images for different resolutions) ?
A solution to do this has been proposed some time ago now, as it is a totally relevant use-case.
The answer to your question about "why we don't have to do this" would be, "we do have to do this", as pixel density differs on bigger screens too and especially for responsive pages, there is need to provide different pictures (not just different resolutions) that fit the content better (commonly referred to as art direction based selection).
This is why the <picture> - element (link to w3c HTML spec) exists and has added support for various attributes like media-queries, multiple sources and srcsets for different screen densities, as we use them on mobile pages.
Additionally, srcset and sizes - attributes exist for the <img>-tag as well.
This page (usecases.responsiveimages.org) describes the different use-cases for this.
The "right" approach will always depend on what you want to achieve, but at least offering different resolutions for varying pixel-ratios should be a standard in my opinion.
So these elements and attributes give you tools to select your image based on
device-pixel - ratio
viewport
context (completely different pictures, not just resolution)
image-format
and you should make use of these tools, no matter what device you're targeting.
Note that the browser support for the picture-element is getting better and better, but is not complete now (at the time of this writing, only Chrome and Opera have it fully implemented when it comes to Desktop - Browsers, Firefox has it implemented but still locked behind a flag, this should change with FF 38). There is a fairly well working polyfill though (https://github.com/scottjehl/picturefill)
tl;dr We really should do this, no matter what device and modern browsers give us very competent tools for doing so.
Why we don't have to do the same task when building responsive web site (provide images for different resolutions) ?
Actually we do, its called retina ready design.
Here three things are to be understood.
1. Pixel density
Pixel density is the number of pixels a display can fit into a fixed distance. This is most of the time measured is PPI (Pixel Per Inch)
2. Resolution
Resolution is a simple count of the number of pixels across the entire width and height of a device.
Now, to further explain this concept, lets take an example of two tablets of same dimensions, say 7 inch tablets, both are physically identical in width and height.
Now at a glance these both tablets may seem quite identical, but first one (Tab-A) has a resolution of 320 x 480 while other one (Tab-B) has a resolution of 640 x 960. So These directly affect the PPI.
What this means is that the Tab-B is cramming (displaying) more (double) no of pixels in the same physical dimensions, effectively increasing the PPI.
So if we choose an icon of say 150 x 150px and display it on both the devices, the same icon on Tab-B shall(should) be half the size of the same icon displayed on Tab-A. With this, the user of the Tab-B shall have double the content of what the user of Tab-A has.
This may sound good, but we must remember that the user of Tab-B has everything half the size of what the logo was originally intended to be, so now he has to exert his eyes more, in order to figure out what that logo is about. But thats not the case.
Here enters the Third concept.
3. Viewport
In my own view/understanding (for lack of official def), A viewport is the virtual resolution that your browser renders, irrespective of the native device resolution. This is supposed to solve the problem of "too high resolution making objects too small".
What this does is that, it renders the logo(and every other thing) on Tab-B the same physical size as Tab-A, effectively stretching the graphics.
Now if the graphics were vector then they would scale seamlessly, but if they are images, then they create a shabby/jagged edges making the images look bad.
This is where you need images 2x the resolution.
So, Coming back to your problem, The difference between the viewport of a normal desktop and its native resolution isn't much.
You should not post the question with a (false) answer included:
We don't have to, but we should create and use images with higher resolutions for all devices that may have pixel ratio>1 because it is not rare that those devices display images using much more pixels than it supposed to. Even if the pixel ratio is 1, all browsers have a zoom feature, which also requires high(er) resolution images.
This means that simple image that we define as:
<img src="myimage.jpg" style="width: 200px; height: 100px;" />
may be displayed at 400x200 px or more. Check some common device pixel ratios.
Therefor all the images used should be at least 2x width, 2x display height (which means 4x larger). If possible, for vector images we should use SVG or icon fonts.
We can also target devices by pixel density using CSS media-queries (short article here. Personally, I do not care that much, serving few Kb or Mb more is nothing to current internet speeds (and will mean nothing in years to come).
On a website I made, one person sent me a screenshot which shows that my subtitle font is too large.
I've checked the site on two machines (Vista) with FF, IE6, IE7, IE8, Safari/win, opera/win.
I can increase the font size of the browser, but the subtitle stays the same size (since it is 8pt as shown below) which is what I want (so it doesn't extend under the logo).
It checks out fine on 34 browsers screenshots at http://browsershots.org.
What could be causing the font to be larger on this one person's machine (windows XP, IE7). He says "all other websites look fine". Is there something about Windows XP that enables the operating to change the font size in browsers, etc.? Or perhaps a problem with arial/italic on Windows XP?
Here is the CSS for it:
#subtitle {
position: absolute;
top: 78px;
left: 40px;
width: 738px;
text-align: right;
font-size: 8pt;
font-style: italic;
font-family: arial;
}
ANSWER:
I changed "8pt" to "10px" and it works now for him. I assume that he had changed the DPI on his machine.
You used ‘pt’ as a size unit. Don't do that. The CSS ‘physical units’ (pt, mm, in...) only make sense for physical output (ie. a print stylesheet).
On-screen, points are mapped to pixels using the system's ‘dpi’ setting, which can vary arbitrarily across machines. Macs/Windows/Linux all default differently, and can be reconfigured. Many Windows users increase the dpi setting in order to resize the fixed-point-size system dialog box (shell) font.
If you must use non-relative units for some text, the unit you want is ‘px’.
There are other reasons font sizes can change (eg. different font availability, minimum font size settings, deliberate font zooming), which is why you should never completely rely on them being what you expect, but this is almost certainly the cause in this case.
This is perhaps a stupid question, but has the user inadvertantly changed their browser's font size? In IE6 onwards, holding down CTRL and scrolling the mousewheel forwards/backwards will increase/decrease font sizes.
Three possibilities:
The user has changed their DPI settings for their machine. In some versions of Windows this manifests as changing fonts to "Large" or "Very Large";
The user has changed their default font in their browser (from, say, Tahoma/12 to Tahoma/16 in Firefox); or
The user has disabled CSS/HTML font sizing in their browser. This is an accessibility setting. Some people also use it for when they have, say, 1920x1200 resolution on a 15" laptop and some Web weenie has set font sizes on their Website to 8 pixels high.
Sorry, bobince and Diogenes, but I must disagree with you in the strongest way possible in regard to not using pt sizes and always using pixels:
A designer wanting a font size to be relative to the default size specified in browser or OS settings, which should be the standard, should use % or em. A designer wanting an absolute size (on screen) should use pt to keep the font size constant regardless of the screen's DPI setting, and here's why:
Modern laptops and mobile devices' screens have much denser pixels than desktops', up to approximately 150dpi of natural (default) resolution compared to the desktop's 72. Medical and other specialized screens go even higher. And the user has the ability (if not always the knowledge) to raise or lower the logical dpi to customize the display according to his preferences and sight ability.
Any image or text sized in pixels will be too small to read on a dense-dpi device, making your good-sighted users struggle and rendering any users with less than perfect sight unable to read the text. More importantly (and one can argue if this is correct behavior or not), some browsers do not resize pixel-sized text even when the user commands it, making the situation unfixable.
Unlike paper medium, where position to the precision of 100ths of an inch is possible and everyone reading a designer's work sees the same-sized paper, the diversity of devices used to access the Net invalidates the entire concept of pixel-perfect design, which looks good only on the one device it was targeted at. The point of the design on the Web is to make the site accessible to the target audience, which usually should be as large as possible and would be using a range of devices and settings.
Operating systems are already going there with vector UI elements or, at the least, large source bitmaps that are scaled smoothly. So should you, forgetting about the arbitrary unit of measure called "the pixel" and making your designs compatible with the widest array of access devices possible.
Addendum - to additional points raised by Diogenes
Unfortunately, the real-world situation with DPI awareness (and thus with proper support for pt-sized text) in currently popular operating systems is, for the lack of a stronger printable word, a clusterfail, as summarized by the CSS-Discuss Wiki:
Unfortunately, most computers don't know [the display's DPI], so the browsers don't either... In the absence of this knowledge, operating systems and browsers typically just make assumptions, and these assumptions are usually wrong.
So, while in theory points would be the best unit for fixed text, in practice using them today produces inconsistent results in many OS/browser/screen configurations. Thus designers often have to give up and revert to pixels to achieve fixed font sizes. Personally, I use percentages and ems, avoiding fixed sizes altogether.
The CSS-Discuss archives have a great summary of the font sizing issues, and numerous links to details and various approaches.
On IE7 there is a zoom level and a text size. The most likely scenario is that they've changed one of these settings inadvertently. Have them click the "Page" button and look at the "Zoom" and "Text Size" settings.
As 2 other answers have suggested, the DPI settings may be giving you trouble. I have found that mixing pt,ex,em with px sizing can be a real challenge once you consider DPI settings and different browser default fonts.
So now I just use px for font sizes. Most of the problems go away.
P.S. Don't force that single user back to the regular DPI. I willing to bet that they are older, need reading glasses and the new high res monitor they got was harder to read because the print was so small. Someone adjusted the DPI and now the fonts are the same size as the old monitor, so now they really do like the new monitor better. The problem now is some web pages are messed up. That's where you come in.
Another thing you might want to look at when changing monitors from a CRT to flat screen is the digital font smoothing setting. Fuzzy characters become sharper. Fortunately, This does not affect your web pages.
Addendum - to address point raised by MaxVT
MaxVT makes some excellent points in his answer. Context certainly matters.
My answer was a bit lazy and incomplete. The reason I use px is because of the inconsistency across browsers. To my way of thinking, specifying a point size should specify the physical size of the character to the user on the device he is using, but in practice it does not.
For example, suppose you font-family: cursive; font-size: 11pt
In most browsers under windows, this defaults to the much maligned MS-Comic font. IE7 decided to use some other default and that font seems smaller and less readable in the same point size. The same can be said of Arial vs. Verdana fonts. Specify the same point size, and your whole layout changes. Throw in DPI settings on setup and it is chaos.
The dots-per-inch (DPI) setting is a bit of an anachronism. Your monitor or phone has a fixed DPI. You can only change it if you get a new monitor or phone. Having a dialog box to change the DPI is there only because the device does not report to the operating system what the DPI is. It's an imperfect world.
So I leave you with this suggestion - use px for now to specify the font size, but only use it once. Make all other sizes relative to your base font.
Then, when you have to port everything over to the latest BlackBerry or iPod that does a better job of everything, switching from 11px to 11pt will be easy. And test out your software so it does look nice as you boost the font size.