[Webkit-unassigned] [Bug 95625] [CSS Exclusions] add support for a subset of the basic shapes
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Sep 6 11:24:03 PDT 2012
https://bugs.webkit.org/show_bug.cgi?id=95625
--- Comment #12 from Hans Muller <giles_joplin at yahoo.com> 2012-09-06 11:24:16 PST ---
(In reply to comment #5)
> (From update of attachment 161830 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=161830&action=review
>
> Overall I'm left scratching my head here regarding the mixture of physical and logical terminology. Your platform/graphics additions seem to be using largely physical terminology, but then everything you're doing with them over in the rendering code is in terms of logical coordinates (i.e., line top and line bottom are x values in vertical writing-modes, but you're happily passing those values in to your XShape code, which then calls them "y").
Here's a proposal that I hope addresses the problem you've brought up.
I think the ExclusionShape API should use logical coordinates for the incoming top/bottom line edges and similarly it should report line segments' start/stops with logical X coordinates. The incoming BasicShape, which is just an encoding of the CSS shape, is defined with physical coordinates. That means that createExclusionShape() method will need an additional parameter, so that it can transform the BasicShape's physical coordinates when the writing-mode is vertical. It also means that an ExclusionShape will be specific to a writing-mode, so in a shape-outside case like this: https://bug-95625-attachments.webkit.org/attachment.cgi?id=162542, two ExclusionShape objects will be used to compute the layouts.
Internally, the ExclusionShapes classes (just ExclusionRectangle for the moment) do their computations as if the writing-mode was horizontal. I don't think this needs to change, although the ExclusionInterval class, which is used to report line segment endpoints, should use logical names for the X coordinates, start and end instead of x1 and x2. Here's what the ExclusionShape API would become:
// A representation of a BasicShape that enables layout code to determine how to break a line up into segments
// that will fit within or around a shape. The line is defined by a pair of logical Y coordinates and the
// computed segments are returned as pairs of logical X coordinates (ExclusionIntervals).
class ExclusionShape {
public:
static PassOwnPtr<ExclusionShape> createExclusionShape(const BasicShape*, float borderBoxWidth, float borderBoxHeight, WritingMode);
virtual ~ExclusionShape() { }
virtual LayouRect shapeBoundingBox() const = 0;
virtual void getInsideIntervals(float logicalTop, float logicalBottom, Vector<ExclusionInterval>&) const = 0;
virtual void getOutsideIntervals(float logicalTop, float logicalBottom, Vector<ExclusionInterval>&) const = 0;
};
} // namespace WebCore
The shapeBoundingBox() would return the logical bounds of the exclusion shape. I've changed the return type from FloatRect to LayoutRect.
Currently the exclusion layout code only supports shape-inside (so an exclusion shape only affects one element's contents) and it explicitly ignores exclusions defined for vertical content (see WrapShapeInfo::isWrapShapeInfoEnabledForRenderBlock). If possible, I'd like to file a bug about the lack of writing-mode support in ExclusionShape, rather than making the changes now.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list