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.
Related
Now that it's 2022 and Android tablets (and their cousins, foldables) are getting more prevalent, I got my interest ramped up in building a better tablet version of one of my apps. Coming from iOS, there is a useful layout feature that one can use when designing tablet UIs called "readable content guide". Apple describes it as follows:
This layout guide defines an area that can easily be read without forcing users to move their head to track the lines. The readable content area follows the following rules:
The readable content guide never extends beyond the view’s layout margin guide.
The readable content guide is vertically centered inside the layout margin guide.
The readable content guide’s width is equal to or less than the readable width defined for the current dynamic text size.
A picture is worth a thousand words. To the right is some text aligned to the readable content guide (the left version just spans the width of the main view):
Looks great when reading long-form content, doesn't it? Thus, my question:
is there a standardized version (that is, without me having to code one myself) of a feature similar to this on Android?
Now that version 12L is out, I thought it would incorporate something like this, especially with Google promoting Jetpack Compose (and other new UI extensions) as a faster and easier way to build UIs.
If you know what a comfortable width is you can use android:maxWidth="yourWidth" to limit the width of your textview to what you want
I have a wordpress website with Json API installed.
Now I want to take the posts content and put it in a webview that has normal margins, breaklines that prevent the text to go out of the screen, prevent zoom in or zoom out (or these will just increase/ decrease font size), and consistent font size across all posts length.
Until now I used a textview, because I just couldn't make it look right, But textview can't show images or videos, and it looks worse overall than my website's mobile version.
this is an example of an html code content:
<p dir=\"ltr\"><strong>This is how a Post should look like</strong></p>\n<p dir=\"ltr\"> <span style=\"text-decoration: underline;\"><u>with underlines and highlights</u> </span></p>\n<p dir=\"ltr\">Paragraphs are the building blocks of papers. Many students define paragraphs in terms of length: a paragraph is a group of at least five sentences, a paragraph is half a page long, etc. In reality, though, the unity and coherence of ideas among sentences is what constitutes a paragraph. A paragraph is defined as “a group of sentences or a single sentence that forms a unit” (Lunsford and Connors 116). Length and appearance do not determine whether a section in a paper is a paragraph. For instance, in some styles of writing, particularly journalistic styles, a paragraph can be just one sentence long. Ultimately, a paragraph is a sentence or group of sentences that support one main idea. In this handout, we will refer to this as the “controlling idea,” because it controls what happens in the rest of the paragraph.</p>\n<p dir=\"ltr\">list of examples:</p>\n<ul>\n<li dir=\"ltr\" style=\"text-align: left;\">first itme</li>\n<li dir=\"ltr\" style=\"text-align: left;\">second item</li>\n</ul>\n<p> </p>\n<p> </p>\n
(you can ignore the "/n" I delete it through code)
this is how I want it too look like:
this is how it actually looks like:
example 1
example 2
as you can see there are no borders and it looks like a desktop site on smartphone.
thank you!
Say you've a list of Strings. The number of Strings varies. Is there a way to randomly display these strings like in an Apple presentation when they show a bunch of features in a slide. See link for an example.
http://www.technobuffalo.com/2011/06/10/iphone-5-feature-hinted-at-in-ios-5-wwdc-presentation/
So, text is randomly scattered but never overlaps. Spacing is pretty even. Some text is dim, some is bolder, big, small, etc. I couldn't find the 'name' of this effect (or these multiple combined effects) if there even is one?
I assume they do it manually in a slide of course, but I was wondering if there was a known way of doing this programmatically.
Any help would be much appreciated!
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.
My Android app displays text in a few different ways, and there are some annoying differences between them I was hoping folks could help with.
When I use display methods that might be termed "automatic," the text is displayed very nicely. By automatic methods, I'm referring tools, like Toasts and Button widgets where I just have supply the text, and the OS (or "environment" or whatever) displays it for me. The letters are nicely curved, pleasant to look at, and easily legible.
However, in my code where I handle the text display (using Canvas.drawText() in a Surface Runner View), the text quality is poor. The text is still legible, but it looks pixelated. The letters just don't look their best.
I've tried experimenting with Paint.setTypeface(), using Typeface.SANS_SERIF for example, but the quality of the display when it's my code is always poor. Doable, but poor.
Has anybody else experienced this? By any chance does anybody have a solution?
You might also try playing around with Paint.setAntiAlias(boolean) or Paint.setSubpixelText(boolean).