Previous Canvas changes missed a @hide tag, so droiddoc was complaining
about a missing method since that was also hidden.
Change-Id: Ib70a9fa2e20fe32b74ba901bb289e77583164004
Adds drawTextRun as internal API on Canvas and GraphicsOperations.
Adds implementation to implementors of GraphicsOperations.
Adds state and API on Paint to control the bidi algorithm when used
by Canvas. This API is currently hidden.
The drawText changes are incomplete since shaping is not yet available
in the native code.
Change-Id: I4368048aef9545df0953a349381771603e04b619
This takes utility functions from Styled and a few other classes and
incorporates them into two new utility classes, TextLine and
MeasuredText. The main point of this is to support shaping by skia,
to experiment with how this will look, this also introduces
character-based Arabic shaping.
MeasuredText is used by code that determines line breaks by generating
and examining character widths in logical order. Factoring the code
in this way makes it usable by the ellipsize functions in TextUtils as
well as by StaticLayout. This class takes over the caching of widths
and chars arrays that was previously performed by StyledText. A small
number of MeasuredText objects are themselves cached by the class and
accesed using static obtain and recycle methods. Generally only these
few cached instances are ever created.
TextLine is used by code that draws or measures text on a line. This
unifies the line measuring and rendering code, and pushes assumptions
about how rtl text is treated closer to the points where skia code is
invoked. TextLine implements the functions that were previously
provided by Styled, working on member arrays rather than
explicitly-passed arguments. It implements the same kind of static
cache as MeasuredText.
TextLine and MeasureText simulate arabic glyph generation and shaping
by using ArabicShaping, ported with very minor changes from ICU4J's
ArabicShaping. This class generates shaped Arabic glyphs and Lam-Alef
ligatures using Unicode presentation forms. ArabicShaping is not
intended to be permanent, but to be replaced by real shaping from the
skia layer. It is introduced in order to emulate the behavior of real
shaping so that higher level code dealing with rendering shaped text
and cursor movement over ligatures can be developed and tested; it
also provides basic-level support for Arabic.
Since cursor movement depends on conjuncts whose formation is
font-dependent, cursor movement code that was formerly in Layout and
StaticLayout was moved into TextLine so that it can work on the shaped
text.
Other than these changes, the other major change is a rework of the
ellipsize utility functions to combine multiple branches into fewer
branches with additional state.
Updated copyright notices on new files.
Change-Id: I492cb58b51f5aaf6f14cb1419bdbed49eac5ba29
Merge commit '0db37997366a4d781af48be758a9d90b6d07d7d5' into froyo-plus-aosp
* commit '0db37997366a4d781af48be758a9d90b6d07d7d5':
Revert to previous text selection behavior
There was a new behavior that starting "Select text" would allow you to
swipe from beginning to end and immediately copy that. This change
reverts to the previous behavior that "Select text" will start where
your cursor is currently and any tap will extend the selection from that
origin to the point of the tap.
Change-Id: Ib955cc8d62a652f518435953da2f54e810d9dfb0
Changes the internal representation of direction information in the Directions object to be a visually-ordered list of start/length+direction pairs instead of a list of directionality inversion offsets.
Rewrite Layout.getOffsetToLeft/RightOf to use run information instead of width metrics.
Remove java Bidi, use native. Switch bidi tests to test native, expect levels instead of dirs.
Add test of directionality. Leave in switch to turn new code off and restore previous behavior for now.
Change-Id: Iea8bb46c678a18820e237c90f76007a084c83051
This is a fix for http://code.google.com/p/android/issues/detail?id=907. Note that
that issue was declined without comment, but the bug (while incredibly minor)
does exist. This can be seen on the facebook app, as well as many third party apps.
Change-Id: I8f1449c47228f5f757a5baf389656e51c817b150
The code that was supposed to keep this from happening was not being
executed when the text was all ASCII.
Bug 1899722
Change-Id: Ifc97a4423d6136e19abbc4c82eb36ac0216ce415
This is the framework part, moving classes around so the framework
no longer needs to link to android-common. Makes some APIs public,
others that didn't need to be public are private in the framework,
some small things are copied.
Fix potential invalid array access if start index is before the
beginning of the array or start + count is past the end of the array.
Update Javadoc for mirror to reflect the usage of "start" and "count".
Change-Id: I7e596de8eae5c518a2b4ff0d28604bd9c59f9d9d
Currently there is no way for an application built against the API to
access East Asian Width data from ICU. This adds an API for applications
to use to access it for correct drawing of international characters.
Change-Id: Iab50698ee555ae2ca8ab4b242cc14aa6e0dc3b48
Note that Rfc822Tokenizer.tokenize(CharSequence text) is already in the SDK
and it just wraps the version I am unhiding.
Change-Id: I1ac3b405a04df960fc1e65ca4797d6f5adf85dc4
The goal of this new feature is to enable users to select
text without having to go through the cumbersome context
menu. Now users can simply execute a
onepointfivetap-and-swipe gesture to select text.
Onepointfivetap is similar to doubletap gesture (where a
finger goes down, up, down, up, in a short time period),
except in the onepointfive tap, a users finger only needs
to go down, up, down in a short time period.
I don't think this change should cause any waves, because
this interaction is consistent with the select interaction
using a computer-mouse and computer-screen, and i've
checked and it seems to be implemented on other touch-based
phones as well.
Change-Id: Iba84f7316a647e963ba7c57ca608bfdc3bb438b8
This change fixes the context menu trigger behavior while
the user is selecting via touch. How if a user is selecting
text via dragging their finger, to trigger the context menu
they will have to lift their finger up, then issue a
longpress. This is consistent with the behavior of selecting
via the trackball.
Merge commit '946bfa490a4df62bfb48e8017c329b052e3e905e' into eclair-mr2-plus-aosp
* commit '946bfa490a4df62bfb48e8017c329b052e3e905e':
Allows users to scroll while in select mode.
This change allows the user to select-n-scroll. While a user
is in select mode, and they try to scroll, the textbox will
scroll in the direction of the selection, and expand the selection.
Merge commit '7c42703082574638ecaa88ea18b0cc94bfabea2d' into eclair-mr2-plus-aosp
* commit '7c42703082574638ecaa88ea18b0cc94bfabea2d':
Improves the touch-based text selection UI in text boxes.
Merge commit '67d9aa15b6c6217a7d3b7b017924af132d048e56' into eclair-mr2-plus-aosp
* commit '67d9aa15b6c6217a7d3b7b017924af132d048e56':
Add isPrintableAscii() and isPrintableAsciiOnly() to TextUtils.java as hidden methods, and make vCard code use them.
With this change, when a user is in "text select" mode, they
can swipe any part of the text. This changes the behavior of
the touch-based select in 2 ways (behavior for cursor-based
select remains the same):
1. You can now indicate where your select will start. Before
this change, the select always started at the last cursor
position.
2. Selection will respect word boundaries. Before this
change the selection would be character to character. Since
users don't have a fine grain level of control over touch
events, this would often lead to incomplete selections.
