Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 23:53:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibWeb/Layout/SVGFormattingContext.h

47 lines
1.5 KiB
C
Raw Normal View History

LibWeb: Add SVGFormattingContext to handle SVG box trees Instead of trying to layout SVG boxes as if they are regular CSS boxes, let's invent an "SVG formatting context" and let it manage SVG boxes. To facilitate this, Layout::SVGBox no longer inherits from ReplacedBox, and is instead a simple, "inline-block" style BlockBox.
2021-09-17 23:12:16 +02:00
/*
* Copyright (c) 2021, Andreas Kling <kling@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
LibGfx: Rename Path => DeprecatedPath
2024-08-08 10:22:03 +02:00
#include <LibGfx/DeprecatedPath.h>
LibWeb: Add SVGFormattingContext to handle SVG box trees Instead of trying to layout SVG boxes as if they are regular CSS boxes, let's invent an "SVG formatting context" and let it manage SVG boxes. To facilitate this, Layout::SVGBox no longer inherits from ReplacedBox, and is instead a simple, "inline-block" style BlockBox.
2021-09-17 23:12:16 +02:00
#include <LibWeb/Forward.h>
#include <LibWeb/Layout/FormattingContext.h>
LibWeb: Split `SVGFormattingContext` up into functions Doing multiple `for_each_in_subtree()` passes was kind of a hack. We can resolve everything in a single pass with a little more control over the layout process. This also fixes a few minor issues like the sizing of nested `<g>` elements. More work is needed here though as this is still fairly ad-hoc. Note: This does regress `css-namespace-tag-name-selector.html`, previously SVG text within `<a>` elements would appear. However, this was only because `for_each_in_subtree()` would blindly look through the InlineNodes from the unimplemented `SVGAElement`s.
2024-04-07 20:47:13 +01:00
#include <LibWeb/Layout/SVGSVGBox.h>
#include <LibWeb/Layout/SVGTextBox.h>
#include <LibWeb/Layout/SVGTextPathBox.h>
LibWeb: Add SVGFormattingContext to handle SVG box trees Instead of trying to layout SVG boxes as if they are regular CSS boxes, let's invent an "SVG formatting context" and let it manage SVG boxes. To facilitate this, Layout::SVGBox no longer inherits from ReplacedBox, and is instead a simple, "inline-block" style BlockBox.
2021-09-17 23:12:16 +02:00
namespace Web::Layout {
class SVGFormattingContext : public FormattingContext {
public:
LibWeb: Add initial support for nesting SVG viewports Previously, we were handling viewBoxes/viewports in a slightly hacky way, asking graphics elements to figure out what viewBox to use during layout. This does not work in all cases, and can't allow for more complex SVGs where it is possible to have nested viewports. This commit makes the SVGFormattingContext keep track of the viewport/boxes, and it now lays out each viewport recursively, where each nested `<svg>` or `<symbol>` can establish a new viewport. This fixes some previous edge cases, and starts to allow nested viewports (there's still some issues to resolve there). Fixes #22931
2024-01-27 16:23:22 +00:00
explicit SVGFormattingContext(LayoutState&, Box const&, FormattingContext* parent, Gfx::AffineTransform parent_viewbox_transform = {});
LibWeb: Add SVGFormattingContext to handle SVG box trees Instead of trying to layout SVG boxes as if they are regular CSS boxes, let's invent an "SVG formatting context" and let it manage SVG boxes. To facilitate this, Layout::SVGBox no longer inherits from ReplacedBox, and is instead a simple, "inline-block" style BlockBox.
2021-09-17 23:12:16 +02:00
~SVGFormattingContext();
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
virtual void run(Box const&, LayoutMode, AvailableSpace const&) override;
LibWeb: Let FormattingContext decide the automatic width of its root Instead of special-casing FlexFormattingContext in the intrinsic sizing layout helpers, add FormattingContext::automatic_content_width() and let each context subclass decide what that means. No behavior change here, just moving this responsibility.
2023-03-19 09:57:31 +01:00
virtual CSSPixels automatic_content_width() const override;
LibWeb: Convert FormattingContext to new pixel units Just FormattingContext and AvailableSpace, and the minor adjustments to make everything else work.
2022-11-23 17:46:10 +00:00
virtual CSSPixels automatic_content_height() const override;
LibWeb: Add initial support for nesting SVG viewports Previously, we were handling viewBoxes/viewports in a slightly hacky way, asking graphics elements to figure out what viewBox to use during layout. This does not work in all cases, and can't allow for more complex SVGs where it is possible to have nested viewports. This commit makes the SVGFormattingContext keep track of the viewport/boxes, and it now lays out each viewport recursively, where each nested `<svg>` or `<symbol>` can establish a new viewport. This fixes some previous edge cases, and starts to allow nested viewports (there's still some issues to resolve there). Fixes #22931
2024-01-27 16:23:22 +00:00
private:
LibWeb: Split `SVGFormattingContext` up into functions Doing multiple `for_each_in_subtree()` passes was kind of a hack. We can resolve everything in a single pass with a little more control over the layout process. This also fixes a few minor issues like the sizing of nested `<g>` elements. More work is needed here though as this is still fairly ad-hoc. Note: This does regress `css-namespace-tag-name-selector.html`, previously SVG text within `<a>` elements would appear. However, this was only because `for_each_in_subtree()` would blindly look through the InlineNodes from the unimplemented `SVGAElement`s.
2024-04-07 20:47:13 +01:00
void layout_svg_element(Box const&);
void layout_nested_viewport(Box const&);
void layout_container_element(SVGBox const&);
void layout_graphics_element(SVGGraphicsBox const&);
void layout_path_like_element(SVGGraphicsBox const&);
void layout_mask_or_clip(SVGBox const&);
LibGfx: Rename Path => DeprecatedPath
2024-08-08 10:22:03 +02:00
Gfx::DeprecatedPath compute_path_for_text(SVGTextBox const&);
Gfx::DeprecatedPath compute_path_for_text_path(SVGTextPathBox const&);
LibWeb: Split `SVGFormattingContext` up into functions Doing multiple `for_each_in_subtree()` passes was kind of a hack. We can resolve everything in a single pass with a little more control over the layout process. This also fixes a few minor issues like the sizing of nested `<g>` elements. More work is needed here though as this is still fairly ad-hoc. Note: This does regress `css-namespace-tag-name-selector.html`, previously SVG text within `<a>` elements would appear. However, this was only because `for_each_in_subtree()` would blindly look through the InlineNodes from the unimplemented `SVGAElement`s.
2024-04-07 20:47:13 +01:00
LibWeb: Add initial support for nesting SVG viewports Previously, we were handling viewBoxes/viewports in a slightly hacky way, asking graphics elements to figure out what viewBox to use during layout. This does not work in all cases, and can't allow for more complex SVGs where it is possible to have nested viewports. This commit makes the SVGFormattingContext keep track of the viewport/boxes, and it now lays out each viewport recursively, where each nested `<svg>` or `<symbol>` can establish a new viewport. This fixes some previous edge cases, and starts to allow nested viewports (there's still some issues to resolve there). Fixes #22931
2024-01-27 16:23:22 +00:00
Gfx::AffineTransform m_parent_viewbox_transform {};
LibWeb: Split `SVGFormattingContext` up into functions Doing multiple `for_each_in_subtree()` passes was kind of a hack. We can resolve everything in a single pass with a little more control over the layout process. This also fixes a few minor issues like the sizing of nested `<g>` elements. More work is needed here though as this is still fairly ad-hoc. Note: This does regress `css-namespace-tag-name-selector.html`, previously SVG text within `<a>` elements would appear. However, this was only because `for_each_in_subtree()` would blindly look through the InlineNodes from the unimplemented `SVGAElement`s.
2024-04-07 20:47:13 +01:00
Optional<AvailableSpace> m_available_space {};
Gfx::AffineTransform m_current_viewbox_transform {};
CSSPixelSize m_viewport_size {};
CSSPixelPoint m_svg_offset {};
LibWeb: Add SVGFormattingContext to handle SVG box trees Instead of trying to layout SVG boxes as if they are regular CSS boxes, let's invent an "SVG formatting context" and let it manage SVG boxes. To facilitate this, Layout::SVGBox no longer inherits from ReplacedBox, and is instead a simple, "inline-block" style BlockBox.
2021-09-17 23:12:16 +02:00
};
}
Reference in a new issue Copy permalink