I am a visual designer, working on an android design and I"m trying to spec my PSD file for our engineers. I cannot seem to find any documentation regarding the conversion of point size to SP for the type in any Android documentation. (Just that SP should be used for type).
The problem is that it depends on the density. Really, they're not good measurements to try to compare.
Points: There are 12 points in a pica, 6 picas per inch, so 72 (more accurately 72.27) points per inch.
Device-Independent Pixels (DP): These will be equal to the pixel size for MDPI displays, 1.5x the pixel size for HDPI displays, and 2x the pixel size for XHDPI displays. (e.g. 12dp = 12px MDPI, 18px HDPI, 24px XHDPI).
Scaled Pixels: These will be equivalent to the DP value, but scaled according to the user preference to be smaller or larger.
If you're designing at 72 dpi (Photoshop default DPI setting), an 8pt font would be equivalent to 8px, which would be 8px at MDPI, 12px at HDPI, and 16px at XHDPI, or more simply 8dp for all densities. I don't know how much scaling gets applied to different SP settings, so you'd have to hunt that out, but basically I would just give them the mockup and let them size it appropriately from there -- surely they can get it pretty close visually from that.
In contrast to dp (and sp with minus the user text sizing factor), pt has pretty much the exact same physical measurement. Dp is more or less a rough approximation, since it uses the same factor for a wide dpi range.
You cannot convert pt to sp, like said by Flavio. You can, however convert pt to dp roughly (+/- 30% in extreme cases, but at least expect +/-10%).
Using the dpi buckets (ldp=120,mdpi=160,hdpi=240,xhdpi=320) the most generic conversion factor would be x0.45 (= 72/120*0.75 = 72/160*1 = 72/240*1,5 = 72/320*2) if using the exact dpi bucket values.
For more precise factors:
mdpi (scaling factor: 1.0) 10.1" WXGA Screen (149dpi) is 0.483076923 (= 72/149 * 1.0)
hdpi (scaling factor: 1.5) Nexus 7 (216dpi) is 0.5 (= 72/216 * 1.5)
xhdpi (scaling factor: 2.0) Nexus 10 (300dpi) is 0.48 (= 72/300 * 2)
So 12 pt would be on...
10.1" WXGA: 24.84dp
Nexus 7: 24 dp
Nexus 10: 25dp
dpi bucket value: 26.666dp
You could use the same values for sp, but keep in mind, that these could be in/decreased by the users settings.
There's no direct mapping between pixels and sp, since sps are dynamically set as the users change the device font size in system settings. The user may want to see all the app fonts in smaller or larger sizes. It's an accessibility feature provided by the OS.
^What Flavio said. but check out the display metrics class overview on the Android Developers site. You might find what you need here... http://developer.android.com/reference/android/util/DisplayMetrics.html#
This is a great tool to help convert between the various measurements - put in what you know and it'll calculate the rest!
http://angrytools.com/android/pixelcalc/
There are 72 pts per inch, and 160 sp per inch (with standard font size in the device settings). this means there are 160sp per 72pts. 160sp/72pts simplifies to 20/9. So when converting pts to sp or dp use pts*20/9. As mentioned by others here already, sp does vary by the user's settings so if you don't want the text size to change with the device settings, then use dp.
Related
I am a visual designer, working on an android design and I"m trying to spec my PSD file for our engineers. I cannot seem to find any documentation regarding the conversion of point size to SP for the type in any Android documentation. (Just that SP should be used for type).
The problem is that it depends on the density. Really, they're not good measurements to try to compare.
Points: There are 12 points in a pica, 6 picas per inch, so 72 (more accurately 72.27) points per inch.
Device-Independent Pixels (DP): These will be equal to the pixel size for MDPI displays, 1.5x the pixel size for HDPI displays, and 2x the pixel size for XHDPI displays. (e.g. 12dp = 12px MDPI, 18px HDPI, 24px XHDPI).
Scaled Pixels: These will be equivalent to the DP value, but scaled according to the user preference to be smaller or larger.
If you're designing at 72 dpi (Photoshop default DPI setting), an 8pt font would be equivalent to 8px, which would be 8px at MDPI, 12px at HDPI, and 16px at XHDPI, or more simply 8dp for all densities. I don't know how much scaling gets applied to different SP settings, so you'd have to hunt that out, but basically I would just give them the mockup and let them size it appropriately from there -- surely they can get it pretty close visually from that.
In contrast to dp (and sp with minus the user text sizing factor), pt has pretty much the exact same physical measurement. Dp is more or less a rough approximation, since it uses the same factor for a wide dpi range.
You cannot convert pt to sp, like said by Flavio. You can, however convert pt to dp roughly (+/- 30% in extreme cases, but at least expect +/-10%).
Using the dpi buckets (ldp=120,mdpi=160,hdpi=240,xhdpi=320) the most generic conversion factor would be x0.45 (= 72/120*0.75 = 72/160*1 = 72/240*1,5 = 72/320*2) if using the exact dpi bucket values.
For more precise factors:
mdpi (scaling factor: 1.0) 10.1" WXGA Screen (149dpi) is 0.483076923 (= 72/149 * 1.0)
hdpi (scaling factor: 1.5) Nexus 7 (216dpi) is 0.5 (= 72/216 * 1.5)
xhdpi (scaling factor: 2.0) Nexus 10 (300dpi) is 0.48 (= 72/300 * 2)
So 12 pt would be on...
10.1" WXGA: 24.84dp
Nexus 7: 24 dp
Nexus 10: 25dp
dpi bucket value: 26.666dp
You could use the same values for sp, but keep in mind, that these could be in/decreased by the users settings.
There's no direct mapping between pixels and sp, since sps are dynamically set as the users change the device font size in system settings. The user may want to see all the app fonts in smaller or larger sizes. It's an accessibility feature provided by the OS.
^What Flavio said. but check out the display metrics class overview on the Android Developers site. You might find what you need here... http://developer.android.com/reference/android/util/DisplayMetrics.html#
This is a great tool to help convert between the various measurements - put in what you know and it'll calculate the rest!
http://angrytools.com/android/pixelcalc/
There are 72 pts per inch, and 160 sp per inch (with standard font size in the device settings). this means there are 160sp per 72pts. 160sp/72pts simplifies to 20/9. So when converting pts to sp or dp use pts*20/9. As mentioned by others here already, sp does vary by the user's settings so if you don't want the text size to change with the device settings, then use dp.
I'm trying to figure out what the minimum screen size (dp) I should design my Android app for.
According to the developer guide small screens are at least 320 x 426 dp.
The page about metrics and grids states that "On average, 48dp translate to a physical size of about 9mm". However, if the density bucket closest to the actual device density would be chosen, 48 dp would translate to 7.62 mm on average (i.e. 48 px # 160 dpi). This made me wonder if generally the next higher density bucket might be applied, to ensure targets are large enough.
In this answer it is stated that manufacturers have some flexibility when choosing the density bucket, but not too much.
My own phone has a 4" 480 x 800 screen (233 dpi), which would mean its density bucket should be 240 dpi (HDPI) with a scale factor of 1.5. Its actual scale factor is 2.0, which means that targets are larger (10.5 mm) and its UI width smaller (240 dp). This is below the "small screen" size bucket.
I've made a spreadsheet to determine density buckets (and corresponding scale factor) and resulting dp sizes for a range of common screen sizes and resolutions. I've done this both based on the closest density bucket, as well as for the next higher density bucket.
When using the closest density, the minimum available screen width would be 320 dp (even with small 3" screens). When using the next higher density, the minimum available width would be only 240 dp (even with 4.5" 720p screens).
The app is intended for a very specific customer base and very small devices (< 4") would not be usable anyway. However, given my observations above, would it be safe to use 320 dp as minimum width in my designs?
I've gathered some other devices from my colleagues, seems that typically items are larger than I'd expect given their densities (just like on my own device). So it seems it is the first bucket > actual density.
I think I will design for 320 dp and use an in-app scaling feature to ensure text and buttons can be sized according to the wishes of the user. 240 dp would probably be too narrow to be usable while the somewhat smaller target size # 320 dp would probably be more acceptable.
I'm asking this question after much reading. I've always heard that dpi is for printers, but when it comes to screen now, they are also talking about dpi. Are they referring to ppi?
Now, what is really resolution, for me its the the number of pixels each dimension can display, e.g. 800x600 means 800 pixesl on width and 600 pixels on the height, but at some places I'm seeing that they are referring to resolution as dpi.
I'm trying to understand this concept well because its very important in Android, like in this article,
For example, say an icon is intended to be 0.5x0.5 in when rendered on a screen. Next, the image must be created at the largest density supported, or as a scalable vector graphic. Best practice is to support the maximum density, which currently is xxhdpi at 480 dpi. At 480 dpi, a 0.5x0.5 in image converts to 240x240 px.
So it is referring dpi as ppi actually if I understand?
So far what I've understood is that different pixels may render different number of pixels. This is why we don't use pixels as measurement unit. Instead we use dp, where a dp is one pixel on 160 dpi device (again the confusion about dpi & ppi)
Can someone clear this big confusion or direct me to an article that may clear it
Mate, Resolution being 800 X 600 implies that the screen has 480,000 pixel points that will be used to render the screen(This is often confused with the dimensions of the display). DPI or PPI means dots/points per inch, this is the measure of the density of the screen.
So just given the Resolution, one can not determine the actual length of the display unless the density parameter is also available. So a 800 X 600 resolution has 480,000 Pixel points & a let this device has a density of 480 dpi.
So the Width of the screen
= No of pixel points along its width/Density
= 800/480
= 1.67 inches
Similarly,
Height = 600/480
=1.25 inches
and if 800X600 resolution device has density of 160 dpi, its dimensions will vary drastically. Following calculations calculate Height/Width of 800X600 on 160 dpi. Compare these two values with above 480 dpi calculations.
the Width of the screen
= No of pixel points along its width/Density
= 800/160
= 5.0 inches
Similarly,
Height = 600/160
=3.75 inches
This is the very reason that scaling images to best fit the screen is such a complex issue on frafmented android environment.However, I love android!
Hope this helps!
and any one who has some thing to add/delete.modify to this answer is most welcome.
dpi (dots per inch) == ppi (pixels per inch)
You are also talking about the DisplayMetrics.density, which gives you the multiplier for the dp unit of measurement.
There's also DisplayMetrics.scaledDensity which also takes into account text size user chose.
To put it plainly, dp unit is intended to give you some security about size of your objects on screen. 160dp should represent one inch on any screen. In order to achieve that, you have to multiply your dimension by DisplayMetrics.density or DisplayMetrics.scaledDensity.
That is, if you're doing that in code. For Layouts, you can just enter a View's dimensions in dp and have Android framework take care of that for you.
How do I know how much DPIs a device has (and thus if it's ldpi / mdpi / hdpi / xhdpi, - and screen size, which is also measured in dp - xlarge / large / normal / small - according to http://developer.android.com/guide/practices/screens_support.html)?
I know the device's resolution and diagonal size, for example:
Display TFT LCD, 3.5 in (89 mm) diagonal.
320×480 px HVGA with Gorilla Glass
16M colors
(Taken from http://en.wikipedia.org/wiki/Samsung_Galaxy_Ace)
Don't need it programmatically, just to calculate myself.
Use DPI calculator to calculate dpis, and Figure 1 in the dev docs to determine whether its ldpi, mdpi, etc.
I think DPI reffers to printers... IN your case DPI = PPI. Please correct me if i'm wrong [edit: I'm wrong :P]
'So a 1200 dpi printer uses 1200 dots of ink in every inch to make up the colours. If you were printing a 300 PPI image, then every pixel would be made up of 16 smaller ink dots (1200 DPI x 1200 DPI / 300 PPI x 300 PPI). A lower DPI would have fewer ink dots making up each pixel, which would make the colour look worse. A higher DPI would have more ink dots for each pixel and should give more accurate colour (especially under close examination).'
im throughoutly confused by dips on Android.
I understand from the reference that the base for dp values is 160.
So, shouldn't 80dp in width equals a view with a width of 50% of the screen ?
On my Nexus One the width in dp is something around 300dp as it seems.
What am i missing here ?
thx in advance
"dp" == "Density-independent Pixels" (This is also why it was earlier called "dip", though I prefer to use "dp" these days.)
Think of it like other units -- "in" (inches), "mm" (millimeters), etc. It allows you to provide a size that is scaled based on the density of the screen.
We define mdpi to be the base density, so "10dp" on an mdpi screen will result in exactly 10 pixels. On an hdpi screen it will result in 15 pixels, because hdpi is 1.5*mdpi.
Note that though the constants for various densities are similar to DPI (mdpi is 160, etc), density is not exactly DPI. It is an abstract scaling factor that adjusts for screen dpi, but does not try to exactly reflect it. (You would use "in", "mm", etc for exact sizes but 99.9% that is not what you want so stick with "dp".) This greatly simplifies life for everyone because you don't need to deal with many Android devices having a slightly different amount of space for its UI because they each of slight different screen DPIs. Also, device manufacturers can select the density of their device to achieve a desired UI -- for example the Samsung Tab uses a density that is a fair amount larger than the actual DPI, resulting in an overall larger UI.
160 dots per inch. So 80dp would be 1/2 an inch, roughly.
I don't understand your question completely but I suggest you take a look at this, if you haven't already.
http://developer.android.com/guide/practices/screens_support.html
pixels = dps * (density / 160)
Density independent pixels (short: dp) are a virtual pixel unit that will be determined at the runtime of your application.
Formala:
1 dp = 1 Pixel on 160 dpi screen.
So 160 dpi is the baseline density for the system.
The conversion of dp units to screen pixels are quite simple.
Actual device pixels (px) = dp (1) * (dpi (of the device) / 160(baseline) )
For the sake of simplicity: px = dp * (dpi / 160)
Example:
If a 240 dpi device starts your app, then 1 dp equals to 1,5 actual device pixels.
Conclusion:
Dp automatically handles any scaling to bigger or smaller devices. The times where you hardcode the pixels are over. DP ensures the proper scaling on different screen densities.