If I specify the width of a <div> tag using CSS as 96px, how many device pixels should that occupy on the screen of a first generation iPhone?
I added <meta name="viewport" content="initial-scale=1.0, maximum-scale=1.0, user-scalable=no"/> to the page, took a screenshot on the simulator, and measured the div to be 96 device pixels wide. Now, I read the W3 spec for CSS pixels and it states that 1px is 1/96th of an inch. So 96 CSS pixels should translate to 1 inch. Since the original iPhone has a DPI of 163, one inch on the screen should occupy 163 device pixels. Why am I not getting that measurement? In other words, should 96 CSS pixels be equal to 1 inch?
I saw that the spec also mentions anchoring to a reference pixel. It seems to me that the reference pixel is simply a device pixel in this case. If I was to work backwards to get the CSS pixel values from a screenshot, would it generally be correct to assume that one device pixel equals one CSS pixel on the iPhone (non-retina display)?
Iphone pixels are like any other pixel. A 96px wide <div> is always 96px wide in any device. DPI (Dots Per Inch) just tell you the ratio between physical pixels (dots) on a screen (or paper) and inches and don't represent any size. DPI are only a ratio between pixels and a real world unit of measurement.
A 96px div would look 6x bigger in a 50 DPI screen than a 300 DPI screen.
DPI vary depending on the device or print/scan quality, therefore 1 inch is NOT always equal to 96 pixels. W3C is just saying that the absolute length units are fixed in relation to each other (it is just an arbitrary approximation to make CSS units consistent). This does not mean that real world units of measurement (inches, cm) can be given a fixed ratio to pixels.
The best help i can give you to understand this is that 1px is only and always equal to 1px. Any comparison between pixels and real world units depends on the DPI of a specific device, not on a standard like the W3C.
The absolute length units are fixed in relation to each other and
anchored to some physical measurement. They are mainly useful when the
output environment is known.
Related
I want to use srcset to provide 2x images for iPhone and iPad, but the 2x descriptor applies to both and the images should be different.
On both devices the image is full width. But on iPhone 2x of 320w is 640w and on iPad Pro 2x of 1024 is 2048w.
How could I differentiate between the two?
The x descriptor is more suited to images which width is fixed across viewports.
For variable width images, you should use the w descriptor.
For example:
<img
src="image320.jpg"
srcset="image320.jpg 320w, image640.jpg 640w, image960.jpg 960vw, image1280.jpg 1280vw, image1600.jpg 1600vw, image1920.jpg 1920vw, image2240.jpg 2240vw, image2560.jpg 2560vw"
sizes="100vw">
The w descriptor applies the screen density factor to the CSS width of the image to get the actual image width to download.
The image1920.jpg image will be downloaded by the browser for several configurations:
screen density 1 with viewport width equal to or below 1920px
screen density 2 with viewport width equal to or below 960px
screen density 3 with viewport width equal to or below 640px
etc.
I have read a lot about BMP file format structure but I still cannot get what is the real meaning of the fields "biXPelsPermeter" and "biYPelsPermeter". I mean in practical way, how is it used or how it can be utilized. Any example or experience? Thanks a lot
biXPelsPermeter
Specifies the horizontal print resolution, in pixels per meter, of the target device for the bitmap.
biYPelsPermeter
Specifies the vertical print resolution.
Its not very important. You can leave them on 2835 its not going to ruin the image.
(72 DPI × 39.3701 inches per meter yields 2834.6472)
Think of it this way: The image bits within the BMP structure define the shape of the image using that much data (that much information describes the image), but that information must then be translated to a target device using a measuring system to indicate its applied resolution in practical use.
For example, if the BMP is 10,000 pixels wide, and 4,000 pixels high, that explains how much raw detail exists within the image bits. However, that image information must then be applied to some target. It uses the relationship to the dpi and its target to derive the applied resolution.
If it were printed at 1000 dpi then it's only going to give you an image with 10" x 4" but one with extremely high detail to the naked eye (more pixels per square inch). By contrast, if it's printed at only 100 dpi, then you'll get an image that's 100" x 40" with low detail (fewer pixels per square inch), but both of them have the same overall number of bits within. You can actually scale an image without scaling any of its internal image data by merely changing the dpi to non-standard values.
Also, using 72 dpi is a throwback to ancient printing techniques (https://en.wikipedia.org/wiki/Twip) which are not really relevant in moving forward (except to maintain compatibility with standards) as modern hardware devices often use other values for their fundamental relationships to image data. For video screens, for example, Macs use 72 dpi as the default. Windows uses 96 dpi. Others are similar. In theory you can set it to whatever you want, but be warned that not all software honors the internal settings and will instead assume a particular size. This can affect the way images are scaled within the app, even though the actual image data within hasn't changed.
#media only screen and (max-device-width:480px),
only screen and (-webkit-min-device-pixel-ratio: 2)
{ /*iphone css*/ }
max-device width makes sense but pixel ratio doesn't make any sense to me. thanks.
From http://developer.android.com/reference/android/webkit/WebView.html
The -webkit-device-pixel-ratio CSS media query. Use this to specify
the screen densities for which this style sheet is to be used. The
corresponding value should be either "0.75", "1", or "1.5", to
indicate that the styles are for devices with low density, medium
density, or high density screens, respectively. For example: The hdpi.css stylesheet is only used for devices
with a screen pixel ration of 1.5, which is the high density pixel
ratio.
And according to https://developer.mozilla.org/en/CSS/Media_queries
-moz-device-pixel-ratio
Gives the number of device pixels per CSS pixel.
Note: This media feature is also implemented by Webkit as
-webkit-device-pixel-ratio. The min and max prefixes as implemented by Gecko are named min--moz-device-pixel-ratio and
max--moz-device-pixel-ratio; but the same prefixes as implemented by
Webkit are named -webkit-min-device-pixel-ratio and
-webkit-max-device-pixel-ratio.
I've gotten some graphics files for buttons etc. from the designer. Most of the retina files have one or both dimensions odd, like 29 x 30 or 79 x 61, and then the dimensions of the corresponding non-retina files will be 15 x 15 or 39 x 31, for example. The dimensions of the UIImageView s that hold each image exactly match the size of the non-retina files they hold, so on a non-retina phone there is no distortion and everything looks fine.
On a retina phone, these images (icons and such) only look fine when the images happen to be even dimensions (like 30 x 30 or 46 x 80); when there's an odd dimension to the image, it gets distorted slightly.
Should the pixel dimensions of a retina image always be twice the size of the non-retina dimensions, and of the dimensions of the frame that displays it?
As the name (#2X) implies, it is indeed assumed that the retina-version is exactly twice the size of the non-retina version. Otherwise, as you have seen, there might be distortions.
On a side note, this has only indirectly to do with the displaying frame, e.g. think of scrollviews.
Ask your designer to always design the UI (not necessarily the components themselves) for the non-retina version first, and then just double up the sizes for the retina version. This way, you won't run into distortion-problems. If he designs for retina-first and then scales all components back to half their sizes, he will likely end up with odd dimensions.
Oh, and give your designer this link:
http://www.smashingmagazine.com/2010/11/17/designing-for-iphone-4-retina-display-techniques-and-workflow/
Yes, image files that have #2x appended should be exactly double the size of the 'non'-retina image. Thus should only have even dimensions.
It would appear so.
When you create a view which is 30 points by 30 points on a regular display the backing store (the data that gets drawn on the screen) will be created 30 pixels by 30 pixels.
On a retina display that backing store is simply multiplied by a scale factor. Currently that scale factor is 2 for iPhone 4 and iPhone 4s. This means that the backing stores on retina displays will always be a multiple of 2.
Your 30 point by 30 point view would have a 60 pixel by 60 pixel backing store. If your images aren't drawn properly for retina displays it would seem that the #2x image needs to be the full size of the backing store, and hence exactly double the size of the view in points.
I created a 8.5x11.0 inches image # a 300dpi setting in photoshop.
When i go to use this as a background image in report designer the image looks hugeee.
It's not fitting within the 8.5x11.0 page.
Is there a way to resize this image correctly so that it will fit correctly within a 8.5x11.0 letter size page?
Thanks in advance,
with the information you gave, i believe your problem is problably in the group Size/dpi
You saved an image of size 8,5 x 11 inches # 300 Dpi (dots per inch) that calculates to aproximately an image of 2550 x 3300 pixels.
Now if your "report designer" software looks only at the size in pixels and assumes a dpi value diferent then the one you used, say for example 72 dpi, your 2550 x 3300 pixels image would actually be something like 45,8 x 35.4 inches.
So, my advice is, find out what are the characteristics your solftware is especting, aparently it is not 300dpi.
If you can´t find the information, try commonly used dpis like 72dpi or 150dpi.