This CL is a rough pass over the HTMLTokenizer to align it with parsing.md.
We'll need to do another pass more carefully in the future, but this CL gets us
roughly in the right ballpark.
We're not handling EOF properly. The parsing.md spec doesn't push the EOF
though the parser, which breaks our current way of handling EOF. We do ok if we
get EOF in the DataState, and that's enough to pass the tests for now.
Also, update camel-case.sky to reflect the fact that the parser doesn't
lower-case tag names anymore.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/678263002
I also fixed several errors in our BUILD.gn files
including bad script dependencies found by
missing_from_gn and gn check.
Still need to figure out how best to handle
:libraries deps being private to :core, etc.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/678703004
Turns out gn has 3 types of sources:
inputs (non-source files)
sources (source files)
public (source files for APIs)
I've now taught missing_from_gn about inputs
brettw says I can ignore public for now as it's unlikely
anyone is using that.
R=brettw@chromium.org
Review URL: https://codereview.chromium.org/675283002
We only allow overflow scrolling. The frame isn't special.
This is a first step in making that happen. There's a lot of
code to remove after this patch, but this gets rid of
ScrollView and a bunch of frame-level scrolling code.
Had to add in a FrameWidget class so that Scrollbar.cpp had
a way of getting to FrameView::removeChild without pulling
a core class into platform. This might go away when we rip
out the Widget tree if we made it so that FrameView didn't
keep a list of Scrollbar instances.
Modified scrollbar.html to use overflow scrolling instead of
frame level scrolling. Once we get rid of the split between
Document and documentElement, we'll be able to make the root
element in the page scrollable as well (i.e. any child of the
Document).
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/646273006
I accidentally broke border parsing when
removing CSS color keyword hacks.
While debugging this I also ran into a
race condition in the debugger, which
is fixed here.
Add --gdb argument to skydb
Makes it trivial to drop into gdb having launched
mojo_shell/sky with the right arguments.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/673073002
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
I had to also register for the text/plain mime-type
which turned out to be harder than expected.
Mostly due to my confusion with mojo_shell
using last-argument-wins argument parsing.
R=ianh@google.com
Review URL: https://codereview.chromium.org/672363002
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