The first of these pieces of information is the intrinsic widths cached
on a block.
The second of them is the font inflation cached on a text frame (which
might be set to 1.0 at this point if a text frame has previously had
intrinsic width calculation done on it, but hasn't been reflowed).
The first of these pieces of information is the intrinsic widths cached
on a block.
The second of them is the font inflation cached on a text frame (which
might be set to 1.0 at this point if a text frame has previously had
intrinsic width calculation done on it, but hasn't been reflowed).
Previously we snapped the results of nsDisplayItem::GetBounds and
nsDisplayItem::GetOpaqueRegion internally. By tracking which display items were
inside transforms, we disabled snapping quite conservatively whenever an ancestor
had a transform, which is undesirable.
With this patch, we don't snap inside GetBounds or GetOpaqueRegion, but just return
a boolean flag indicating whether the item will draw with snapping or not. This flag
is conservative so that "true" means we will snap (if the graphics context has a transform
that allows snapping), but "false" means we might or might not snap (so it's always safe
to return false).
FrameLayerBuilder takes over responsibility for snapping item bounds. When it converts
display item bounds to layer pixel coordinates, it checks the snap flag returned from
the display item and checks whether the transform when we draw into the layer will be
a known scale (the ContainerParameters scale factors) plus integer translation. If both
are true, we snap the item bounds when converting to layer pixel coordinates. With
this approach, we can snap item bounds even when the items have ancestors with active
transforms.
This is the second of two patches to honor inflation during intrinsic
width calculation (which we need to do to make some form controls
inflate correctly).
This is the third of three patches to rework the way we handle getting
the font inflation container and width data during reflow, which are
needed so that we can sometimes honor inflation during intrinsic width
calculation (which we need to do to make some form controls inflate
correctly).
This does not address users of font metrics in layout/mathml/ (for text
size and alignment issues) or in layout/xul (for text size and sizing of
listbox and tree widgets): see all the callers of GetFontMetricsFor*
in those directories.
This applies the font size inflation to reflow and painting of text
frames. However, it does not (by design) apply to intrinsic width
computation, since the inflation is itself a function of the containers
width, which can depend on the intrinsic width.
This does not address users of font metrics in layout/mathml/ (for text
size and alignment issues) or in layout/xul (for text size and sizing of
listbox and tree widgets): see all the callers of GetFontMetricsFor*
in those directories.
This applies the font size inflation to reflow and painting of text
frames. However, it does not (by design) apply to intrinsic width
computation, since the inflation is itself a function of the containers
width, which can depend on the intrinsic width.
We now bail in GetRenderedText when we encounter dirty text frames. This should be okay since dirty text frames should be reflowed at some point and we'll refresh our accessible text cache. (relanding)
We now bail in GetRenderedText when we encounter dirty text frames. This shouldm be okay since dirty text frames should be reflowed at some point and we'll refresh our accessible text cache.
This change does two things:
1) Makes sure that we don't clear textruns when removing continuations due to
an earlier consideration expanding to contain all their text.
2) Remove continuations in chunks to work around the fact that blocks are
really bad at handling single frame removals.
2011-08-25 23:29:24 -04:00
Alfred Kayser ext:(%2C%20Ms2ger%20%3Cms2ger%40gmail.com%3E)
This code is a little bit sketchy, but given that text-decoration
drawing is the same across modes we shouldn't have a quirks mode check
here (though there's a decent argument to be made that we shouldn't be
checking text decorations at all).
The FrameProperty representing baseline is set when a block defines
text-decorations and has vertically-aligned children, but we were
retrieving it whether the block or the vertically-aligned frame itself
defined the decorations. As a result, we "undo" the frame offset to get
the baseline from the child in that case.
Make the quirks mode text-decoration + text-shadow code draw the
decorations for shadows that do not have a specified color using
the same color used for the un-shadowed decorations, which matches
standards mode behavior. (The color of unspecified-color shadows
is explicitly undefined in the specification.)
This code will (in a later patch on this bug) be used for both
quirks and standards modes.
Quirks-mode code draws text, and then all decorations. We need to instead draw
underlines, then overlines, -then- text, then line-throughs, as per CSS 2.1.
This involves refactoring nsTextFrame::PaintTextDecorations and
nsTextFrame::DrawText by merging them together, and also updating some
of their callers.
Rendering text decorations far away from the frame's baseline seems to
sometimes introduce rounding issues. This patch addresses that by
avoiding snapped-baseline weirdness and using a different argument to
nsTextFrame::PaintTextDecorations in some computations that didn't
really need to use the snapped baseline anyway.
Change the quirks mode text-decoration code (soon to be used for all
modes) to follow CSS 2.1's rules for positioning of decoration lines.
Decorations are now drawn at a constant vertical position established by
the element creating the decoration, and more than one of the same type
(underline, overline, line-through) of decoration are supported on the
same piece of text.
This means that text-decorations can now significantly overflow a text
frame, since the vertical-alignment of the element with text-decoration
may be substantially different from the vertical alignment of the text.
Set overflow areas for text frames with text decorations in
nsLineLayout::RelativePositionFrames since it must happen *after*
vertical alignment is done, and when relative positioning data are
consistent (nsIFrame::GetRelativeOffset matches the offset that has been
applied).
