Bug 105409 - Refactor RenderText::linesBoundingBox() code for returning correct logical rect values.
Summary: Refactor RenderText::linesBoundingBox() code for returning correct logical re...
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-19 03:01 PST by Arpita Bahuguna
Modified: 2012-12-24 03:50 PST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arpita Bahuguna 2012-12-19 03:01:59 PST
RenderText::linesBoundingBox() returns an IntRect as per the writing mode.

Thus, appropriate "logical" left, right, top and bottom calls are made to retrieve the corresponding values.
logicalLeft(), logicalRight(), logicalTop() and logicalBottom() (called on the inlineBox), all return values as per the writing mode.

Yet, while computing the width and height for the returned rect, we further interchange the values (for vertical writing mode), even though that has already been taken care of (by using the logical method calls).

This ultimately results in the returned rect not having the width and height set as per the writing mode. Or, in other words, the width and height set on the returned rect are always as per the horizontal writing mode.
Comment 1 Arpita Bahuguna 2012-12-24 03:49:49 PST
Verified the issue stated here to not be true. Upon further analysis have found that the confusion perhaps arises due to our comprehension of the terms logicalLeftSide and logicalRightSide when compared with the width and height.

In the horizontal writing mode, we have the leftSide and the rightSide indicate values as per their general convention as do the width and height.
But in the vertical writing mode, the logicalLeft points to the top value and the logicalRight points to the bottom value of the rect whereas the computed width and height values continue to be indicative of the actual width and height of the rect (with the width being equal to the font height and the height being equal to the actual text length).

Thus the implementation is indeed proper (although perhaps a bit misleading).

I propose to close this issue here.
Comment 2 Arpita Bahuguna 2012-12-24 03:50:59 PST
Closing since not an issue (see #1).