We were not taking context start into account when deciding whether
to split a ligature, which was causing inconsistent behavior. This
patch consistently references the widths array relative to the start
of the context.
Bug: 21549197
Change-Id: I7c71e10c1af84354fefe782fc0b87120016e6555
Very long words cause O(n^2) behavior. These are unlikely to happen in
real text, but do happen with synthetic strings, so in those cases we
just disable hyphenation.
Bug: 20790394
Change-Id: Idf957dd40b24efe1476f619f17093a48b5bc56f7
Three hyphenation frequencies are now supported:
kHyphenationFrequency_None, which turns off both automatic
hyphenation and soft hyphens.
kHyphenationFrequency_Normal, which has aconservative amount of
hyphenation useful as a conservative default.
kHyphenationFrequency_Full, which has a typographic-quality amount of
hyphenation useful for running text and tight screens.
Bug: 21038249
Change-Id: I2800f718c887c9389a1a059d7ec07d7fa2ca1dee
In a paragraph with a trailing newline, the width of the newline
character was included in the line width for breaking purposes,
basically as if it were a non-breaking space. This caused a
discrepancy, where Layout.getDesiredWidth() suggested that the text
would fit in a single line, but StaticLayout would break it because of
the added width of the newline character.
The proposed fix is simply to consider newline to be a space that
disappears at the end of a line.
Bug: 20152308
Change-Id: I539574c5b8ea892c8ed6aca6c59e90ccdf74a680
New functions for computing the correspondence between cursor
position and advance, respecting grapheme boundaries.
Change-Id: I620378d5f64cd74300cd43db522adeb555825dff
The name "margin" conflicts with another meaning, so we're making the
name in the public api "idents" and the code consistent in naming.
Change-Id: I9170116b4d972e4b25f0f319e78376310288eb41
In order to support layout in non-rectangular regions, the LineWidths
object needs to accept an arbitrary array of margins. This is
implemented in addition to the existing firstWidthLineCount/restWidth
mechanism for convenience, though using only arrays would have the
same expressive power.
Bug: 20182243
Change-Id: Iea96bca1a92012314ac27e617c67f306c1f1b2f2
This patch adds hyphenation using the Liang hyphenation algorithm,
similar to TeX. It also improves the optimized line breaker so that
it works correctly and efficiently even when the line width is not
constant (there is a specialization for constant width, which is
probably worthwhile, but performance TODOs remain).
Still to be done:
* hyphenator has many shortcuts, only tested with English
* interaction between punctuation and hyphenation is problematic
Change-Id: I2d94a1668ebc536398b7c43fcf486333eeb7c6aa
This patch adds a LineBreaker class to Minikin, which will be used for
computing line breaks in StaticLayout. The version in this patch
contains basically the same functionality that existed before, but
hopefully better performance and an interface that's suitable for more
sophisticated paragraph layout.
Note that this version contains a high quality strategy, which mostly
works but doesn't respect varying line width.
Change-Id: I02485d58b1e52856296a72cdd4efd963bc572933
Adds a "HyphenEdit" field to the Minikin Paint object, which represents
an edit to the text to add a hyphen (and, in the future, other edits to
support nonstandard hyphenation).
Change-Id: Ib4ee690b0fe2137e1d1e2c9251e5526b274ec3a7
Previously, HarfBuzz's default fallback to compatibility
decompositions resulted in Mathematical Alphanumeric Symbols getting
rendered as normal letters and digits when there was no font
available to render them. This patch disables that fallback, to
ensure they are displayed as tofus.
Based on a patch by Behdad Esfahbod.
Bug: 19202569
Change-Id: I357f172302448d4ab0b24efc86119f1977b5996b
For build-system CFLAGS clean-up, fix unused variables.
Reorder initializer list to initialize in the order of member
declarations.
Change-Id: I64358b2dcf0e39d0f4e18fdc3473de867f84fcba
This will significantly reduce memory usage and also speed the creation
of new font families. In particular, the coverage bitmaps for the fonts
in the fallback stack will be computed once in the Zygote, rather than
separately in each app process.
Bug: 17756900
Change-Id: I66f5706bddd4658d78fe5b709f7251ca9d2ff4f8
This will significantly reduce memory usage and also speed the creation
of new font families. In particular, the coverage bitmaps for the fonts
in the fallback stack will be computed once in the Zygote, rather than
separately in each app process.
Bug: 17756900
Change-Id: I66f5706bddd4658d78fe5b709f7251ca9d2ff4f8
Some fonts contain a cmap segment for char 0xffff that contains an
invalid rangeOffset. This was rejected by the existing code, which
means the font is considered to have empty Unicode coverage. This patch
just discards the invalid segment (consistent with OpenType Sanitizer),
making the custom font display.
Bug: 18106256
Change-Id: Icc8616a3030f80e62db906332be64d434ae72ea2
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
