This preserves the existing behavior at the SDK level while skia
investigates a more comprehensive solution.
bug: 8986473
Change-Id: Ief82dcfd47f1ba08d28d43402b3c28694f94f2e4
This CL also updates the documenation to make it clear that the API
returns in local space, not clipped to the size of the bitmap/device.
bug: 8747526
Change-Id: I389844672ce955341863f9940c3b401ab00dc1dc
For fullwidth latin (or, more generally, a font considered as a complex
script, but not supported by the font specified), and for a font other
than a system default font, we were getting a mismatch in baseGlyphCount
between the shaping and painting fonts.
This patch preserves the original typeface in this case. In that sense,
it is a slightly more general fix for bug 8127795.
Change-Id: Ibdbfdb34eb7dc39cc8f0784a67c93c9af4ce6ab2
This patch makes segmentation into script runs behave the same in RTL
as in LTR modes - so that inherited script characters are always
associated with the preceding run. Otherwise, for a sequence such as
u+0631 u+064d u+0020, it would get split after the first character,
which would lose the ability to correctly position the u+064d mark.
Change-Id: I3c12ba1b77d18334f55e707f518be1046e6b339b
TextLayoutShaper was defaulting to the Regular-style fallback chain
for all unknown scripts. This became problematic in that the
codepoint->glyphID enumeration stage of shaping was always using the
Regular-style fallback chain for unknown scripts, and there's no
guarantee that glyph indices are compatible between fallback chains.
Defaulting to a style-appropriate fallback chain addresses this
issue, and probably unreported but related issues, as well.
Bug: 8189208
Change-Id: I6ecf531c74d71a8e4a5359d23439ccc950b0cf80
We've a number of native functions in the text layout path that take
a bidiFlags argument. We've a number of callers of those functions
passing in SkPaint::Flags in that slot. This completely breaks text
directionality for the affected functions, as
SkPaint::kAntiAlias_Flag happens to share values with kBidi_RTL,
resulting in anti-aliased SkPaints measuring text as if it were RTL,
and non-anti-aliased SkPaints measuring text as if it were LTR,
regardless of the actual text directionality. Oops!
To address the issue, this commit replaces erroneous calls to
SkPaint.getFlags() with the value of Paint.mBidiFlags, and includes
the necessary plumbing to get that value where it needs to be.
Bug: 8471481
Change-Id: I2d04b70defed3130fc1ad13f4c9098f5fce4ffde
- remove the ICU related methods and update the methods using the "reserved" argument
- update to CTS in another CL too
Change-Id: I5509736568c342d9d17bfeafc17951117ab5d3cc
getTotalClip() returns the canvas bounds even if no explicit clip
was set. This CL fixes that issue by only transfering clips that
were explicitly set to the new canvas.
bug: 8255582
Change-Id: I0144d430e7718151ad93d988fcf20b412f74b256
When provided with a new bitmap device the canvas will retain
certain information such as it's matrix and clip.
bug: 8167188
Change-Id: I20ac8a24eebc85fb7c147504a103ce9a95b530b3
# Via Android (Google) Code Review (1) and Victoria Lease (1)
* commit 'c69bce2e41c70da35e1b6a2ab5ec44469ab14c80':
fix argument mismatches in Paint JNI
Paint.getTextRunCursor() no longer has a "flags" argument on the Java
side. The native side, however, still had the argument, and was being
called with misaligned arguments, causing all manner of madcap fun.
Also, the version of Paint.getTextRunCursor() that took String as an
argument needed to lose the "flags" argument, as well, to prevent an
infinite loop in the CharSequence version of the function, which was
supposed to be calling the String version but was actually calling
itself.
Bug: 8201224
Change-Id: Iad0dabaf81185f29a082566cc64590f2ba9bc31c
# Via Android (Google) Code Review (1) and Fabrice Di Meglio (1)
* commit '336fcac31ddccc7e7a6773d03e7cb17967ebb898':
Fix bug #8194572 Chrome SIGBUS'es on launch around TextLayoutCacheKey
This reverts commit 6c0307dd0aefe9a08794b155fc03ee60ebd14f25, reversing
changes made to a2cd828b749c444d55c2c41c7dbb85088ff94b9f.
Conflicts:
packages/SystemUI/res/values-sv/strings.xml
Change-Id: Ia178efe8b14751583d47b2826bfe3d3d5463dd2e
Characters from complex scripts without dedicated typefaces were
getting baseGlyphCount counted twice: once in shapeFontRun() and
then a second time during SkScalerContext::getNextContext()
chaining.
This was a problem for text runs beginning with full-width Latn
characters - shapeFontRun() would get the base glyph count for
the typeface containing those characters, then realise it had no
typeface specified for the Latn script, resetting the typeface
to default without resetting the base glyph count along with it.
Mojibake full-width Latn characters, ho!
The same issue also affected Cherokee text, which this fix also
addresses.
Bug: 8127795
Bug: 8034351
Change-Id: I058d81cffbbf86426cc3c5aafcc91a76f4fe6b62
# Via Android (Google) Code Review (1) and Michael Jurka (1)
* commit 'c24b14481527e2f87ddb3a156b8217d32c645b10':
Don't mark recycled bitmaps as immutable
