I am not asking what is the difference between dp,sp and px.
I am designing a website based on google's new material design, all the measurements are in dp (for grid) and sp(for text). My question is how do they translate to pixels. I have been designing websites for more than 4 years and all the measurements (grid and font) are in pixels.
For Example:
A headline is 24sp, how many pixels does it equate to? (its not 24px, I've tried matching them, it's around 28px but there has to be a standard measuring systems).
Grid Guideline: "All components align to an 8 dp square baseline grid." - how many pixels does it equate to?
1px = ?dp =?sp on a desktop or any average monitor or mobile device?
I recommend reading Google's definitions of dp and sp, which can be found in the Android docs, here and here.
There's also some helpful information in the wonderful Designer's Guide to DPI.
I think the answer is going to be:
1px = 1dp = 1sp on any average monitor or mobile device.
How did I come up with this?
Because a pixel is a pixel, for andriod dp and sp are used because they are used for native apps which have to scale and the dpi of each screen is different based on device. For desktops all of this is same, off course the website has to be compatible/responsive for mobile devices but since the website loads in a browser, some additional media quires (based on guidelines) will do the job.
If anybody has some other logical conclusion, please share
A safe rule of thumb is to use 1 px = 1 dp.
This should give you a good safe size on just about any device. It will appear a bit large on some devices, notably the iPad (regular).
Here's why:
"A dp corresponds to the physical size of a pixel at 160 dpi" (https://developer.android.com/training/multiscreen/screendensities.html#TaskUseD)
160 dpi means:
160 dots = 1 inch
Therefore:
160 dp = 1 inch (25.4 mm)
So when Google recommends that buttons have a touchable target height of 48 dp, they're saying that they need to be 0.3 inches (7.6 mm) tall.
So how many px is this? Well, that depends on the device.
Examples for 48 dp (7.6 mm) button height:
iPad mini: 48 px Why: The iPad mini screen is about 120 mm wide and uses 768 px to fill that space. You therefore need 162 px to take up an inch (25.4 mm), or 48 px for your button height of 7.6 mm.
Kindle Fire (7"): 43 px
Kindle Fire (6"): 50 px
iPhone: 48 px
Nexus 7: 48 px
Regular iPad: 39 px
(I may have fudged the rounding up/down a tiny bit.. I like 48 better than 49!)
Screen mm and CSS px width for examples: I calculated the screen width using the CSS px screen dimensions and diagonal length.
iPad mini: 1024 x 768 resolution and 201 mm diagonal = 120 mm width.
Kindle Fire 7": 858 x 533 resolution and 178 mm diagonal = 94 mm width.
Kindle Fire 6": 853 x 533 resolution and 152 mm diagonal = 81 mm width.
iPhone: 568 x 320 resolution and 102 mm diagonal = 50 mm width.
Nexus 7: 960 * 600 resolution and 178 mm diagonal = 94 mm width.
iPad regular: 1024 x 768 resolution and 246 mm diagonal = 148 mm width.
Note that for calculating the px height of the button you need to use the device CSS px dimensions. These numbers are not necessarily the same as the resolutions stated in the specs.
All are roughly equivalent for most use cases.
Source
To preserve the visible size of your UI on screens with different densities, you must design your UI using density-independent pixels (dp) as your unit of measurement. One dp is a virtual pixel unit that's roughly equal to one pixel on a medium-density screen (160dpi; the "baseline" density). Android translates this value to the appropriate number of real pixels for each other density.
For example, consider the two devices in figure 1. If you were to define a view to be "100px" wide, it will appear much larger on the device on the left. So you must instead use "100dp" to ensure it appears the same size on both screens.
When defining text sizes, however, you should instead use scalable pixels (sp) as your units (but never use sp for layout sizes). The sp unit is the same size as dp, by default, but it resizes based on the user's preferred text size.
Figure 1. Two screens of the same size may have a different number of pixels
Related
there are 160 units per inch.
2.If I created an Photoshop file that are 72 dpi then there will be 72 points per inch.
3.If the element is 88px height in Photoshop then what I have to set it in xamarin?
If the phone is 360dpi then the height in xamarin should be :88 / 72 * 160 / 2?
but it is not right.
I know the units in each platfform and I only want to know how to get units from pixels
You could use Xamarin.Essentials to get the Screen density as follows:
// Get Metrics
var mainDisplayInfo = DeviceDisplay.MainDisplayInfo;
// Screen density
var density = mainDisplayInfo.Density;
If the density is 3 in iOS device and pixels is 88 , then there are 88/3 units in iOS.
If the phone is 360dpi
That means it shoule be a Android device, and screen density also can be calculated by 360/160 = 2.25. Then there are 88/2.25 units to set for HeightRequest.
================================Update==============================
If there is a BoxView in Xaml as follows:
<BoxView x:Name="MyBoxView" BackgroundColor="CadetBlue" HorizontalOptions="Fill"/>
And the effect:
Now I will print the MyBoxView.Width. the result is:
Console.WriteLine("++++MyBoxView++++" + MyBoxView.Width);
++++MyBoxView++++411.428571428571
If you use var density = mainDisplayInfo.Density; to get density, you will get Screen Density::2.625. (My device is Piexl_2_pie_9_0 api 28 emulator)
You know the size of screen width is 1080 pixels, however the width is 411.428571428571. That should means units of WidthRequest.
And if you put 411.428571428571 * 2.625 , you will get 1080 pixels.
It sounds simple but how is the fontsize, which can be set with setPointSize defined in Qt4? A point is 1/72 inch but if I compare to
glyph metrics from FreeType
Is it the max_advance_height, the advance between two lines or the distance between the highest and lowest point (the maximum ascender - descender)?
If I create a QLabel and setPointSize to 75 I get the following result:
My screen has 96x96 dpi which should result in 75/72*96 = 100 pixels. But measured the B, for example is 70 pixels in height.
In css w3(here),
1px = 0.75pt, 1pt = 2.54/72 cm, so 1 css pixel:1px = 0.26mm
for example, the CSS pixel of iPhone4 is 320px * 480px(not device pixel),
so in width ,the length should be:
320 *0.26 = 83.2mm
but the iPhone4 is 3.5"，so the length in width is about 60mm,
it dont match the result i calculated above
where is wrong?
thanks
The physical unit is based on 96dpi, therefore 1in in css is 96px, so 3.5in = 336px. Here's a blog post which can explain this: http://www.quirksmode.org/blog/archives/2012/11/the_css_physica.html but it's also mentioned in the W3 spec you posted if you scroll down a bit.
The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length.
A CSS pixel is not always 0.26mm
From CSS W3:
The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm's length, 1px thus corresponds to about 0.26 mm (1/96 inch).
The iPhone4 is not 96dpi. With a device pixel ratio of 2, its "CSS dpi" is around 163. Since 96dpi devices render 320px at 83.2mm, mathematically, 163dpi devices should render 320px at 49mm.
There is a similar question here whose answer in essence says:
The height - specifically from the top of the ascenders (e.g., 'h' or 'l' (el)) to the bottom of the descenders (e.g., 'g' or 'y')
This has also been my experiance. I.e. in 14px Arial the height of the letter K (the baseline height) is about 10px.
The specs say nothing about the calculated font-size so I'm guessing this is browser-specific, but I could not find any reference to it.
(Other questions here and here ask roughly the same thing but sadly no answer gives a satisfying explanation..)
Is there any documentation on why the font-size seems to be the size "from ascenders to descendes"?
Some background on the subject
Back when letters were created on metal, the em referred to the size of each block that the letter would be engraved on, and that size was determined by the capital M because it usually takes up the most space.
Now a days, font developers create their fonts on a computer without the limitations of a physical piece of metal so while the em still exists, its nothing more than an imaginary boundary in the software; thus prone to being manipulated or disregarded altogether.
Standards
In an OpenType font, the em size is supposed to be set to 1000 units. And in TrueType fonts, the em size is usually either 1024 or 2048.
The most accurate way to define a font style is to use EM that way when you define a font-size for use, the dimension does not refer to the pixel height of the font, but to the fonts x height which is determined by the distance between the baseline and the mean line of the font.
For the record 1 PT is about 0.35136mm. And PX is 1 "dot" on your screen which is defined by the dots per square inch or resolution of your screen and thus different from screen to screen and is the worst way to define a font size.
Unit conversion
This is a pretty good read if you enjoy literature that makes your eyes bleed like me.. International unification of typopgrahic measurements
1 point (Truchet) | 0.188 mm
1 point (Didot) | 0.376 mm or 1/72 of a French royal inch
1 point (ATA) | 0.3514598 mm or 0.013837 inch
1 point (TeX) | 0.3514598035 mm or 1/72.27 inch
1 point (Postscript) | 0.3527777778 mm or 1/72 inch
1 point (l’Imprimerie nationale, IN) | 0.4 mm
1 pica (ATA) | 4.2175176 mm = 12 points (ATA)
1 pica (TeX) | 4.217517642 mm = 12 points (TeX)
1 pica (Postscript) | 4.233333333 mm = 12 points (Postscript)
1 cicero | 4.531 mm = 12 points (Didot)
Resolutions
µm : 10.0 20.0 21.2 40.0 42.3 80.0 84.7 100.0 250.0 254.0
dpi : 2540 1270 1200 635 600 317 300 254 102 100
Standards are only worth so much..
The actual size of one fonts glyphs vs another font are always going vary dependent on:
how the developer designed the font glyphs when creating the font,
and how the browser renders those characters. No two browsers are going to be exactly the same.
the resolution and ppi of the screen viewing the font.
Example
As an example of how common it is for font developers to manipulate the geometry.. Back when Apple created the Zapfino script font, they sized it relative to the largest capitals in the font as would be expected but then they decided that the lowercase letters looked too small so a few years later they revised it so that any given point size was about 4x larger than other fonts.
If you don't have a headache, read some more..
There's some good information on Wikipedia about modern typography and origins; and other relevant subjects.
Point (typography)
Pixels per inch
Font metrics
Typographic units
And some first-hand experience
If you want to get more first-hand understanding you can download the free font development tool FontForge which is comparable to the non-free FontLab Studio (either of these two being the popular choice among font developers in my experience). Both also have active communities so you can find plenty of support when learning how to use them.
Fontlab Studio
Fontlab Fontographer
FontForge
Fontlab Wikibook
FontForge Documentation
The answer regarding typesetting is excellent, but be aware css diverges from traditional typography in many cases.
In css the font-size determines the height of the "em-box". The em-box is a bounding box which can contain all letters of the font including ascenders and descenders. Informally you can think of font-size as the "j"-height, since a lower case j has both ascender and descender and therefore (in most fonts) uses the full em-box height.
This means most letters (like a capital M) will have space above and below in the em-box. The relative amount of space above and below a capital letter will vary between fonts, since some fonts have relatively larger or smaller ascenders and descenders. This is part of what stylistically sets fonts apart for each others.
You ask why font-size is including ascenders and descenders, ie. why it correspond to the height of the em-box, even though the height of most letters will be less than this. Well, since most texts do includes letters with ascenders and descenders, the em-box height indicates how much vertical space the text require (at minimum), which is quite useful!
An caveat: Some glyphs may even extend beyond the em-box in some fonts. For example the letter "Å" often extend above the em-box. This is a stylistic choice by the designer of the font.
I've experimented to pin down exactly what the font-size corresponds to in terms of font-metrics (as shown in the diagram in davidcondrey's answer).
Testing on Safari, Chrome and Firefox on macOS, setting font-size to 100px seems to set the apparent size of difference between the ascender line and descender line to 100px.
Unfortunately, there's multiple meanings for the ascender and descender when talking about different font formats, so to disambiguate in the case of OpenType, we're talking about the 'Typo Ascender' and the 'Typo Descender' from the OS/2 table.
OpenType CSS font-height diagram
An interactive illustration is available on the opentype.js glyph inspector https://opentype.js.org/glyph-inspector.html
When positioning the character (again in terms of OpenType metrics), browsers seem to consider y = 0 to be the Ascender, (which is not the same as the 'ascender line' in davidcondrey's diagram, but instead it's the ascender in the hhea table in OpenType). However, if CSS line-height is not set to normal, the position is offset by some amount but I think the rules here might be a bit more complex.
I expect there's more that factors in and it may be different between operating systems and browsers, however this is at least a good approximation.
After searching for a satisfying answer to a similar question, I found this graphic to be a lot of help...
http://static.splashnology.com/articles/Choosing-the-Best-Units/font-units-large.png
Does ImageResizer.Net for asp.net have any method by which we can know the resolution of any uploaded Image. I know one method:
ImageResizer.ImageBuilder.LoadImageInfo (object source, IEnumerable< string > requestedInfo )
that gives me Height, Width, Mimetype & extension of image file, but I have a requirement where I need to validate the resolution of an uploaded image.
As far as I know dpi is something what connected to devices where images will be rendered.
So, if it is Desktop dpi can be or 72 (MAC) or 96 (Windows), but if you will print it dpi can be 150 or 300.
So to check if image will be correctly printed (with good quality) on paper with size 200x200 milimeters you can calculate min size if image you need in pixels.
So, we have the following input:
- dpi of printing is 150
- size of paper is 200x200 milimeters
200 mm is 7.9 inch
=> min resolution of image should be 7.9*150 = 1185 pixels
So only images with height and width equal or more than 1185 will be printed with good quality.
So question for you - what for you need resolution(dpi) check?
As far as you have Height and Width you can calculate DPI using this formula:
dp = sqrt(width^2 + height^2) (Pythagorean theorem)
then, you should know size of the screen in inches (di). Simply:
dpi = dp / di