I am setting a custom font to all subviews (such as UILabels) inside my view by a custom function. However, if I try to correct the font size for specific UILabels only via
[lbl_EXAM_Statistics setFont:[UIFont fontWithName:#"PTSans-Regular" size:13]];
The 13point seems to be a little "too small" from what was given me from the Screendesign.
In the psd file however its 13pt to be exact.
Why does the 13pt font size differ from the 13pt font size in my app?
In the screenshot the above text is from the psd file, the bottom one from the iphone simulator.
If I want to get near the text size from the Screendesign to my app I'd have to use somewhat of 18pt - but I cant waste time playing around how to get the exact pt, thats a huge timewaste with all the font size I have to specify directly. So there must be a better way.
Totally depends on your psd.
Best is to set your metrics in Photoshop in pixels. So you can see the size of your font in pixels.
Then if your PSD is at retina size (640 px width), you just have to devide by 2 the px size of your font and you will have the good result on your app.
In the end, don't use pt but px in your PSD and it will be allright (just have to think that 1point in iOS is 2px on retina screen and 1px on non-retina)
Photoshop's font size and the iPhone's should match assuming the PSD file is set to 72dpi (or 144 for retina images).
You can check this in Photoshop using Image->Image Size... and then set the resolution to 72 pixels/inch (keeping the pixels untouched by unchecking "Resample Image:"). If the image is for retina resolution, use 144 pixels/inch.
This will not change the image in any way but make all pt measurements in Photoshop match the iPhone's coordinate system, retina or not.
Related
I am writing an iPad app which requires letters to be displayed at their exact point size regardless of screen size.
I've implemented the text display using a UILabel object. I have the Autoshrink property set to Fixed Font Size, however the letters on the screen are much smaller than indicated by the font metrics. For instance the capitals of a 251 point font, which should be 3.5 inches tall, are only 2 inches on the screen. At different point sizes the same shrinkage happens.
The fontCapHeight is the same as the font size with the font I am using.
How can I make the displayed size is the same as the font size?
For instance the capitals of a 251 point font, which should be 3.5 inches tall, are only 2 inches on the screen.
You're assuming a point is 1/72", which is not true. That's a desktop publishing point. A point in iOS is a certain number of pixels (based on the scale). The number of pixels in an inch are a factor of the screen's pixel density (PPI). iOS provides no way to query for that that I'm aware of. You have to just have a big table that knows. A fairly nice one for that is GBDeviceInfo, but ultimately it just has a big table of values based on looking up specs or measuring screens.
You need your cap height (pt) to be (ppi/scale)*inches, but you can't set cap height directly. You need to set it via the em box size (the "font size"). Here's an example. It takes a label containing a font of any size and make it's cap height be 3".
let font = label.font!
let ppi = 326.0 // iPhone 6s
let scale = Double(UIScreen.main.scale)
let desiredSize = 3.0 // inches
let emBoxRatio = Double(font.pointSize / font.capHeight)
let fontSize = (ppi / scale) * desiredSize * emBoxRatio
label.font = label.font.withSize(CGFloat(fontSize))
Keep in mind that "make its cap height be 3 inches" is not the same thing as "make any particular letter be 3 inches." It depends on the font and the letter. In many fonts, glyphs with a curved top are a little taller than the cap height, and some ascenders may be a little taller than the cap height. While H, X, and I are often exactly the cap height, sometimes they're a little shorter (sometimes O is the cap height rather than X). Sometimes glyphs are above their baseline. There is nothing that says that a font even has to fit within its em box, and some fonts draw wildly outside (Zapfino, I'm looking at you).
My only point here is that you need to check your actual font carefully. Font metrics are serving suggestions at best. They're meant to make fonts with similar metrics "feel" the same. They're not always absolute measures of things.
I don't understand this:
The fontCapHeight is the same as the font size with the font I am using
If the cap height is the same as the "font size" (em box height), then where are the descenders? It feels like you've run out of em box.
Problem solved. I found the following statement at http://blog.fluidui.com/designing-for-mobile-101-pixels-points-and-resolutions/ : "An iOS point is equivalent to 1/163 of an inch. This size is always the same regardless of the resolution of the phone it is on, and comes from the 163DPI of the original iPhone." I couldn't find it anywhere in the Apple documentation, but I'm sure it is there somewhere!
I'm having a hard time putting all the information on image sizes for #1x, #2x, and #3x together. I've been using the scene editor in XCode with the scene size being 1334x750 (pixel dimensions of the screen of the iPhone 6). So when I size an image for a sprite in that scene, is that the size I should use for the #2x?
From what I've read in the documentation CGSize uses points, not pixels, so if I have an image that is CGSize(width: 50, height: 50), is this independent of my scene size in the scene editor?
Bottom line question: How does the CGSize dimensions translate to how I export my images for #1x, #2x, and #3x in pixels and what should the PPI be when I export?
Xcode can handle vector images, so you can forget about #2X and #3X images if you are able to export your images as PDF e.g. in Sketches export panel one of the options for export format is PDF, so create your artwork #1X and export as PDF, then in Xcode when you add the image to Assets.xcassets, you can set the images Scales attribute to Single Scale. Xcode will generate the required #2X and #3X images from your vector PDF at build time.
The concept is simple. The size in Storyboard or Interface Builder should be the size of you asset in #1x format.
The retina display ( or the iPhone 6+ #3x size ) does not mean than you have much space than before, it means that you can draw 2 ( or 3 ) pixels where you draw 1 before.
So for a 50x50 px Image View, cou should have 3 assets :
- Image#1x.png ( 50x50 px)
- Image#2x.png ( 100x100 px)
- Image#3x.png ( 150x150 px)
Suppose you have created an image in your assets library consisting of 3 sets of same image, #1x.png having size 50x50 pixels, #2x.png of size 100x100 pixels and #3x.png size 150x150 pixels.
you don't needs to worry about which one to use in your storyboard(because storyboard automatically using #1x.png), and which one to use for the targeted device like as iPhone6, or iphone7, or iPad(because by default programing all hardware finds out their pixels relative required image among those #1x.png, #2x.png and #3x.png)
for further instructions you needs to study Auto layout Programing Guide
you can also view their apple's tutorial videos regarding Auto layout.
mysteries of auto layout part1
mysteries of auto layout part2
#1x and #2x used to relate to the retina graphics change when iPhone 4 came out.
iPhone 3GS was 320x480, iPhone 4 was 640x960. This meant that the points per inch were literally the same, but the ppi was doubled, hence the #2x. When the iPhone 5 came out, the only thing that changed was the height, so the ppi was the same for the width, no problems here.
Then we hit the 6 and 6+. At this point, apple said screw it, try to keep ppi that correlate to previous iPhones without having keep the previous iphones usable area, or provide bigger screen pixels for bigger devices. Now #2x has lost its original meaning
But, to really throw us off, they made the iPhone SE, which went back to the ppi screen size of the iPhone 5, so #2x makes sense again.
Basically, when thinking of the #2x graphics, think about the 1st iPhone resolution size.
Now, you have a choice to make. You can give your apps more/less usable area, you can black box the extra usable area, or you can scale and take some kind of quality loss due to game pixels not being 1:1 with the screen pixels anymore.
All of the breakpoint helpers online use pixels. For example: iPhone 6 and 6 Plus Responsive Breakpoints. But browsers don't treat emss the same way. There's no set em-to-pixel size that's the same across all phone browsers. So what does the iPhone (iOS Safari) say is the width/height in em's?
An em is not a unit of fixed size, it's a relative measurement based on the parents size. For example setting a body font size of 12 px, then a child element with font size 0.5em, the child will effectively have a font size equivalent to 6px (0.5 * parents size).
Since this is a relative measurement, it does not make sense to define fixed bounds in this way.
I followed the PaintCode tutorials on StyleKit and I've successfully exported icons into a Swift project (code only - MyStyleKit.swift file). I'm trying to understand the relationship between the UIImage generated in code and the image sizes expected for different iOS devices.
I wired up the MyStyleKit object in the storyboards to the image for the Tab bar icon. Works great but I can't tell if the resolution of the image is adjusting depending on the device. Apple's HIG suggests the tab bar icon size in pixels should be
75 x 75 px for #3x images (iphone6+)
50 x 50 px for #2x retina image
25 x 25 px for non-retina
Firstly what canvas size should I be choosing in PaintCode initially? I guessed at putting the canvas size as 25 x 25, reasoning that I should map to the UI points size.
When I rig up the icon in Storyboards does it automatically adjust to whether it needs #3x, #2x or #1x?
Should I be setting the canvas size to the UI points size?
Any help would be greatly appreciated.
Yes, set the canvas size to 25×25 points. You can then preview the canvas at #1x, #2x or #3x (or infinite) scale.
When you ask the StyleKit for image of this canvas, the returned UIImage will have the size of 25×25 points, but scale of the current screen. That means 25×25, 50×50 or 75×75 pixels.
Scaled screenshot on iPhone 5S:
CCLabelBMFont is on top and CCLabelTTF is at the bottom.
Both strings use Helvetica Neue Light 17pt.
As you can see there is some kind of a stroke in the first string, but all symbols in font image are white on transparent background. Is it possible to get rid of this effect and make CCLabelBMFont look just as good as CCLabelTTF?
I used bmGlyph and other free analogs for Bitmap font creation, results were always the same.
First, don't change the node's scale property or it will be blurry.
You need to make a HD version of the font, where the font's png filename has the -hd suffix and the font size is double that for non-Retina devices. For example:
Non-Retina font with 32pt size (if you support non-retina devices):
font.fnt
font.png
Then create a font with 64pt size and save it as:
font-hd.fnt
font-hd.png
What a relief!
Turned out it's because of Blend src property.
I changed this property on my label from default in SpriteBuilder 'One' to 'Dst Alpha' and now it's impossible to see any difference between CCLabelTTF and CCLabelBMFont!