[MUSIC PLAYING]
RAPH LEVIEN: I'm Raph Levien.
I'm on the Android
UI Toolkit team,
and I'm going to
talk to you today
about Android textual layout.
And I hope you'll find
this an interesting talk,
and I hope you brought
lots of questions as well.
And I'm happy to address
those after the session
and also at office
hours this afternoon.
So I'm going to talk
about-- it's kind of a grab
bag of a bunch of different
topics around text
and typography on Android.
I'm going to talk about
some of the challenges
and opportunities.
Just a little bit of an
introduction to material
design, which I'm sure everybody
here is quite familiar with.
Then I'm going to go into some
of the details about the Roboto
2 and Noto fonts, and
especially the kind of more
recent changes around
these to better support
international typography.
A huge amount of the work that
we do on the Android UI Toolkit
team is supporting all of
the languages of the world,
or most of them.
Then I'm going to go into
some of the really, I think,
exciting newer features
around OpenType
typography control and high
quality paragraph layout,
which rolled out in
Lollipop and Marshmallow.
So what are some of the
challenges and opportunities?
I mean, I come from
a print background.
And doing typography
on mobile is
extremely different than
doing typography on print.
There are some things in common,
but there are some things
that are really different.
You have to be very focused
on the performance of the text
stack because you've got
only so much battery and only
so much RAM.
But you really do have very
powerful compute resources.
You've got multi-core,
multi-gigahertz processes
in there.
So if you want to do
sophisticated, advanced
typography, you do have the
compute power to do that.
60 frames a second is
absolutely a requirement.
And this is, again, both a
challenge and an opportunity
that you can do these
really rich animations
and transitions, and do this
kind of interactive motion
typography that
really is completely
impossible in a
print background.
But you have to
make everything fit
in that 16 millisecond budget.
You've got a very small screen.
And this has some
interesting challenges
in how you create
your layouts, how
you do the paragraph layout.
But a flipside, again, is
that on modern devices,
you have this very
high resolution.
Then, as I mentioned,
we have this requirement
to support all of the
languages of the world, all
of the scripts of the world.
But we have a lot of
really good resources
both in fonts and typography
control of how you do that.
And then I'm going
to talk about some
of the line breaking
improvements,
some of the paragraph layout
improvements in Marshmallow.
And those were really
motivated by a need
to get this working
in very small screens,
like watch faces.
So I'm going to just introduce
this concept of the advance
of display technology.
This was the first
mobile device I ever
had when I was 12 years old.
And as you can see, it's
got a lot of the elements
of a modern mobile device.
It even has a really
nice, big keyboard.
But the display technology in
this generation of technology
is kind of the bare
minimum that you need
to get text displayed at all.
And I think that that
evolution kind of carried
that there was a very
primitive approach
to just get the letters
drawn on the screen
and not really think
about typography.
Another good thing
about this screenshot
is you get some sense of the
difference in computing power
available today as back then.
So before I worked
on Android, I was
working on Google web
fonts, Google Fonts.
And the upper left corner is
kind of your classic laptop
or desktop screen.
And this really
ruled what we did,
that you have a very
small number of pixels
to represent the text.
And you have a
lot of constraints
in how the letterforms
map into those pixels.
And that also
includes the spacing.
You see very poor-- like the a
and p are crunched up together,
and the p and o are
separated, because you only
have so many pixels
and so much precision.
But as you go into more
modern display technology,
you have so many more pixels.
And so on the upper right,
you have a 4k monitor, which
is starting to replace laptops.
And on the lower
left, this isn't even
the most recent device.
This is a two-year-old
device and it has 468 ppi.
And you probably can't
even see the pixels here.
And then comparing that to,
for example, an inkjet printer,
you actually have, on
these mobile devices,
you have a much higher
precision, higher quality
representation of the
shapes of the letter forms
and the spaces between them.
So it really enables typography.
And all four of these
screen shots or captures
are of the same 12
point Times Roman.
And so this is what we
have to work with today.
This is our lead
device, the Nexus 6P.
It's an amazing device.
And it has an amazing screen
to match the overall device.
It's at 515 ppi.
One of the ways I think
about screen resolution
is when Star Trek-- when they
were doing the Star Trek TV
show, they had a book that
had all of the specifications
for all of the technology,
like how many terajoules
were in a phasor pulse.
And one of the
specifications is what
is the resolution of
these little devices
that people are carrying around?
And the answer is 400 dpi.
So we've blown way
past Star Trek.
So as I say, everybody here
knows about material design.
This will just touch
on it that the UX team,
it started really
about two years ago
that they were looking at these
more powerful devices, higher
quality display technologies.
And they were really thinking,
if we were redesigning this
from scratch, if we really could
do anything, what would we do?
And the result of
that exploration
really synthesized into
a set of guidelines,
into a coherent design
language that incorporates
many different elements.
It incorporates
colors, it incorporates
the material
metaphors with paper,
and kind of a three
dimensional effect.
And it also
incorporates typography.
And so one of the sections
in the material design
spec I really recommend, it
has a lot of good information
and a lot of good guidance
about how to do typography
within material design.
And of course,
another part of that
is a much greater expanded
palette of different weights
and of different sizes, and how
you use the weight and size.
Instead of having just one
size of text, one weight,
you use this to
indicate the structure
of your app, the structure of
the information in your app.
So the cornerstone of
typography in material design
is the Roboto 2 typeface.
And so this was an update
that happened in Lollipop.
And it was pretty subtle.
A lot of people probably
didn't even notice it.
But there was actually a
lot going on in this update.
So one of the things is the
expanded Unicode coverage.
It actually increased
by a factor of three.
And we have full
support for Unicode 8
for Latin, Greek,
and Cyrillic scripts.
And that covers a lot of the
languages in the world that
are maybe less familiar to us,
like the African languages use
a lot of unusual
Latin characters.
We also expanded the
weights and styles
that we ship on the device.
So we're doing thin, light,
regular, medium, bold,
and black.
So there's a tremendous
palette of the visual effects
that you can get.
And all of those
include true italics.
And we also have a
family of condensed,
which is better for better
information density,
and also can give
you some contrast.
Two different styles that you
can work with in your app.
In addition, the Roboto 2 font
is completely open source.
And that includes not just the
final true type font files,
but the entire build chain.
So you can go in there and
customize it and play with it
and send us pull requests.
And we really treat
almost everything
we do in a very
open source manner.
So the design updated as well.
And this is just a little
bit of a before and after.
And you can see it's
a little subtle,
but there's kind of
a stiff sides to some
of the characters,
like a capital O.
And that has become a more
refined, gentle curve.
Some of the shapes were
maybe a little bit unusual,
like the K's and the
capital R. And those
have become more simplified
and more streamlined.
And we also went from
a square dot on the i's
and j's to a round dot.
So it's an evolution.
It's a more refined form
of the original design.
It's very central to Android
and very central, of course,
to material design.
So I talked about the
global reach of Android.
And we talk a lot about
the next billion users.
And they're-- like we heard
in the previous talk, about,
how do you reach them through
the Play Store console?
But there's also a
lot that you have
to do with the presentation
of text and language
in these devices.
So again, Roboto 2 dramatically
increases the Unicode coverage.
And you can see, this
is just a sample.
This is just one of the pages
of additional extended Latin
characters.
And another thing I'll point
out, just for this slide,
like if you look kind
of near the middle
towards the left-hand
side, you see
some O's with some
doubly stacked accents.
And that's a very common
pattern in a lot of languages,
but not European languages
that we're used to.
So you see it in Vietnamese and
some of these other languages.
So you really-- when
you're designing your apps,
when you're testing
your apps, you really
need to be careful
to test them in some
of these other languages
to make sure that you've
got enough vertical space.
This is one of the
real key takeaways
that if you just
design in English,
you've got these letters, they
don't have anything going on
above, they don't have
anything going on below.
But that is not the
experience of millions,
hundreds of millions of
people around the world.
So in addition to Latin,
Greek, and Cyrillic,
there's this huge diversity
of other languages.
And in fact, this is the list
of scripts, not even languages.
There's many scripts that
support multiple languages.
These are the Noto
scripts that we're
supporting in Marshmallow.
So it really is a huge expansion
compared with previous versions
of Android.
And it really covers a very
large fraction of the languages
that are spoken in the world.
And so here are three scripts
that I just kind of picked out
as representative.
I find these just
really beautiful.
And you can see attention
between classical forms,
but also trying to make them
consistent with the kind
of clean Roboto design.
And so I think these
three are either
new in either
Marshmallow or Lollipop.
So then, in addition to
this large set of scripts,
CJK, Chinese,
Japanese, and Korean,
represent a very large fraction
of the users of Android.
A lot of the users in the world.
And so in Lollipop, we
launched Noto CJK, which
is a joint project with Adobe.
So it's also out
there-- they released it
as source Hans Sans.
And that's also an
open source project.
And it has a tracker.
It's very active.
People find issues and
it's being revised.
And in addition,
to just the fonts,
that project also
brought with it
a high quality
renderer for something
called CFF, Compact Font Format.
And this is based
on the Adobe code,
but it's now been open
sourced as part of free type.
So you can go look at the code,
use that in your own projects
as well.
So Noto CJK is a very
ambitious project
that really is designed to
be a comprehensive support
font to support all of CJK.
And that includes the
different local forms.
So there's a difference between
simplified and traditional
Chinese.
Those are different
from Japanese.
And then there are
some glyphs that
appear different in Korean.
And it's very important
to these users
to see the correct
form in their language.
If you see it wrong, it
really is a polish problem.
So notice CJK has
a unified design.
There's like a consistent--
like there's some releases
that we've done where the
Chinese and Japanese really
don't look like they're part
of the same family of fonts.
And in Noto CJK, we really
have a unified design,
but we have the
different variants
in the different regions.
So no discussion of
text is complete today
without talking about emoji.
And we really treat
emoji as a type of text.
So an app doesn't have
to do anything special.
An app doesn't have to say, oh,
show me some color images here
or something like that.
You just represent text and you
ask for the text to be drawn,
or in a text view, or edited.
And it just automatically
shows up using this color font
technology which is now
standardized in OpenType 1.7.
And there are
actually many tools,
many font editors
actually will create fonts
in this emoji form.
So if you want to-- or I should
say, in a color font form.
Whether it's used for emoji
or not is really up to you.
And you can incorporate these
custom fonts in your app
and get color representation
of either emoji or text
just by dropping in the font.
This also supports
flags and keycaps.
It's a more expanded
set of emoji.
And one of the new API's--
I should say this is
a Marshmallow API.
In a lot of apps, you want to
know what emoji are present,
because you want to make a
decision do you present this
as a palette for
users to choose.
And this has always
been a problem
because different phones will
have different emoji sets.
And as we're upgrading,
it's hard to know,
is this emoji present
or not, or does
this flag exist, in the
case of the flag emoji.
And so we've got this new
API that will tell you.
It's very fast and we
really recommend-- we really
want you to be using
hasGlyph so you
know what emoji are on your
device, what you can use.
So then I want to
talk about some
of the typography features.
We've really been
expanding this.
The goal-- my goal
certainly-- is to make Android
typography match what
you can do on the web
and match what you can do not
just in print, but like really
high quality print.
And so I'll walk you
through some of the things
that we do here.
I'll just go through
this list and then
I'll show some
examples that we have.
Kerning and ligatures,
we've actually
had those since, I
think, Jelly Bean MR2.
But now there's more control.
So if you want to
turn those on and off,
there's fine grain
control to do that.
We have this font feature
settings attribute
where you really can go in and
control the OpenType features.
I'll give you several
examples of that.
And that's using a
CSS-compatible syntax.
So we want to make this stuff
so if your designers are used
to controlling
typography on the web,
we want to make impedance
mismatch as smooth as possible.
So you can just
take that knowledge
and apply it to Android apps.
And then this is a little
bit more technical thing,
but we use OpenType integrally
to give you these localized
forms that-- there are many
languages, certainly not
just the Chinese, Japanese,
and Korean, where there's going
to be some subtle differences.
The same basic script,
but differences in the way
it's presented.
And we use OpenType
to control that.
And I'll talk a little
bit also about what
you want to do in your app
to make that work perfectly.
So kerning and ligature.
So the fi ligature is a little
controversial in Roboto.
Not everybody loves this.
But it is definitely a sign of
more sophisticated typography
that you don't just put the
letters that, in some cases,
you have these combinations.
And you have a
specifically drawing glyph
that represents more
than one letter.
And this is certainly--
this exists in Roboto.
And it's a very important part,
like especially in serif fonts.
You really need those
ligatures for the font
to display correctly.
So if, again, as you're using
custom fonts in your app,
you want those ligatures.
And the same is
true for kerning.
You almost never want
to turn this off.
The only time you might
want to turn it off
is if you've got some kind
of technical alignment
where things need to have the
consistent with no matter what
the characters are.
But in any case, as of
M, with the font feature
setting attribute,
you can control these.
These are actually implemented
as OpenType features.
And as with any
OpenType feature,
you can turn it on or off
with fontFeatureSettings.
And that's actually
a Lollipop Plus API.
So another great hidden feature
is the user proportional
and old style numbers.
And these are really
important for a more refined,
sophisticated typography.
That the default
numbers are basically
the same size as capitals, and
they're all the same width.
And being the same width
is really important
if you've got some kind
of animated display.
You don't want it to be
juddering back and forth.
Or if you've got a tabular
presentation of numbers
like a spreadsheet.
But it's not always
the prettiest display.
And if you're
doing running text,
if you're doing
paragraphs of text,
then proportional may
be a more subtle change
where you just give the
one a little bit narrower
so you don't have all
this space around it.
And then if you're really trying
to do something that looks more
like a book, something
that looks more
like traditional
typography, then you've
got these old style figures.
And those are in Roboto 2.
Those are present in the font.
And you use the Android
fontFeatureSettings
to select pnum, proportional
numbers, or onum, old style
figures.
And again, highly recommended
if you're bringing custom fonts
into your app that you have
the complete access to all
of the OpenType
features in those fonts.
And this is, again,
an L Plus feature.
Another feature that
I think is really
a powerful tool for bringing
more sophisticated design
to apps is control
over letter spacing.
So there's the default
letter spacing.
It's really tuned
for legibility.
People are getting
information on their phone.
They need to be able
to read it quickly.
And that's what the default
letter spacing is tuned for.
But if you've got
something that's
kind of larger,
more of a branding
and less of a
functional element,
then spacing it a little tighter
might kind of highlight that.
And then you can
also use wide spacing
as maybe a form of emphasis
or just bringing a little bit
more breath to your design.
So you have-- you're
no longer stuck
with just the default spacing
that's set in your font.
And again, that's
an L Plus feature.
So in Marshmallow, this is
really one of the things
I'm most excited about,
that we really stepped up
the paragraph layout.
And the old algorithm
used-- you fill up a line,
and then when once
you get to the point
where the line is full, then you
just break at the word boundary
and you keep going.
But in Marshmallow, we have this
high quality paragraph layout
mode.
And it incorporates a couple
of different elements.
It incorporates
automatic hyphenation.
And it also incorporates this
concept of whole paragraph
optimization.
So it kind of
moves pieces around
to get like a best score.
There's kind of a
score that tells you,
what is the quality
of this layout?
And it's really trying
to optimize that
across the entire paragraph.
Both of these
algorithms are based
on TeX, which is a print
typography package.
It has a very long history.
And high end print publishing
tools use this same approach.
But the parameters-- like
when do you use hyphens?
Hyphens are a little bit weird.
People are not used to seeing
them on a mobile device.
There's some contexts where
they make a lot of sense,
like if you're displaying
an e-book, for example.
And there's some
where maybe it makes
a little less sense, like UI
strings or maybe chat messages.
People are not used to
seeing hyphens there.
So we tuned the
parameters-- its heuristics.
And we kind of chose these
so that a couple of things
that people were noticing.
That if you hyphenate and
you break a partial word
onto the last line,
that is really weird.
That's something that people
have a negative reaction to.
So there's a parameter in
the tuning that kind of
doesn't do that very often.
But on the other hand,
one of the reasons
why you want to do
this hyphenation
and want to do this high
quality paragraph layout
is you want better
information density.
This is especially
important when
you have very narrow settings,
and especially true on very
small screens like watch faces.
That if you break a word,
and you leave a huge amount
of empty space, that's waste.
That's an opportunity that
you could have used that space
to present information.
So we really look at this
question of would hyphenation
bring you end lines
down to n minus 1
by doing the hyphenation?
And in that case, we say, yes.
You do want that.
You don't want to
waste that space.
You want more
information density.
And that increases
the chance that you'll
get a hyphen on there.
So this is kind of
a different tuning
than you would
expect for something
like print typography, which is
where there's kind of the most
tradition of doing hyphenation.
So one of the other
things we looked at
is this question,
do we want to have
an opt-in where your app says,
yes, I want high quality mode.
But maybe it's
considered expensive.
You know, it's too
slow to run or we
don't want to always have it.
But we tried turning it on
across the entire system
as a default and we
really liked what we saw.
I mean, you want a higher
quality presentation
of paragraphs.
Of course, if it is
not right for your app,
then please turn it off or
control the tuning parameters.
But we also had to do a lot
of work on the performance.
So it's doing a lot more work.
There's a lot more
sophistication
that's going on in there.
But overall, the amount of time
that it spends drawing text
is about the same as Lollipop.
There's some use
cases that are faster
and there's some where it's like
maybe some of the benchmarks
where we've gone backwards.
But we've really tried to make
that usable for everybody.
And so here's a demo of the
kind of profound difference.
You can see that you really see
on the left-hand side, which
is the pre-M paragraph layout.
And you can still get to this by
setting breakStrategy="simple"
in your XML.
But you see these huge
gaps where, like the word
conversation, it doesn't fit.
So OK, it just goes
to the next line.
And with the high
quality layout,
it says, OK, we
can hyphenate that.
And we can actually
get this block of text
that's very clean.
It really looks much
more like a book
and less like
computer text display.
And on the right-hand
side, you can
see it's actually pretty
eager to use hyphens.
And that's a control.
There's a default, which
is a little less eager.
It uses hyphens when they really
improve the density, when you
really improve those huge gaps.
And then there's
this setting of full,
hyphenationFrequency="full",
which is really appropriate
if you are displaying
paragraphs of text.
If you've got an app
like an e-book reader
where you're really
displaying paragraphs.
Then we recommend using
full instead of the default.
And if you want to
turn hyphenation off,
you can actually--
you can mix and match.
You can have a high
quality strategy
in terms of the optimization
of where the line breaks go,
but just no hyphens.
And that's another option.
In the same kind of
increased control
and has control
over line breaking,
we were looking at this
particular problem, a very
common pattern for UI strings.
You've got a string
that just doesn't quite
fit into the space, into
the width of the set.
And then you get
this word-- you know,
UI strings are often very short.
So this happens quite a lot
where you just have one line,
but you have like one
or maybe two words
that go to the second line.
And it just doesn't look nice.
It's not a very pleasing visual
presentation of this text.
So you can select
breakStrategy="balanced".
And that tries to line it
up so that all of the lines
are roughly the same length.
In a traditional paragraph, you
try and get all of the lines
except for the last
the same length,
but balanced really just
tweaks that one thing
and says, just make this
whole thing line up.
This is based,
again-- for designers
who are familiar
with web technology,
this is based on
Adobe's proposal
for text wrap balanced.
That hasn't become a standard.
I don't think it's
widely shipping yet.
But again, we're trying to
make the design of typography
on Android similar to the design
of typography for the web.
So I wanted to
also-- I mentioned
when I was talking about
the different languages
and the different things that
we do to change the way we
present text, that
this is really
one of the most important
things that apps can do
is to get the locale of the
text that the app is displaying
correct.
Because if it's wrong,
you'll still get the text
displayed, but things
will be degraded.
They won't be as nice.
They won't be as polished as if
you set that locale correctly.
So there's three
different ways that locale
flows into text in Android,
in Android framework text.
There's the settings,
which are system-wide,
which control a default locale.
And of course, this
is their fault.
This is what happens if
you don't do anything.
And you hope it's right,
but unfortunately, there
are a bunch of
cases, mostly when
you have multilingual users--
in America, there aren't any.
But in the rest of
the world, there's
a lot of people that speak
more than one language.
So the language that
they're viewing the app in,
the language that
they're interacting,
that they're maybe looking at
user content, might not be,
might not match the
system setting app.
So we have a
setTextLocale API, which
you can use on a text view.
And if you have metadata, if
your server knows the language
that that text is,
then we strongly
recommend that you
set text locale
on the text key that displays
that text so that the locale is
correctly identified.
And then this may be a
little bit more specialized,
like for something like
a translate app where
you may have a
single string that
contains multiple languages.
It might say the
translation of this word
into this other language
is some other word.
And you might have a
language that's just a span.
And for that we've
got a LocaleSpan.
And you can set that on
just the text in your app
that represents that span.
So what does the locale do?
I mean, like I've said,
it's important to set it,
but what happens?
How does that actually control
the way text is displayed?
And before Jelly Bean, there
was no difference at all.
Text just displayed.
But in Marshmallow,
there's four different ways
that locale affects the
presentation of text.
It changes the
font that's chosen.
And that's especially
important for distinguishing
between traditional
and simplified Chinese,
as well as Japanese and Korean.
Those are different
fonts that are unified.
It affects this local OpenType
feature lookup so that,
like there are differences in
devanagari script between Hindi
and Marathi.
And it makes sure that
you get the correct forms
of those letters, things like
Persian numerals and so on.
Or not-- well, Persian
numerals are complicated,
but the point is that if
you know the language,
then setting it will get the
correct lookups to happen
on the font.
The locale also
affects line breaking.
There's some languages
where deciding
where the boundaries
are between words, where
you can break the
line, is actually
kind of a complex question.
Thai is the most
common, certainly,
that you'll see where
there's no spaces.
And so you really, in the case
of Thai, you need a dictionary.
You need to say,
this is the word,
so that I know where the
boundaries of the words are.
And that is completely
reliant on knowing
what the language is.
If you just put Thai text
through, but don't identify
that the language is Thai,
then it gets confused
and you get in line breaks in
potentially very bad places
that don't line up
with words at all.
And then, of course,
lastly, now that we
have automatic
hyphenation, that knowing
which dictionary of patterns
to use depends on the language.
And this is-- like
most of the things
that I just talked
about are kind
of more exotic languages
to this audience,
but automatic hyphenation
is important between,
for example,
Norwegian and English.
They're both in the same script.
But if you use the
wrong patterns,
you'll get you'll
get weird hyphens.
And then there's-- like how do
you know what the language is?
And fortunately, there is
an open source library.
I mean, this is actually
mostly developed by Google,
but it's out there.
The Compact Language
Detector library,
which is now in
its second version.
It's open source
and it's designed
to be very
performant, very fast.
It's not a huge
dependency to take on.
So if you've got an app where
you're displaying messages
and you really don't
have the metadata,
you don't know where it came
from, what that language is,
but you want to ensure that
it's displayed with the highest
quality-- and of
course, that metadata
can be really useful for
lots of other things--
then we really do recommend
this Compact Language Detector.
You pipe the output of
that into setTextLocale,
and that really improves
the quality of your display.
So that's kind of all of the
prepared topics that I had.
I want to open it
up to questions.
I'm happy to answer
any questions you have.
And please wait for
the mic to come to you.
AUDIENCE: Hello.
On the topic of
custom fonts, so you
can achieve custom fonts
via-- like on simple views
such as text view, but
it's pretty difficult
to do for framework UI classes,
such as like navigation view
or toolbar.
Is there a recommended
way by the frameworks
team to achieve custom fonts
globally within your app?
RAPH LEVIEN: Yeah,
that's a good question.
I don't think we have a
mechanism for applying
a font globally across the app.
So unfortunately, I
think that is something
that you have to do with code.
But that's something that
we're interested in looking
at, making easier.
AUDIENCE: Hi.
I get a lot of requests
from design forum situations
where they want the text
to be exactly this size,
possibly because it's
aligning with an image
or something like that.
What is your recommendation
for-- what I'd really
like to do is have
the text shrink down
if it's in, say, a language
that it has more text there.
What is your
recommendation for that?
RAPH LEVIEN: That's a
very common request.
And we do not have support in
the framework for that yet.
It is something that we
are really looking at.
There are a number of
open source libraries.
One of the reasons that we
haven't implemented something
like that-- I looked at
it and one of the problems
that you get into is
that you get kind of,
how do you specify what
that behavior should be?
So you just specify kind of one
point in there, where you want
it to be exactly that size.
But there's a lot
of other use cases
where people are trying
to-- because you're
trying to line it up, basically,
with other graphic elements.
There's a lot of other cases
where people are just mostly
concerned about making it fit.
So they want kind
of different logic.
They want something that
says make it a standard size.
Make it 14 sp, unless
it doesn't fit,
and then we want to have it
shrink down to some other size.
But we don't want to have it
shrink down to below like 8,
because then it
becomes illegible.
So you get these
cases where specifying
how you want that behavior to
scale is kind of complicated.
And if and when we do
implement something
like that in the
framework, we really
need to make sure that we
cover the range of behavior
in a way that makes sense.
Until then, I'm not
going to recommend
any specific open
source library,
but there's a bunch
of them out there.
And it's likely that
there's something
that just subclasses text view
and overlays that behavior.
It's likely that
there is something
that will fit what you need.
AUDIENCE: Early
on, I saw a mention
for CSS styles being
applied to text.
Is that something is
done through styles
or is it through the
use of HTML text?
RAPH LEVIEN: OK.
So I'm sorry if
that was misleading.
It's not CSS styles in general
that we're applying to text.
There are specific attributes,
there are specific parameters
that we're-- and in
that particular slide,
I was talking about
font feature settings.
And it's like the syntax.
Because specifying
all these OpenType
features is kind
of a complex thing.
It's not just like a number
or something like that.
And so we adapted
the syntax from CSS.
It is compatible with CSS.
So if you have that particular
feature, other features
that we've got,
like letter spacing,
the name of the feature,
the meaning of the feature,
we're trying to make
it consistent with CSS.
But we haven't implemented a
web browser in Android framework
text.
You can use web view, but
that's-- there is not like
a generic CSS translator.
It's just these
specific features
that are low impedance,
or compatible with CSS.
AUDIENCE: What is
the performance cost
of the high quality text layout
strategy with hyphenation?
For example, if you want
to actually change the text
view contents.
So what is that going to
cost you at layout time?
RAPH LEVIEN: Well,
measuring text performance
is really complex.
I mean, the order
of magnitude is
that it's about the same
as simple text in Lollipop.
So it's doing more work, but
we actually took a wrench to it
and did a lot of optimizations
to make it go faster.
There's going to be some
specific cases that are
going to be a little slower.
There's other cases,
like if you're
editing a very large
buffer, that it's
going to be a lot faster.
Because we really did a lot
of performance improvement
in that area.
So ultimately, if you're really
concerned about performance,
like if you've profiled your
app and you've said, oh, my god.
I'm spending all of this
time doing the layout,
of the high quality layout.
And if you've decided that
the visual improvement of that
is not worth it in your app,
then by all means, set simple.
We have not come across-- I
can't really think of any apps
that I know of,
either first party
or third party, where people
have felt a need to do that.
But it's certainly an option.
And we will continue to
improve the performance.
This is a very
important area for us.
It's got to not jank.
AUDIENCE: Also, will there be
a support library for this?
RAPH LEVIEN: No.
Unfortunately, a
lot of the stuff
that happens in framework
text is at such a low level
that you can't really fill
it in with a support library.
AUDIENCE: Hi.
I know better than
to ask you what
are you guys going
to do in the future,
but I wanted to ask a
little about static layout
and the new method that lets
you set custom margins per line.
RAPH LEVIEN: Yes.
AUDIENCE: So I know it's not
ready to do full wrapping
around a path, which is
what I imagined when I first
heard about it.
But I am wondering,
what were you guys
imagining when you added it?
Is it just the
circular watch face,
or is there something else cool
I could, but I don't know yet.
RAPH LEVIEN: Oh, great.
No.
And that's a slide that
almost happened in this talk.
And I wanted to keep
it simple because I
wanted to talk about things that
would be for most developers.
So certainly, the
circular watch face.
So maybe I should just
explain that there's
layers of the text stack, where
text view is the one that most
of you interact with.
But underneath text
view is static layout.
And static layout does
a lot of the things
around line breaking
and paragraph layout.
And then below that is
like draw text and the kind
of very low level APIs.
And in static layout,
we have a new method
that lets you adjust
the shape by controlling
indents on the paragraph.
And so, yes.
The watch face was absolutely
a motivation for that.
We are seeing
other applications.
People are adopting
it in cases where
people are doing custom
views, rather than
just relying on text view.
One of the really nice
ones is when you just
get to flow around an image,
where you're basically
doing something like
a web style float.
And it is possible to do your
own-- to kind of roll your own,
if you've got a
path, to figure out,
based on the knowledge
of the line heights
and stuff like that, to figure
out what the indents are.
I think you'll see this
continue to evolve.
Clearly, it makes sense
to do a higher level
feature that is easier to
use, is not so low level.
But unfortunately,
it is not there yet.
Any other questions?
All right.
Well, thank you so
much for coming.
[APPLAUSE]
[MUSIC PLAYING]
