DynamicLayout reuses a StaticLayout.Builder object to avoid having to
allocate. There is a "finish" method that releases any expensive
internal state of the builder object, but it didn't release a
reference to the text object (which in turn may contain references to
lots of other things, especially if it's a Spannable).
This patch releases the text, as well as a few other arrays, at time
of finish.
Bug: 22822416
Change-Id: Icc8b6cd41a9a2d11689df7bd1b9f524c6524f706
This patch sets up an "empty" hyphenator, which it uses by default
for locales in which there is no hyphenation pattern data. This has
the effect of enabling soft hyphens (U+00AD), which were otherwise
disabled, because the "no-hyphen" code path didn't consider them.
Bug: 19605972
Change-Id: I4dcb95cee8edc48495f7c38736f5abf26fa04935
The existing implementation of handleText() in TextLine laid out
text to the end of the context. However, in cases where the text is
broken into multiple style spans, it's only valid to lay out up to
the end of the style span. This can lead to inconsistent
measurements, especially in the presence of legitimate zero-width
characters such as bidi control characters and zero width space.
This patch changes the invocation of getRunAdvance to measure only
within the style span.
Bug: 22589743
Change-Id: I027f5e77db27ddf9596ef20adcad7e62a82b41de
The default has been 'true' for eternity in the code. But the
documentation was mistakenly saying it was 'false'. Going with the
code, since there are people out there relying on the code continuing
to work the same way.
Bug: 22557371
Change-Id: I6f4e7b2052d0cc30d41e8ccf2b9a5c6111fa0ab7
Previously, users of the results of formatFileSize() and
formatShortFileSize() needed to unicodeWrap the results themselves
using BidiFormatter, which resulted in several bugs and
inconsistencies across the platform when they didn't, especially in
Hebrew and Urdu locales:
Hebrew and Urdu use Latin abbreviations like 'MB' for file sizes
which cause undesired reorderings (or incorrect detection of the
string direction when the formatted file size starts the string).
With this patch, the results are now bidi-wrapped before being
returned if the locale of the context passed in to the formatter is a
right-to-left locale.
Bug: 22237132
Bug: 22273176
Change-Id: If076636d15828fc810feef6f0fa8806ef52aed5d
The existing documentation is very terse and users were getting
confused whether the method escapes HTML metacharacters or not. Expand
the description a bit and explicitly state that metacharacters are
escaped.
Bug: 17456925
Change-Id: Icaae7fe1344629de5c0860674f3913781de18013
An app setting maxLines = 0 is an edge case, but it can happen. We
had some logic that would index an array at -1 in that case. This
patch just skips the fixup of the ellipsis line break in that case.
Bug: 22353342
Change-Id: I940cf0782b319010f5aedf75b9291df4ac2976d8
Bug: 22378829
Every time setText is called a BoringLayout is created.
BoringLayout internally creates a new Paint called mWorkPaint.
However, creating a Paint turns out to be somewhat substantial
amount of work, and mWorkPaint is never actually used. Deleting
this shaves off roughly 50ms and 1,000 object creations during
a fling on a listview.
Change-Id: I5d03402b9027df6ce0f3e58160752c66c69a4d2d
This patch refines the crude check for potential RTL characters, based
on ranges containing RTL scripts and format characters that affect
bidi. This will make it much less likely that a StaticLayout will be
chosen instead of a BoringLayout.
Bug: 22328919
Change-Id: I9a0ed9b3f3373069052de21c836b3372f175430f
The old code made invalid assumptions about read() behavior and
failed to clean up properly in case of error. This patch changes the
file reading to use IoUtils.readFileAsString, which handles that.
Bug: 21020457
Change-Id: If9b54955c20a20a4ed5e8381d0c7e9c920d0639a
The implementation of indendataion had two issues. First, the indent
pattern would restart on a new paragraph, which created problems when
a multi-paragraph text would flow into a shape. Second, the indents
didn't affect drawing position, which is ok for centered text but not
most of the other alignments. This patch fixes both.
Bug: 21904268
Change-Id: I53a3eb1c192fc0f8f0beace304832eed61b38497
WordIterator's getEnd/getBeginning methods does not support the needs
for word boundary detection in text selection. Consider the words
AABB (where AA and BB are each words). If getEnd is given the offset
on the boundary between AA and BB, it would return that offset since
it is the end of AA. For text selection we always want the "next end"
if available.
This CL adds two methods to word iterator that return the next end
and previous beginning.
This CL also alters the code in Start/EndHandle to use the x value
and current / prev line positions to determine if the user is
expanding or contracting the selection.
Bug: 21305292
Change-Id: I6e7a83e53e245d71e43d78f1957f844f2ed1cdfb
When we forget a private partition, ask vold to also forget the key
for that partition GUID. This means we need to track both the
filesystem UUID and the partition GUID for a private volume.
Bug: 21782268
Change-Id: Icda1cbb65539d61dacc663428daf3d1a2e4c313e
Per UX, default strings should have space between value and units
resulting in "12.3 GB". Add a formatting variant that returns the
various components for callers who want to build their own strings.
For now there is only one mounted emulated volume at a time, and
it's always the primary storage, so give it the default rootId to
keep old Uris working.
Change-Id: Ifcc72a91a6b397ee65dc92642153286186eb64ac
In current implementation, ellipsis is applied after
coptuting line breaks without limiting line count. As a
result, ellipsis can be skipped or- wrongly applied because
the breaks are computed to fit with the width.
With this change, the last line and overflowed part are
treated as a single line when the number of breaks exceeds
the remaining line count.
Bug: 6615676
Bug: 18514378
Bug: 20177499
Change-Id: I1d90e299404960cdd22746bad572411b119f7360
Improve wording of javadoc for nextSpanTransition() to accurately
reflect the actual implementation.
Bug: 19274845
Change-Id: I8f8fb6a21a8cbcc26fefb63164a6943431d16089
StaticLayout.Builder used "setTextDir" as a shorthand, but it's not
as clear as spelling it out. So, setTextDirection.
Bug: 21572282
Change-Id: Ia94476562d70678f963196b87bb63511d30836b6
If a developer extends an existing ParcelableSpan and overwrites
writeToParcel, TextUtils will crash when attempting to unparcel
since the span type ID is not accurate. This CL makes a separate
framework-private method for writeToParcel to ensure that even if
a developer extends a ParcelableSpan class, they won't modify the
parceling or unparceling code that's tied to the span type ID.
Bug: 21274544
Change-Id: If4c3506a55999df7a3b6d87cb8d550235d7a02c6
Commit a40d2447b6f516116135ee7f126579771ba98a2c made the
case consistently "as for the beginning of a sentence".
This updates the docs to reflect that. Previously the
result depended on the string returned (e.g. "Tomorrow"
was capitalized in English) and the casing varied
within and between locales.
Bug: 20247811
(cherry-picked from commit 0e1c0e11e4)
Change-Id: I7b48958725b32b13bee00347585472f8073e7761
TextLine used to use getTextRunAdvances on a substring to compute a
cursor position, but this had a number of problems, especially when
the substring is a wider than the full string (as can happen in
certain Tamil ligatures).
This patch changes the implementation to use getRunAdvance, which was
explicitly designed for this use case.
We should also change Layout.getHorizontal to use the dual
getOffsetForAdvance, but that's basically a performance optimization,
the functionality should be basically equivalent.
Bug: 21125816
Change-Id: I669b85eaecfbf6f7aa6c6a9dddbf1a210eb94571
This loads hyphenation data for the languages we currently provide at
initialization time. It also has a poor man's locale fallback
mechanism for finding hyphenation patterns where the locale doesn't
exactly match what may be available and caches the results.
Bug: 20088132
Change-Id: If7b2a8d5295df9cb2bdae7418df27bf77fb44e58
This patch adds plumbing to TextView and StaticLayout to control the
frequency of automatic hyphenation used in laying out paragraphs.
Bug: 21038249
Change-Id: Ib45de190eb0a1ed738e69fd61f2b39561b11aec7
Previous getWordEnd and getWordStart functions would return a boundary
rather than a word end / start boundary in some cases. This behavior is
most evident when moving between short lines -- the handle would go to
the next boundary rather than the word end on the next line (and the
start handle would go to the word end rather than the word start on
the prev line).
This CL ensures that word or punctuation boundaries are returned and moves
most of the punctuation boundary logic into WordIterator since it makes
a bit more sense there.
Bug: 21030788
Change-Id: I96c6aff7f2c213aa3c4f66ac87ca913ca16fd347
This treats punctuation as "words", so groups of punctuation will be
selected together, i.e. "Hmm... yay!!!" would be treated as four words:
Hmm-...-yay-!!!
Bug: 19950062
Change-Id: Ic9514c524092734fad1abdf19a736bfa1406157b
