Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-31 05:10:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Layout/LineBoxFragment.h

81 lines
3 KiB
C
Raw Normal View History

Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 09:38:21 +01:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2018-2020, Andreas Kling <andreas@ladybird.org>
Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 09:38:21 +01:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 09:38:21 +01:00
*/
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
#pragma once
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
#include <LibGC/Ptr.h>
Meta+LibHTTP through LibWeb: Make clang-format-10 clean
2020-09-18 09:49:51 +02:00
#include <LibGfx/Rect.h>
LibGfx+LibWeb: Calculate and save glyph positions during layout Previously, we determined the positions of glyphs for each text run at the time of painting, which constituted a significant portion of the painting process according to profiles. However, since we already go through each glyph to figure out the width of each fragment during layout, we can simultaneously gather data about the position of each glyph in the layout phase and utilize this information in the painting phase. I had to update expectations for a couple of reference tests. These updates are due to the fact that we now measure glyph positions during layout using a 1x font, and then linearly scale each glyph's position to device pixels during painting. This approach should be acceptable, considering we measure a fragment's width and height with an unscaled font during layout.
2023-12-02 18:38:05 +01:00
#include <LibGfx/TextLayout.h>
LibWeb: Rework the layout engine to use relative offsets The box tree and line boxes now all store a relative offset from their containing block, instead of an absolute (document-relative) position. This removes a huge pain point from the layout system which was having to adjust offsets recursively when something moved. It also makes some layout logic significantly simpler. Every box can still find its absolute position by walking its chain of containing blocks and accumulating the translation from the root. This is currently what we do both for rendering and hit testing.
2020-06-10 10:42:29 +02:00
#include <LibWeb/Forward.h>
LibWeb: Resolve border radius during layout and save it in paintables This change fixes a problem that we should not call `to_px()` to resolve any length or percentage values during paintables traversal because that is supposed to happen while performing layout. Also it improves performance because before we were resolving border radii during each painting phase but now it happens only once during layout.
2023-12-07 06:16:17 +01:00
#include <LibWeb/Painting/BorderRadiiData.h>
LibWeb: Convert Paintable coordinates to new pixel units This fixes a few sizing issues too. The page size is now correct in most cases! \o/ We get to remove some of the `to_type<>()` shenanigans, though it reappears in some other places.
2022-10-31 19:46:55 +00:00
#include <LibWeb/PixelUnits.h>
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
LibWeb: Rename LayoutNode classes and move them into Layout namespace Bring the names of various boxes closer to spec language. This should hopefully make things easier to understand and hack on. :^) Some notable changes: - LayoutNode -> Layout::Node - LayoutBox -> Layout::Box - LayoutBlock -> Layout::BlockBox - LayoutReplaced -> Layout::ReplacedBox - LayoutDocument -> Layout::InitialContainingBlockBox - LayoutText -> Layout::TextNode - LayoutInline -> Layout::InlineNode Note that this is not strictly a "box tree" as we also hang inline/text nodes in the same tree, and they don't generate boxes. (Instead, they contribute line box fragments to their containing block!)
2020-11-22 15:53:01 +01:00
namespace Web::Layout {
LibWeb: Move everything into the Web namespace
2020-03-07 10:27:02 +01:00
LibWeb: Use coordinate instead of WeakPtr for box->fragment connection Using WeakPtr to remember which LineBoxFragment owns which Box was imposing some annoying constraints on the layout code. Importantly, it was forcing us to heap-allocate fragments, which makes it much harder to clone a FormattingState. This patch replaces the WeakPtr with a coordinate system instead. Fragments are referred to by their line box index + fragment index within the line box.
2022-02-27 10:26:38 +01:00
class LineBoxFragment {
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
friend class LineBox;
LibWeb: Rework the layout engine to use relative offsets The box tree and line boxes now all store a relative offset from their containing block, instead of an absolute (document-relative) position. This removes a huge pain point from the layout system which was having to adjust offsets recursively when something moved. It also makes some layout logic significantly simpler. Every box can still find its absolute position by walking its chain of containing blocks and accumulating the translation from the root. This is currently what we do both for rendering and hit testing.
2020-06-10 10:42:29 +02:00
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
public:
LibWeb: Layout inline elements respective of `writing-mode` Use the `writing-mode` property to determine what values should be used for computing each element's rect on the screen. If it is a vertical mode, swap the inline and block, lengths and offsets. This only lays out whole inline formatting contexts vertically, and does not currently support mixing the two orientations in a single context.
2024-10-29 11:32:59 +00:00
LineBoxFragment(Node const& layout_node, int start, int length, CSSPixels inline_offset, CSSPixels block_offset, CSSPixels inline_length, CSSPixels block_length, CSSPixels border_box_top, CSS::Direction, CSS::WritingMode, RefPtr<Gfx::GlyphRun>);
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
Node const& layout_node() const { return m_layout_node; }
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
int start() const { return m_start; }
int length() const { return m_length; }
LibWeb: Rework the layout engine to use relative offsets The box tree and line boxes now all store a relative offset from their containing block, instead of an absolute (document-relative) position. This removes a huge pain point from the layout system which was having to adjust offsets recursively when something moved. It also makes some layout logic significantly simpler. Every box can still find its absolute position by walking its chain of containing blocks and accumulating the translation from the root. This is currently what we do both for rendering and hit testing.
2020-06-10 10:42:29 +02:00
LibWeb: Make inline layout independent of direction This patch separates the notion of x, y, width, and height, from inline_offset, block_offset, inline_length, and block_length. These can then be used to compute the final screen positions, in respect of the desired layout direction. This is the terminology used in https://drafts.csswg.org/css-writing-modes/#text-flow This makes it possible to use this layout algorithm to flow text in any direction. For example, vertically.
2024-10-29 11:32:59 +00:00
CSSPixelPoint offset() const;
CSSPixels inline_offset() const { return m_inline_offset; }
CSSPixels block_offset() const { return m_block_offset; }
void set_inline_offset(CSSPixels inline_offset) { m_inline_offset = inline_offset; }
void set_block_offset(CSSPixels block_offset) { m_block_offset = block_offset; }
LibWeb: Rework the layout engine to use relative offsets The box tree and line boxes now all store a relative offset from their containing block, instead of an absolute (document-relative) position. This removes a huge pain point from the layout system which was having to adjust offsets recursively when something moved. It also makes some layout logic significantly simpler. Every box can still find its absolute position by walking its chain of containing blocks and accumulating the translation from the root. This is currently what we do both for rendering and hit testing.
2020-06-10 10:42:29 +02:00
LibWeb: Use the new Gfx::Painter::draw_text_run() API for drawing text This avoids a bunch of unnecessary work in Painter which not only took time, but sometimes also led to alignment issues. draw_text_run() will draw the text where we tell it, and that's it.
2022-03-28 21:05:51 +02:00
// The baseline of a fragment is the number of pixels from the top to the text baseline.
LibWeb: Convert Paintable coordinates to new pixel units This fixes a few sizing issues too. The page size is now correct in most cases! \o/ We get to remove some of the `to_type<>()` shenanigans, though it reappears in some other places.
2022-10-31 19:46:55 +00:00
void set_baseline(CSSPixels y) { m_baseline = y; }
CSSPixels baseline() const { return m_baseline; }
LibWeb: Use the new Gfx::Painter::draw_text_run() API for drawing text This avoids a bunch of unnecessary work in Painter which not only took time, but sometimes also led to alignment issues. draw_text_run() will draw the text where we tell it, and that's it.
2022-03-28 21:05:51 +02:00
LibWeb: Make inline layout independent of direction This patch separates the notion of x, y, width, and height, from inline_offset, block_offset, inline_length, and block_length. These can then be used to compute the final screen positions, in respect of the desired layout direction. This is the terminology used in https://drafts.csswg.org/css-writing-modes/#text-flow This makes it possible to use this layout algorithm to flow text in any direction. For example, vertically.
2024-10-29 11:32:59 +00:00
CSSPixelSize size() const;
CSSPixels width() const { return size().width(); }
CSSPixels height() const { return size().height(); }
CSSPixels inline_length() const { return m_inline_length; }
CSSPixels block_length() const { return m_block_length; }
void set_inline_length(CSSPixels inline_length) { m_inline_length = inline_length; }
void set_block_length(CSSPixels block_length) { m_block_length = block_length; }
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
LibWeb: Convert Paintable coordinates to new pixel units This fixes a few sizing issues too. The page size is now correct in most cases! \o/ We get to remove some of the `to_type<>()` shenanigans, though it reappears in some other places.
2022-10-31 19:46:55 +00:00
CSSPixels border_box_top() const { return m_border_box_top; }
LibHTML: Remove trailing whitespace in line boxes After the splitting-into-lines pass, remove any trailing whitespace from all of a block's line boxes. This improves the appearance of text-align: justify/right :^)
2019-10-20 17:18:28 +02:00
LibWeb: Teach line layout to collapse whitespace across fragments This kind of HTML now produces a single piece of whitespace: <span> </span> <span> </span> <span> </span> We achieve this by checking if the last fragment on the last line ends in whitespace. If so, we either don't add a fragment at all (for the current chunk) or we simply skip over all whitespace at the head of the current chunk (instead of collapsing it to a single ' '.)
2020-06-13 14:59:17 +02:00
bool ends_in_whitespace() const;
LibHTML: Implement "text-align: justify" In order for this to work nicely, I made the line box classes use float instead of int for its geometry information. Justification works by distributing all of the whitespace on the line (including the trailing whitespace before the line break) evenly across the spaces in-between words. We should probably use floating point (or maybe fixed point?) for all the layout metrics stuff. But one thing at a time. :^)
2019-10-20 12:30:25 +02:00
bool is_justifiable_whitespace() const;
LibHTML: Remove trailing whitespace in line boxes After the splitting-into-lines pass, remove any trailing whitespace from all of a block's line boxes. This improves the appearance of text-align: justify/right :^)
2019-10-20 17:18:28 +02:00
StringView text() const;
LibHTML: Implement "text-align: justify" In order for this to work nicely, I made the line box classes use float instead of int for its geometry information. Justification works by distributing all of the whitespace on the line (including the trailing whitespace before the line break) evenly across the spaces in-between words. We should probably use floating point (or maybe fixed point?) for all the layout metrics stuff. But one thing at a time. :^)
2019-10-20 12:30:25 +02:00
LibWeb: Consider margins of atomic inlines in layout According to CSS Inline Layout Module Level 3 § 2.2 Step 1. atomic inlines should be layed out in a line box based on their margin box. However, up until this patch we were unconditionally considering only the border box during line box height calculation. This made us essentially drop all vertical margins for atomic inlines.
2023-03-14 10:28:01 +01:00
bool is_atomic_inline() const;
Everywhere: Limit layout text fragments to use one font for all glyphs The ChunkIterator now limits a chunk to using only one font (before, it was possible to have a chunk with >1 font, when `unicode-range` CSS property is used). This change allows us to reduce some complexity in the text shaping and painting code and makes us compatible with the APIs in Skia and HarfBuzz.
2024-06-29 17:14:23 +02:00
RefPtr<Gfx::GlyphRun> glyph_run() const { return m_glyph_run; }
LibWeb: Draw text vertically, for fragments with vertical `writing-mode` For fragments with a vertical `writing-mode`. Rotate the text, so that it is rendered on its side. This makes it fit into its layout box.
2024-10-29 14:29:00 +00:00
CSS::WritingMode writing_mode() const { return m_writing_mode; }
LibWeb: Layout text chunks based on their Unicode direction Append text chunks to either the start or end of the text fragment, depending on the text direction. The direction is determined by what script its code points are from.
2024-08-18 17:58:05 +01:00
void append_glyph_run(RefPtr<Gfx::GlyphRun> const&, CSSPixels run_width);
LibGfx+LibWeb: Calculate and save glyph positions during layout Previously, we determined the positions of glyphs for each text run at the time of painting, which constituted a significant portion of the painting process according to profiles. However, since we already go through each glyph to figure out the width of each fragment during layout, we can simultaneously gather data about the position of each glyph in the layout phase and utilize this information in the painting phase. I had to update expectations for a couple of reference tests. These updates are due to the fact that we now measure glyph positions during layout using a 1x font, and then linearly scale each glyph's position to device pixels during painting. This approach should be acceptable, considering we measure a fragment's width and height with an unscaled font during layout.
2023-12-02 18:38:05 +01:00
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
private:
LibWeb: Layout text chunks based on their Unicode direction Append text chunks to either the start or end of the text fragment, depending on the text direction. The direction is determined by what script its code points are from.
2024-08-18 17:58:05 +01:00
CSS::Direction resolve_glyph_run_direction(Gfx::GlyphRun::TextType) const;
void append_glyph_run_ltr(RefPtr<Gfx::GlyphRun> const&, CSSPixels run_width);
void append_glyph_run_rtl(RefPtr<Gfx::GlyphRun> const&, CSSPixels run_width);
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<Node const> m_layout_node;
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
int m_start { 0 };
int m_length { 0 };
LibWeb: Make inline layout independent of direction This patch separates the notion of x, y, width, and height, from inline_offset, block_offset, inline_length, and block_length. These can then be used to compute the final screen positions, in respect of the desired layout direction. This is the terminology used in https://drafts.csswg.org/css-writing-modes/#text-flow This makes it possible to use this layout algorithm to flow text in any direction. For example, vertically.
2024-10-29 11:32:59 +00:00
CSSPixels m_inline_offset;
CSSPixels m_block_offset;
CSSPixels m_inline_length;
CSSPixels m_block_length;
LibWeb: Convert Paintable coordinates to new pixel units This fixes a few sizing issues too. The page size is now correct in most cases! \o/ We get to remove some of the `to_type<>()` shenanigans, though it reappears in some other places.
2022-10-31 19:46:55 +00:00
CSSPixels m_border_box_top { 0 };
CSSPixels m_baseline { 0 };
LibWeb: Layout text chunks based on their Unicode direction Append text chunks to either the start or end of the text fragment, depending on the text direction. The direction is determined by what script its code points are from.
2024-08-18 17:58:05 +01:00
CSS::Direction m_direction { CSS::Direction::Ltr };
LibWeb: Layout inline elements respective of `writing-mode` Use the `writing-mode` property to determine what values should be used for computing each element's rect on the screen. If it is a vertical mode, swap the inline and block, lengths and offsets. This only lays out whole inline formatting contexts vertically, and does not currently support mixing the two orientations in a single context.
2024-10-29 11:32:59 +00:00
CSS::WritingMode m_writing_mode { CSS::WritingMode::HorizontalTb };
LibWeb: Layout text chunks based on their Unicode direction Append text chunks to either the start or end of the text fragment, depending on the text direction. The direction is determined by what script its code points are from.
2024-08-18 17:58:05 +01:00
Everywhere: Limit layout text fragments to use one font for all glyphs The ChunkIterator now limits a chunk to using only one font (before, it was possible to have a chunk with >1 font, when `unicode-range` CSS property is used). This change allows us to reduce some complexity in the text shaping and painting code and makes us compatible with the APIs in Skia and HarfBuzz.
2024-06-29 17:14:23 +02:00
RefPtr<Gfx::GlyphRun> m_glyph_run;
LibWeb: Layout text chunks based on their Unicode direction Append text chunks to either the start or end of the text fragment, depending on the text direction. The direction is determined by what script its code points are from.
2024-08-18 17:58:05 +01:00
float m_insert_position { 0 };
CSS::Direction m_current_insert_direction { CSS::Direction::Ltr };
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
};
LibWeb: Move everything into the Web namespace
2020-03-07 10:27:02 +01:00
}
Reference in a new issue Copy permalink