The old logic for fake bolding results in no fake bolding for a bold
span on a light weight (300) because the target weight (600 in this
case) didn't meet the condition. This patch fine-tunes the threshold
to enable fake bolding for this.
Bug: 17587185
Change-Id: I04abd00a74240cbed79c417f81486aa2158b2806
Fractional advance widths were causing subtle problems with text
positioning when the same text was drawn with different spans in the
hwui renderer. Quantizing the coordinates on layout (as opposed to
waiting until the renderer draws the glyphs) solves the problem.
This patch also fixes a discrepancy between x position and advance
widths when letterspacing.
Bug: 17347779
Change-Id: Ia705944047408c2839d5ad078eefd6bbec446872
This patch finds an appropriate fallback font in the case where no font
directly maps the requested character, but a font does exist for the
character's canonical decomposition. This yields correct rendering of
compatibility characters such as U+FA70.
Bug: 15816880
Bug: 16856221
Change-Id: Idff8ed6b942fec992a0815a32028b95af091d0ee
This reduces another allocation (last one?) we were doing when
fulfilling shaping requests from the cache.
Bug: 17111260
Change-Id: Ieb8ae1ccfcaacedb257e1e9263777f10623aaf98
C++ local var initialization always tricks me. Previously, Layout
didn't have a constructor, which meant that defining it on the stack
left mAdvance uninitialized. This was not an issue when we were doing
"new Layout()", since that invokes zero-initialization, but was an
issue for the skipCache path that was allocating layout on stack by
just "Layout l" instead of "Layout l = Layout()". To avoid surprises,
add a constructors that clears everything.
Also adds reset() method to reset the layout for reuse.
Change-Id: I3e02f00da9dd7d360abe13f63c310f6882292d0a
The U+20E3 COMBINING KEYCAP is used in our fonts to generate an emoji
rendering of ASCII numbers and letters through GSUB. For that to work
we need to choose the same (Emoji) font for the character coming
*before* the COMBINING KEYCAP character.
This is a special-case of a broader need to choose fonts per grapheme
cluster as opposed to per character, but for now, special-case U+20E3.
Bug: 7557244
Change-Id: I958e5a01068df8495bbb9bc3b9ed871cea1838b6
We are stack-allocating MinikinPaint objects in Minikin clients, and
without a constructor adding new members to the struct cannot be done
without updating all clients (only one right now!).
Change-Id: I4170f16498bb6b07cb795495011aca58087ed0bd
Replaces invalid unicode with replacement character U+FFFD and always
makes forward progress.
Bug: 15849380
Change-Id: Ic59ef6c64b0f5c4450bcae61597adcc269d6e7c5
After update to HarfBuzz 0.9.33 we don't need this anymore. HarfBuzz takes care of invalid input and passes U+FFFD to us.
This reverts commit 29eb45e667be81d37f29fcce2adccb8c5e6d5ada.
Change-Id: Icfd0dc836a8d684fb1723fc215aa01f99639ff59
When a run has no cmap coverage in any font, use the base font. Most of
the time, this will cause rendering of the .notdef glyph, which is
preferable to displaying nothing. In some cases, Harfbuzz may be able to
decompose the characters (not in the cmap) to ones that are, in which
case we'll render those, as long as they're in the base font.
Bug: 6629748
Bug: 15816880
Change-Id: Ibb1b9242c83626e0c7db363ad65ce44a967a005e
Proper Japanese layout requires sophisticated rules for spacing
punctuation, not just turning on the "palt" (proportional alternate)
feature. Until we can support the whole set, roll back palt.
Change-Id: If2359c529b70b1dd45dddc00e5f4aa1c91f8b0e9
This patch includes an implementation of grapheme cluster breaking,
which is especially useful for repositioning the cursor for left and
right arrow key presses. The implementation is closely based on Unicode
TR29, and uses the ICU grapheme cluster break property, but is tailored
to more closely match the existing implementation and expected behavior.
Part of a fix for b/15653110 Improve behavior of arrow keys in EditText
Change-Id: I8eb742f77039c9ab7b2838285018cf8a8fc88343
Fixes b/15734816 In the text "Wi-Fi", "-Fi" appears bolder than "Wi"
The problem was caused by "stickiness" in choosing fonts, where layout
would prefer using a font used for preceding characters as long as it
mapped the following characters in a run, in favor of the "best match"
rules. This patch adds a whitelist for making the stickiness more
conservative, only applying it for characters necessary for correct
shaping (ZWJ and ZWNJ in particular) and basic punctuation, where it is
desirable to match the style of the preceding text.
Change-Id: I1cf116879f074a5a71c351846707bfdd07b0d320
