I am trying to render a view to a PrintedPdfDocument. The size of the page, as expected, is in units 1/72nd of an inch. So, for an A0 size page (width = 33.11 in), document.getPageWidth() returns 2384 (33.11 * 72). The page canvas width equates one pixel to one 1/72nd of an inch unit - so, pageCanvas.getWidth() returns 2384. This is true on different devices. So far so good.
The problem I am facing is that on different devices, the generated PDF document for the same view looks different. On some devices it is stretched on the PDF page, and on somes devices it renders as it should.
What could be the issue here? Isn't the generation of the PDF supposed to be device independent? I noticed that pageCanvas.getDensity() is different on different phones. Why does the phone screen density impact the density of the PDF page canvas?
Given that the numerically document.getPageWidth() in 1/72nd of an inch == pageCanvas.getWidth() in pixels, shouldn't pageCanvas.getDensity() always be 72 DPI? On some phones it is 320 (where it shows correctly) and on others it is 420 (where the view is rendered stretched).
A bit stuck here, so would really appreciate any pointers. Thanks in advance!
I found a way to work around this problem.
I still don't know why pageCanvas.getDensity() is set to the display density instead of the density of the PDF Page (72dpi). My guess is that it may be because some views may incorrectly use display metrics of the screen when drawing to a canvas, even when the canvas is not the screen - but this is just my guess.
Regardless of why pageCanvas.getDensity() is set to screen density, the way I worked around it was by computing the page dimensions (which is in dp) using the screen density. So, if I want to draw to an A0 page (which is 33.11 inches wide), I set the width of the page (when creating the PrintedPdfDocument) to 33.11 * 420 = 13906 dp, instead of the recommended 33.11 * 72 = 2384 dp. This way, when the views draw to the canvas that has 420 dpi density, the resultant page is the required 33.11 inches wide.
This is working perfectly and the created PDF page now looks the same regardless of the device where it was created. The only side effect is that Adobe Acrobat thinks the pages are 33.11 * 420 / 72 inches wide instead of 33.11 inches wide. But this doesn't really matter practically, since we can shrink the pages to fit an A0 paper while printing.
What is the difference between pt and px in CSS? Which one should I use and why?
px ≠ Pixels
All of these answers seem to be incorrect. Contrary to intuition, in CSS the px is not pixels. At least, not in the simple physical sense.
Read this article from the W3C, EM, PX, PT, CM, IN…, about how px is a "magical" unit invented for CSS. The meaning of px varies by hardware and resolution. (That article is fresh, last updated 2014-10.)
My own way of thinking about it: 1 px is the size of a thin line intended by a designer to be barely visible.
To quote that article:
The px unit is the magic unit of CSS. It is not related to the current font and also not related to the absolute units. The px unit is defined to be small but visible, and such that a horizontal 1px wide line can be displayed with sharp edges (no anti-aliasing). What is sharp, small and visible depends on the device and the way it is used: do you hold it close to your eyes, like a mobile phone, at arms length, like a computer monitor, or somewhere in between, like a book? The px is thus not defined as a constant length, but as something that depends on the type of device and its typical use.
To get an idea of the appearance of a px, imagine a CRT computer monitor from the 1990s: the smallest dot it can display measures about 1/100th of an inch (0.25mm) or a little more. The px unit got its name from those screen pixels.
Nowadays there are devices that could in principle display smaller sharp dots (although you might need a magnifier to see them). But documents from the last century that used px in CSS still look the same, no matter what the device. Printers, especially, can display sharp lines with much smaller details than 1px, but even on printers, a 1px line looks very much the same as it would look on a computer monitor. Devices change, but the px always has the same visual appearance.
That article gives some guidance about using pt vs px vs em, to answer this Question.
Here you've got a very detailed explanation of their differences
http://kyleschaeffer.com/development/css-font-size-em-vs-px-vs-pt-vs/
The jist of it (from source)
Pixels are fixed-size units that are used in screen media (i.e. to be read on the computer screen). Pixel stands for "picture element" and as you know, one pixel is one little "square" on your screen.
Points are traditionally used in print media (anything that is to be printed on paper, etc.). One point is equal to 1/72 of an inch. Points are much like pixels, in that they are fixed-size units and cannot scale in size.
Have a look at this excellent article at CSS-Tricks:
px – em – % – pt – keyword
Taken from the article:
pt
The final unit of measurement that it is possible to declare font sizes in is point values (pt). Point values are only for print CSS! A point is a unit of measurement used for real-life ink-on-paper typography. 72pts = one inch. One inch = one real-life inch like-on-a-ruler. Not an inch on a screen, which is totally arbitrary based on resolution.
Just like how pixels are dead-accurate on monitors for font-sizing, point sizes are dead-accurate on paper. For the best cross-browser and cross-platform results while printing pages, set up a print stylesheet and size all fonts with point sizes.
For good measure, the reason we don't use point sizes for screen display (other than it being absurd), is that the cross-browser results are drastically different:
px
If you need fine-grained control, sizing fonts in pixel values (px) is an excellent choice (it's my favorite). On a computer screen, it doesn't get any more accurate than a single pixel. With sizing fonts in pixels, you are literally telling browsers to render the letters exactly that number of pixels in height:
Windows, Mac, aliased, anti-aliased, cross-browsers, doesn't matter, a font set at 14px will be 14px tall. But that isn't to say there won't still be some variation. In a quick test below, the results were slightly more consistent than with keywords but not identical:
Due to the nature of pixel values, they do not cascade. If a parent element has an 18px pixel size and the child is 16px, the child will be 16px. However, font-sizing settings can be using in combination. For example, if the parent was set to 16px and the child was set to larger, the child would indeed come out larger than the parent. A quick test showed me this:
"Larger" bumped the 16px of the parent into 20px, a 25% increase.
Pixels have gotten a bad wrap in the past for accessibility and usability concerns. In IE 6 and below, font-sizes set in pixels cannot be resized by the user. That means that us hip young healthy designers can set type in 12px and read it on the screen just fine, but when folks a little longer in the tooth go to bump up the size so they can read it, they are unable to. This is really IE 6's fault, not ours, but we gots what we gots and we have to deal with it.
Setting font-size in pixels is the most accurate (and I find the most satisfying) method, but do take into consideration the number of visitors still using IE 6 on your site and their accessibility needs. We are right on the bleeding edge of not needing to care about this anymore.
A pt is 1/72th of an inch and is a useless measure for anything that is rendered on a device which doesn't calculate the DPI correctly. This makes it a reasonable choice for printing and a dreadful choice for use on screen.
A px is a pixel, which will map on to a screen pixel in most cases.
CSS provides a bunch of other units, and which one you should choose depends on what you are setting the size of.
A pixel is great if you need to size something to match an image, or if you want a thin border.
Percentages are great for font sizes as, if you use them consistently, you get font sizes proportional to the user's preference.
Ems are great when you want an element to size itself based on the font size (so a paragraph might get wider if the font size is larger)
… and so on.
pt is a derivation (abbreviation) of "point" which historically was used in print type faces where the size was commonly "measured" in "points" where 1 point has an approximate measurement of 1/72 of an inch, and thus a 72 point font would be 1 inch in size.
EDIT: Note to clarify
There are approximately 72 (72.272) points in one inch or 2.54 cm. The point was first established by the Milanese typographer, Francesco Torniella da Novara ( c. 1490 – 1589) in his 1517 alphabet, L'Alfabeto. (you can search for various references to those)
px is an abbreviation for "pixel" which is a simple "dot" on either a screen or a dot matrix printer or other printer or device which renders in a dot fashion - as opposed to old typewriters which had a fixed size, solid striker which left an imprint of the character by pressing on a ribbon, thus leaving an image of a fixed size.
Closely related to point are the terms "uppercase" and "lowercase" which historically had to do with the selection of the fixed typographical characters where the "capital" characters where placed in a box (case) above the non-capitalized characters which were place in a box below, and thus the "lower" case.
There were different boxes (cases) for different typographical fonts and sizes, but still and "upper" and "lower" case for each of those.
Another term is the "pica" which is a measure of one character in the font, thus a pica is 1/6 of an inch or 12 point units of measure (12/72) of measure.
Strickly speaking the measurement is on computers 4.233mm or 0.166in whereas the old point (American) is 1/72.27 of an inch and French is 4.512mm (0.177in.). Thus my statement of "approximate" regarding the measurements.
Further, typewriters as used in offices, had either and "Elite" or a "Pica" size where the size was 10 and 12 characters per inch respectively.
Additionally, the "point", prior to standardization was based on the metal typographers "foot" size, the size of the basic footprint of one character, and varied somewhat in size.
Note that a typographical "foot" was originally from a deceased printers actual foot. A typographic foot contains 72 picas or 864 points.
As to CSS use, I prefer to use EM rather than px or pt, thus gaining the advantage of scaling without loss of relative location and size.
EDIT: Just for completeness you can think of EM (em) as an element of measure of one font height, thus 1em for a 12pt font would be the height of that font and 2em would be twice that height. Note that for a 12px font, 2em is 24 pixels. SO 10px is typically 0.63em of a standard font as "most" browsers base on 16px = 1em as a standard font size.
Yes, "px" means "pixel"
Now that I said it, I can already hear an army of clairvoyants approaching, with "px has nothing to do with pixels" on their banners. They're so proud of knowing better that they look up every comment containing the original truth and explain in detail that it's false, incorrect, misleading, etc.
And yes they have a point - a very specific point in time, actually, called iPhone 4.
Here's what happened.
The peaceful days
Before Retina displays, one pixel was one pixel. Because that's how it should be, according to human logic. You put a single pixel line on the screen, you magnify the hell out of it, and there you go: it's exactly ONE PIXEL wide. On many hardwares, modern ones included, this is still the case, so it's everything but "incorrect" to say 1px = 1 pixel.
But.
Back then, one day, iPhone 3 was followed by iPhone 4, doubling the resolution in both X and Y, and the developers of Safari worried that all webpages will look ricidulous, especially because many web developers relied on the steady 320x480 resolution. So just creating a 640x960 pixel area would have killed most of the sites. And at this point, someone had the billion-dollar idea to introduce a magical beast: a CSS feature called -webkit-min-device-pixel-ratio - on iPhone 3 it was 1, and on iPhone 4 it was set to 2 by default. Meaning "1 CSS pixel now means 2 screen pixels". A very ugly hack to keep websites look somewhat intact - it worked at that time, with the very small cost of some images looking a bit blurry, but in the long run it caused this worldwide misunderstanding of poor old px who actually did nothing wrong.
So then: pt or px?
On screens, use px because on many-many displays it will mean ONE PIXEL. The biggest advantage of using pixels is they look crispy; even if 1px means 2 or 3 physical picture elements, whatever you draw will start at the boundary, not somewhere-in-between. This is very important. Watch any browser animation that includes text, especially size transitions: when you increase a div to double size, but slowly. You'll see how your browser recalculates its pixels and redraws the font when the animation is done. There's a temporary image of the area which is a little blurry - to make the animation itself smoother -, and then, after reaching its final state, a more exact image is calculated. See this CodePen.
1px is always an integer multiplication of hardware pixels; that is, unless your operating system is being smart like resizing your whole desktop to sqrt(2) x PI. Or just 125%, yes, hello Windows on tiny laptops. But anyway - with px, you have the highest chance to align your things with the physical grid.
What about pt? The funny thing about pt is it's actually translated to px, so it's just a worse way to specify pixel sizes. Here's a calculator. Points (since they come from the print world) start to make sense when you print something, but today there are better alternatives, depending on what you need - so tbh, points are almost never needed.
TL;DR
For screens, use px whenever possible.
I would like to get size of the Android Phone but size in mm and not in pixels.
I know how to get size in pixels, however I would like to do some RND and for that I want to get width of the screen in mm.
Like here Galaxy S4 size is Dimensions 136.6 x 69.8 x 7.9 mm (5.38 x 2.75 x 0.31 in)
136.6 x 69.8 x 7.9 mm (5.38 x 2.75 x 0.31 in)
^^^
Does any one knows what is this size for?
Though I am iPhone developer BUT I am beginner (1 day baby) for Android. Well below is what I want to do as RND.
Let's say designer gives me design for the app of size 1080*1920 and have title of size 30px (which covers 80% exactly) of the screen size.
That means 10% space on left side, 80% text and 10% space on right side.
I know in Android we have something called sp or android:textAppearance="#android:style/TextAppearance.Large", but that won't give the 10% spaces.
What I want to achieve is regardless of size, design should go same.
Considering design to fit with width, if height increases, I would have scrollview and I am okay with that.
"Pixel density" is the number of pixels per inch. So dpi gives you the scale factor you need so that the number of pixels is consistent across devices.
Another way of saying this is that if you have a 480 pixel screen with hdpi, then a 360 pixel screen at mdpi is about the same physical size. While the screen sizes may vary some, it generally is not that important. Even so, as mentioned, see this post about doing the actual calculation:
Is there a way to determine android physical screen height in cm or inches?
However, you are talking about percentages of screen size in your example. If you know the screen size in pixels, then the physical size doesn't matter, just do your calculations using pixels. If you have 480 pixels, 10% is 48.
You cannot do this in XML, which it sounds like you might be wanting to do. You can use "weighted linear layouts" for runtime calculations of the screen size. You can also use different res folders depending on screen size (like res/layout-hdpi).
You may want to read this from Google regarding supporting different screen sizes: http://developer.android.com/guide/practices/screens_support.html
Use DisplayMetrics. The API is: http://developer.android.com/reference/android/util/DisplayMetrics.html
You can perform a calculation on the given fields and obtain the height and width in inches, then convert that to mm.
I am making a calendar and I need a grid. Problem is the borders, or rather the space between each grid, which is what I am using to kind of simulate a grid, is 1 dp. But its rather thick. I am looking at other calendar apps that have the borders, and they are very thin. Even if I were to use a drawable shape and make it 1dp, it still has that thickness. I tried using .5, but that did not seem to work. Is that not possible?
Android does allow you to enter fractional values for dp into XML, though I'm not sure I would recommend it because the results become less easy to predict/compute. Devices convert dp values into pixels using (basically) the following formula:
px = (int)(scale * dp + 0.5)
(i.e. the device density scale rounded to the nearest whole pixel value)
The scale value would be based on the screen density of the device:
MDPI = 1
HDPI = 1.5
XHDPI = 2
XXHDPI = 3
So 0.5dp would result in {1px, 1px, 1px, 2px} for the above densities, whereas 1dp would be {1px, 2px, 2px, 3px}. A tiny value like 0.1dp would resolve to {1px, 1px, 1px, 1px} because anything less than 1 in the above formula resolves to a single pixel unless the value was explicitly 0dp (it's not possible to draw something thinner than a single pixel width).
If you want to ensure that thinnest possible width is used, probably best to define the width explicitly with px instead of a scaled unit like dp. Setting a value of 1px will draw with a single pixel on all devices, and is much more readable than hoping 0.5dp or 0.1dp does the same.
Yes.
I set to 0.1dp and it is smaller than 1dp on my 4" ME860 DRIOD.
Simple answer is yes, you can.
Simpe solution to your problem (i.e. achieve the thinnest possible line) set thinckness to:
1px
I suggest px as its not device dependant and it is the smallest measure available, furthermore it wont be converted into another form, therefore no rounding errors nor any unexpected rendering... let me explain.
Android layout xml file, or dimensions xml values file, will allow you to enter decimal values for dp.
HOWEVER:
I have experimented with several values from 0.1dp to 1dp, on many devices. Depending on the device - it may not render so as you expect.
On lower pixel density devices, the lines may render thicker on one side compared to another side even though they are coded to have the same... This is due to inaccuracy introduced when truncating the converted to dp to px value - (as Devunwired mentions):
px = (int)(scale * dp + 0.5)
A pixel (px) is the smallest unit and must be an integer. so - if your aim is to simply have the smallest possible line/border, why not set it to:
1px
I hope this helps!
I'm trying to make an Evolus Pencil template for Android. My device has a 1.75x2.5625" screen, and I would like to emulate these exact physical dimensions. From reading this post:
Android multiple screen sizes with same density
I see Physical Size = Pixels / Density. So if I create an image that is 168px wide, on a 96dpi screen, should I not get a physical image of 168/96=1.75" wide?
Because I get one about 1.5" and I'm lost. I am running Ubuntu and confirmed my screen dpi with xdpyinfo as being 96x96. So what is a formula I can use for this? I was thinking one could get the pixels needed by multiplying the inches we want on the screen by the dpi of the screen, but this gives me the 168 mentioned above and obviously gets me no where.
Can anyone point me in the right direction, I'm honestly terrible with numbers and math so my apologies if I'm missing something simple or obvious.
Are you sure that the display is actually 96 ppi? Going by the specs, and my own calculations, your Lenovo S10e actually has a density of ~116.36 ppi, which is probably where your difference is coming in.
Assuming these specs are correct:
10.1" diagonal
1024 x 576 resolution
16:9 screen ratio (taken from above resolution)
Using some geometric formulas, you can get the actual width and height of the monitor as:
Width: 8.8"
Height: 4.95"
Dividing 1024/8.8 and 576/4.95 gives you 116.36 pixels per inch, rather than 96.
Using this instead, a 168 pixel image should display as 168/116.36, or ~1.44", which is consistent with your results. I wouldn't put too much faith in the xdpyinfo results. :)