All variations of getRelativeTimeSpanString() now properly handle dates
that are in the future. Prior, the version used by
getRelativeDateTimeString() would occasionally show the time instead of
a date when the future date was the same weekday as the current weekday.
This resulted in the time output being duplicated, eg.: "11:23, 11:23"
Change-Id: If20972a6942cce792fa233437f94dedfb71379f3
Signed-off-by: Steve Pomeroy <steve@staticfree.info>
We were doing line breaks after punctuation as long as they weren't
surrounded by digits. This is a misinterpretation of the Unicode line
breaking algorithm. Punctuation (class IS) is not hugely different than
the default classes (NU and AL) - there are breaks after punctuation
that are allowed (for example, followed by an open parenthesis), but
we're not implementing the algorithm with anything near that level of
fidelity.
The long term fix is to really implement the algorithm. In the shorter
term, the easiest thing to do is to remove the special case altogether.
Change-Id: Ic4dc3216c2a4191fbb7cfa06e9dc038d1a56398c
Cherry-pick of I7f1b0d49a2ece957a7b9b5d65d48385bf2c2a668 from master.
I've also provided TextView.setTextLocale() for use in single-language
TextViews.
Change-Id: I5692859bfd2aafc284172454d943afc250b22535
The mPos field in the MeasuredText object is relative to the start of
the text (mTextStart), but the pos passed in by the caller of the
setPos() method is relative to the character sequence. When spans
overlap break boundaries and the paragraph doesn't start at 0, the
result is an out of bounds error. This fix uses the correct offset.
Change-Id: I64ef06df0eb06f75aedd25de97e9f347eeb52979
The mPos field in the MeasuredText object is relative to the start of
the text (mTextStart), but the pos passed in by the caller of the
setPos() method is relative to the character sequence. When spans
overlap break boundaries and the paragraph doesn't start at 0, the
result is an out of bounds error. This fix uses the correct offset.
Change-Id: I12c7a2311a9bdbbea7ab21554a922b7f665a17bf
Skipping spaces at ends of line used to be done only when ok != here
(a potential line break was found).
Moved this logic up one level to handle all cases.
Also moved maxLine test in the block that actually adds a new line.
Updated the unit tests accordingly.
Change-Id: Ib10bc838b1ffa5b8a60259ea4b622d9fecb2ec70
Bug 6598784
The algorithm uses three imbricated loops:
- paragraphs
- span regions (called "blocks" in that description) in these
- characters in these
We can ignore the paragraphs and assume paraStart==0.
The span region loop cuts the text into blocks of text which share
the same set of MetricAffectingSpan spans applied to them. Note that
spanStart and spanEnd represent such a range, and not necessarily an
actual span range.
The third loop then iterates over the characters of these blocks, and creates
a new line (calling out() as soon as the width has been reached.
The core of the problem comes from the 'nextSpanStart' variable.
It is used to restart the block loop from a previous position in case
a line has been created that does not intersect with the current block.
However, in case the current block is larger than the width of the text,
the character loop is going to create other lines of text before we exit the
j-loop. Going back to the block loop, we reset spanStart to the nextSpanStart,
which may be too far back in the text. As a result, the same range of characters
is measured again.
The (spanStart == spanEnd) test was used to handle the case where
nextSpanStart was indeed assigned to a value different than spanEnd.
This fix simplifies this logic and removes the nextSpanStart variable:
When the created line ends before the current block (here < spanStart), we
immediately exit the character loop, re-starting the block loop from the
current position.
Patch 4: added a fix in measured to handle overlapping character ranges.
Change-Id: Ie71b3cf4018b332e335ea916fef08acb43a6679e
Bug 6642222
Using setMaxLines(0) and setMinHeight(30) causes a crash
because Layout#getLineRangeForDraw() returns a [0,0] interval
in that case.
Accessing the Direction in draw causes a NPE.
Change-Id: If50f9b554e3cdc598a721b623992e9196982838c
This change is analogous to Ic0e9f1bbd8cae9fdd3a6d1d015bb9224c8be545c
in WebView, and depends upon the same Skia change that that CL makes
use of.
This flips the "fake bold" flag on for bold fonts in
TextView.setTypeface(), with the expectation that Skia will ignore
the flag if the final typeface used to render the glyphs is already
bold. It also does the same for StyleSpans, TextAppearanceSpans,
TypefaceSpans, and the Switch widget.
With this, fake bold should work uniformly across all scripts - if
fake bold works for a primary typeface, it should also work for all
fallback typefaces.
Bug: 6629786
Change-Id: Id3b8639ab0df83052ffd82809cb12adaacc1d46b
Make clearer how the platform is handling key events following some
unfortunate uses by third party applications. Also highlight the
changes in Jelly Bean default keyboard.
Bug: 6566711
Change-Id: Ibcdaf54c6d629fd0733529bfe2fffc82f555f084
Bug 5763685
To improve performance, preventively cut the the into display
list of 3-10 lines of text. Further updates to small parts of
the text (such as adding an underline on a word) will only
invalidate and redraw the affected sub display list.
DLs are aligned with paragraphs, just like they will be during
text edition.
Change-Id: I0d60debc7fdaea8b29080a6eacb2d60205e7d547
Bug 6448052
The empty EXCLUSIVE removal condition was incorrect.
Also changed the unit test the didn't catch this problem.
Change-Id: I5576d830cdfa6cc3716c878fb698695a2978b296
Bug 6343982
Finally deeply understood the meaning of the POINT and MARK flags.
Updated the Spanned documentation to reflect this.
Updated tests to come.
Change-Id: I400d56b7b4929bc1e7eb4f0497d8e081ee23682e
An editable TextView caches text rendering inside an adaptive
number of sub display lists. The bounds of these use to be those
of the entire View.
This CL creates block display lists with tighten bounds, so that
(a still-to-be-implemented) quick rejection can occur.
Also cleaned-up the contradictory translations that were used to
handle the TextView's internal scroll and removed the invalidation
of display lists in that case.
TODO: When internal scroll sets a tighter clipping rect, quick
reject the creation and display of the clipped display lists.
Also renamed blockEnds to a more explicit blockEndLines.
Change-Id: I7d79bea78d06d19b6935aef75ff7aa7df2594050
Bug 6344997
The early exit we used to do when both replaced and replacement
strings were empty has been added back.
Only this time it correctly also makes sure no spans from the
replacement string would get added with a 0-length.
Change-Id: Ifc38a7e3619c57aa7647c0a8e63d7627d86f1036
Found while tracking bug 6326750
A bug in the SpannableStringBuilderSpanTest JUnit CTS test was hiding
this problem.
Also removed the instanceof test on SpanWatcher. All spans, including
those implementing this interface should be copied.
Change-Id: I5233818fb0c08ab56477720db932a5be453e88ee
When using the clipboard, ACTION_SEND, etc., you can now supply
HTML formatted text as one of the representations. This is exposed
as a set of methods on ClipData for building items with HTML
formatted text, and retrieving and coercing to HTML (and styled)
text. In addtion, there is a new EXTRA_HTML_TEXT for interoperating
with the old ACTION_SEND protocol.
Change-Id: I8846520a480c8a5f829ec1e693aeebd425ac170d
Bug 6331765
A call to replace was previously not sending any span modification to the
attached span watchers.
Change-Id: Ic9e4a8ac0210e422961adfb18e205d80531889fe
This is a new version of CL 179343 which had to be reverted.
This problem of the previous CL is that the ComposingSpan that
was part of the replacement text was correctly added during the
replace but was immediately removed because it had a zero-length
size.
Swapping the add and remove blocks solves the problem.
The new non-zero length enforcement also revealed a bug in the
spell checker where we were creating useless range spans.
Change-Id: I59cebd4708af3becc7ab625ae41bc36837f1a1cf
