I've been trying to make use of the Unicode symbols for astrology in products for both Apple and iOS. I'm getting inconsistent results, as shown here:
Most of these are coming out as I like, but for some reason the Taurus symbol is appearing one way on the first line, following the Moon, and a very different way, with the Emoji-like purple button, when it follows Mars. These results are consistent for different symbols and across Apple hardware; here's a screen capture from my phone showing the same problem with some other signs - Scorpio comes out all right, but Libra and Cancer are buttons.
The strings are extremely straightforward; "Moon Taurus" in the first image is \u263D for Moon, \u2649 for Taurus, basically assembled as [NSString stringWithFormat:#"%#%#", #"\u263D", #"\u2649"]. The "Mars Taurus" image is the same, only with \u2642 for Mars. The string formatting is identical in the different cells of the OSX table, and in the iOS AttributedString.
Any idea what makes these symbols appear one way sometimes, and another way other times?
Unicode uses variation sequences to select between different renderings for certain code points—listed in the StandardizedVariants.txt file. In your case, the astrological symbols have both "text style" and "emoji style" variants that are selected between by a U+FEOE (text style) or U+FE0F (emoji style) following the code point:
U+2650 U+FE0E: ♐︎
U+2650 U+FE0F: ♐️
Note that correct interpretation of the variation selector depends on support from both the application/framework and the fonts being used. On Chrome (42) there doesn't appear to be any difference between my examples above, but on Safari (8) they are distinct.
I've been following the Google official Material Design guidelines (http://www.google.com/design/spec/style/typography.html) on typography but I find them to be quite lacking. For instance, they list 10 styles you should use for things like body, subhead, title, headline display1, display2, etc. type text in your app... This leads me to the first problem.
Problem #1: How does one know what a "subhead" is, or a "title" vs "headline", or when should "display1" be used as opposed to "display4", are there standards for these items?
Moreover, the guidelines state that leading space should be built into the line-height of the text. Therefore, problem 2.
Problem 2#: How can I add "leading" space for text in Android, is this relevant Android guidance?
Problem #3: Although I've downloaded the latest version of Roboto, my medium fonts look absolutely bold, as opposed to Google's elegant and slightly thicker medium fonts, how can I confirm my font is actually different than Googles?
Thank you very much
"Show me the code": not mine, but see comment below for one option, and also how Plaid app (Butcher) tacked typography challenges by visiting its source on Github (BaselineGridTextView class).
Disclaimer: I'm by no means a reference in this subject, but your question is a month old without any answers, even though it is important and its importance will only grow from now on. That said, I'll try to, at least, give some light and offer my head because of the possible mistakes.
Problem #1: How does one know what a "subhead" is, or a "title" vs "headline", or when should "display1" be used as opposed to "display4", are there standards for these items?
These are common, standardized, abstract text entities that came to us from the traditions in printed publishing.
Display: big text, normally used at placards, attractive slogans, things that demand and compete for attention, that should draw attention when the user isn't looking. It is less readable exactly because it should be very short (draw attention at once, not part of extensive flow). I imagine the 4 different display sizes in Material Design is just extra care from Matias and his team, but I doubt apps will ever use more than 1 display size (maybe magazines and rich media app, perhaps). Most apps won't even use display size at all.
Headline: traditionally, I believe, if my shallow understanding of this subject is right, headline sizes are used as short taglines of the story. Not a description, just a tagline, a short message. An example of a headline: ASSASSIN KILLS KENNEDY. In common apps following Material Design, it is used as the main subject of a screen (just like pages of a newspaper). I think (as in not sure) that this may be called “Heading” elsewhere.
Title: honestly, it is very generic, and because of its modest size (compared to headline and display), it is one of the styles I use the most: it is very useful in places above a block of text. For example, “Eula” as a title for the eula text that follows this title, or “Authors” immediately before a list of authors. It is widely used in the framework as well.
Subhead: this is more specific. It is an immediate, inferior degree to “headline”, and is used to provide excerpts, quotes or a brief description of the text block that follows it. Example of a subhead (following the headline example): Governor of Texas Wounded, Marxist accused of murder. In Material Design, because of the size, the most common place I've seen it used in is in a two item list item, exactly because it is used as excerpt of an email (to provide an overview) or as a phone number (a detail of the most important asset for a particular person in a phone list).
Body: main text. Pretty obvious. The most readable of them all, and the only option for long texts.
Caption: footnotes and small text. In print, it is widely used as captions of images. In Holo, I think (as in not sure) it was used as divider text (but in all caps). In Material Design, I think dividers stopped using caption text and use “body” with light color.
Other programs use these (part, or all) concepts themselves with slightly variations:
text styles of text processors;
font settings in image software like Photoshop, Illustrator and so on.
optical sizing of fonts. Adobe, for example, uses “caption”, “regular”, “subhead” and “display”, which, as you can see, is meant to complement sizing and leading with font shapes especially tailored to different size spans;
The general concept seems to be that these are abstract entities that represent gradients of importance in text sets, and may have flexible rules between publications as long as it is used consistently within a publication, theme, application etc..
Problem 2#: How can I add "leading" space for text in Android,
This is for those places where you mix TextViews with different styles, like in the image example (or with text spans, of course).
Let me be honest: right now, for emergency purposes, I'm using my eyes with superimposed grids to check my leading. I'm starting with the leading size, then I subtract the font size of the following text line and some small amount as the descender of the current line. Then I make tiny small optical adjustments if needed. It would be nice if these elements (x-height, cap height, descender etc.) could be calculated exactly, but I honestly didn't dive into this yet (but it's probably possible). I'm satisfied with my “eyeometer” while I don't perfect MD in my layouts.
However, and I just looked at this (didn't try it out), I believe you can dive into FontMetrics, measuring the fields and applying the proper dimensions on the fly between the two TextViews shown above. I'd try that first (ascent of the next and descent of the previous).
is this relevant Android guidance?
Yes, it is. Very much. Place a text below another, when they have different styles. Like a title followed by a body, and try to just take a wild guess: it won't work and your app won't be consistent with the system. See above.
Problem #3: Although I've downloaded the latest version of Roboto, my medium fonts look absolutely bold, as opposed to Google's elegant and slightly thicker medium fonts, how can I confirm my font is actually different than Googles?
Please tell us where exactly you're getting the two samples to compare. Font rendering may be affect by many different things, and each system uses its own hinting algorithms, besides many other things. There are slight variations even between different Roboto versions and different Android versions. Surely medium looks “boldy” compared to regular, but not actually bold.
You can check the fonts in your sdk/platforms/android-APIVERSION/data/fonts folder. Rendering with Ubuntu 15.04 (slight hinting), out of the box, as of android-22:
I think it stays accordingly to the sample.
To compare with something also widely available, this is (part of) the Ubuntu font family (regular, medium and bold, respectively). In my opinion, medium also comes closer to bold than regular:
Minion Pro (regular, medium, semi and bold). It is more evenly weighted possibly because it also offers a semibold variant, but we are talking about a serif font made for fine print and with much more time in the market to have been continuously refined:
I hope this helps.
I am trying to have a custom EditText based on the background that i am using for. The Background image has some spaces between the entry areas so i need to have some space between the characters(kerning) to fit them right in. So for example after every character the user enters, i need to put 4 whitespace after that.
I couldn't find any solution for this on the net so far, some people suggested TextWatcher, but i couldn't manage to make it work as i want it too.
Can someone help me about it?
Thanks
I have you considered using a custom font? Some font types are made to stretch out or shrink or have empty spaces. With so many different fonts available online, you can definitely find something. You can also make your own with a software. It might be time consuming if you start the lettering from scratch. I'm not 100% sure if it'll fit exactly to your background, but it's idea that you can consider.
If it doesn't fit, I supposed you can always customized the background to fix your font too. Here's the code for those who might want to use custom fonts in their app too.
Typeface myfont = Typeface.createFromAsset(getAssets(),
"fonts/Blocks2.ttf");
myeditText.setTypeface(myfont);
The font is in the asset folder under another folder called fonts.
This question is related to How to change letter spacing in a Textview?
As shown at this issue: android format edittext to display spaces after every 4 characters a solution might be to insert spaces with Java code...
You need to use TextWatcher to achieve visual purpose spaces.
And use any simply split string by space logic to join it back or loop
through the entire string per character wise and eliminate (char) 32
from the string
As far as i know actual character spacing is not possible, though i'd love to use that myself as well.
Another option might be to use a custom font with the character spacing included.
A short preface. Thai script has vowel signs that may appear above the consonants, and also there are diacritic signs (DS) that also appear above the consonants; when both vowel and DS present, they appear one above other, so the vowel is set above the consonant and the DS is set above the vowel.
I am writing an application that will display text in Thai. Everything looks perfect in the emulator (API 10) but not on the real device (Samsung GT-I9001 with Gingerbread 2.3.6).
I've prepared two pictures to illustrate the problem. I have a simple layout that has the only TextView at the top; two words พี่สาว and ไม้ are displayed in that view.
This is how it should look like (a screenshot from the emulator):
The first character has a vowel and a DS above the vowel, and the last character has the DS only.
And here is a screenshot from my phone:
Both DS have slid down and now the vowel and the DS overlap each other above the first character. Note that the last by one character appears lower than it should (it should be whole line tall like you may see on the first screenshot).
I've found that the problem is system-wide: I've copied these Thai words to a simple web page and loaded it in the web browser in my phone, and got the same problem. It seems like the font rendering is broken.
So the question: how to bypass this? Do I need to install fonts (how?) or maybe some language pack (again, how?), or the only way is upgrading the Android?
PS: no problem on Android 4.0.4. Perhaps only old versions are affected.
Update: WarrenFaith has given a promising advice about setting the custom font. However this appeared to be not as simple as it looks. I've tried several different fonts including Roboto (introduced in ICS), Verdana from the msttf Linux package, and some others. To see that the font is really loaded and applied, I've added some Latin and Cyrillic characters to my text.
The result is funny. Only the Latin and Cyrillic characters change, but not Thai ones. Looks like the fonts don't have the required glyphs and Android replaces them with ones rendered using some default font.
(I don't understand why Roboto didn't work; it's the official Android font—shouldn't it have full support for the whole Unicode?)
So it seems like I have to find the font that has Thai glyphs.
And I'm still wondering what font is used by default in Android 4.0.4.
Happy end: thanks to WarrenFaith's advice, Google, and this blog article.
If the default text/font is broken, you should provide a font you know that will work. To implement the font, you can use the following answers:
Android - Using Custom Font
Using a custom typeface in Android
I'm currently facing strange problems with Android's font Roboto. At first I had two TextViews in one horizontal LinearLayout, centered both vertically and horizontally. The first TextView was set font Roboto-Black.ttf and the second was Roboto-Light.ttf. Both was set to textSize="12sp", but the one with Roboto-Light.ttf was just a pixel higher then the Roboto-Black.ttf TextView. But it didn't happen when I've set textSize="13sp". So I've created new Android project, just to be sure it's not only in the one application. The result is almost identical, but in this case, textSize="12sp" works as expected but textSize="13sp" doesn't. I've made screenshots to show the issue.
12sp works as expected. Top edges align.
13sp has this strange behavior.
Strange is, that this happens only when I try to mix thin and thick lined variants. When I make one TextView Roboto-Bold.ttf and second Roboto-Black.ttf, result is good. When I try Roboto-Light.ttf and Roboto-Thin.ttf, it also work properly.
So I also tried to test this in photoshop and this is what I found:
It's the same for all fonts from Roboto family, except for the Roboto-Light.ttf. I can also post source code for the layout if needed.
Thanks in advance.
PS: I'm sorry for the links but due to low reputation (brand new account) I can't post images. Also in the last link i had to remove the "h" from "http", because it didn't allow me more than two links.
I can't tell you if its the fonts or how your phone interprets the fonts and displays them on the screen but I can tell you that I've had issues with centering views in the middle before.
Have you tried using a relativelayout and then align the second textviews top and bot with the first textview? That might solve the problem.