This addresses b/16486549.
This change updates public documentation to specify the behavior of
LeadingMarginSpan2s. This change specifies what happens when a
LeadingMarginSpan2 is combined with other LeadingMarginSpans. This
behavior was not previously documented.
LeadingMarginSpan2s specify the number of lines used for the leading
margin. When laying out and rendering, for all LeadingMarginSpans, the
first line margin is applied for the number of lines specified by the
LeadingMarginSpan2.
Previously, this behavior was slightly buggy -- the LeadingMarginSpan2
affected all LeadingMarginSpans when laying out text, but not when
rendering.
This change is designed to cause the least amount of breakage in
existing code while achieving consistency with the way
LeadingMarginSpan2 is handled in layout and drawing.
For the most common use of LeadingMarginSpan2 -- getting a multi-line
first margin in the first paragraph of text in a layout -- this should
cause no change in behavior. For any other uses, the old (buggy)
implementation most likely did not exhibit correct behavior to begin
with, so developers were most likely not relying on that functionality.
Change-Id: I6f69df09c0130e703458e65bf3eaac4a905df56e
.. and use Locale.getScript() instead of ICU.getScript.
bug: 15876704
(cherry picked from commit 08b3516984)
Change-Id: Ifac179e0577d66062f32c95372b631bf574dfdf9
This fixes b/16510772.
When measuring paragraphs, leading margins should be taken into account.
When computing line width, the margin should be added to the absolute
value of the extent (there were missing parenthesis). Both of these
caused views with leading margins to be rendered incorrectly.
Change-Id: I5029b2790a249192a858eb226d7b793d0622a70d
The reason for separate classes for each type, instead of a more flat
structure is to enable easy discovery of the available arguments that
can be set. For L we'll have about 12 types with 30 arguments and
almost all of the arguments are type specific. In future releases
we'll introduce more arguments. With editors that have code completion
one can construct a span without having to consult the documentation.
For now it only contains Text and Cardinal types.
Change-Id: I94531e600133d9f4f59a4170cceef1ee7a360ca7
(cherry picked from commit 90b095aabd8a5c43723821dda37354fd2beb38fb)
The TtsSpan can be used to provide addtional data for TTS engines.
For now it only includes the types text and cardinals, but more will follow.
Change-Id: I31392dd413c0902ba4ce702fa3307253c90c618f
Clusters were broken incorrectly when in narrow views (when the width of
the cluster was greater than the width of a view). Also, out() calls
were modifying fm, so clusters that were too wide were not positioned
correctly.
Change-Id: I521f8dc6338f5f1de6858af3f0c0bd320aa46bc0
Incorporate patch from Logitech (donated under AOSP license) to the
framework to add mouse-based text selection to ArrowKeyMovementMethod.
Bug: 14652753
Change-Id: Iab264bb954b72ccedfada763eba8f13ef37a4578
The dirFlags and bidiFlags enums are distinct, and have different
meanings. The former is a determined direction for a run of text, while
the latter is a request for the bidi algorithm. They have been used
interchangeably, and this has caused some problems, notably running the
bidi algorithm needlessly when the direction for a run is already
determined.
This patch cleans up the confusion, by always naming each occurrence
explicitly "boolean isRtl" or "int bidiFlags" (the previous code often
just used "int flags", which added to the confusion), and converts
between the meanings when a function takes an isRtl argument but passes
it to another function expecting bidiFlags.
Fixes b/15089607 Clean up bidi flag mess
Change-Id: I410b6604376e853dd12c255e7f5a9d2b9a310dd9
SpannableStringBuilder should throw an exception when the
parameters to #insert and related methods are in the wrong
order.
We'll have to reopen b/9570771 and deal with it separately.
Bug: 14965397
Change-Id: I01847e0010d23f98ad3def8ba030d36570528900
This fixes a CTS test for Wearable. We cannot check for FEATURE_WEBVIEW, because
there's no way to get a PackageManager from within these static methods.
Bug: 15131296
Change-Id: I7bf7564b6209f330a413ed54a94be1e07fedb30d
The CTS test expects an ArrayIndexOutOfBounds exception when passing in
an unreasonably large value for len. Since the actual implementation was
causing an integer overflow, we were getting a different exception.
Since integer overflow is potentially dangerous, this patch tests for it
and throws an exception explicitly.
Change-Id: I0420c06185d33d130853861d25d4f65b06fe0dfa
The previous fix did not work when the text was ellipsized, because the
test for whether the line was the last line was incorrect. The new test
handles both the end of the buffer and the case where it is the last
line because of ellipsizing.
So this should be the proper fix for bug 14276128 Clipping at bottom of
TextView when lineSpacingMultiplier < 1
This version of the patch also handles the single-line case (which is
computed in BoringLayout rather than StaticLayout).
Change-Id: I88791acc2aa493cc8c599b374f4d213571260b4b
The previous fix did not work when the text was ellipsized, because the
test for whether the line was the last line was incorrect. The new test
handles both the end of the buffer and the case where it is the last
line because of ellipsizing.
So this should be the proper fix for bug 14276128 Clipping at bottom of
TextView when lineSpacingMultiplier < 1
Change-Id: Iac5c96f2273142031c18a27f504f7d6d5fcf823e
Avoid applying "extra" linespacing to the last line of a layout, because
when that is negative, it causes clipping.
Change-Id: I4cc8792fd3444e4118604cc3d0f816d59dfc1e74
This is a fix for bug 7615701 TextView: calling setText with long
strings causes ellipsize to not work correctly. The problem is that the
"break" when the last line was ellipsized did not fully break out of
both loops of the processing logic, but only the inner loop. This
caused the outer loop to restart at the next span, causing the next span
boundary to overwrite the line end of the last visible line.
The fix simply returns from the function in that case, as there is no
further processing needing to be done.
Change-Id: I5b34233ffba6f0f6f1c12b9565b4fc53e83a4892
ExtractedText#partialStartOffset and #partialEndOffset are
from the app, that sets it as it sees fit. We need to
validate them so that we don't crash.
Still emit a warning if this is the case, as this is
not expected.
Bug: 9570771
Change-Id: Id9d6babd1620da39bf0e454b14d7ce716bd9d9d3
