[TEXT] Problem with trailing spaces within a right justified row.

RESOLVED WONTFIX

Status

()

Core
Layout
P4
minor
RESOLVED WONTFIX
19 years ago
16 years ago

People

(Reporter: Charles Mak, Assigned: Shanjian Li)

Tracking

({testcase})

Trunk
mozilla1.0.1
x86
Windows NT
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [TESTCASE], URL)

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
Overview Description: Problem with spaces within a right justified row.

Steps to Reproduce: Goto URL and notice the yellow test in the upper right
corner.

Actual Results: The column is being painted without the trailing space.

Expected Results: There should be a forced space between the text and the end of
the column.

Build Date & Platform Bug Found: build 1999-1105-08 on Windows NT 4.0 (sp6)

Additional Builds and Platforms Tested On: also a problem in M10

Additional Information: I believe IE will force a space even if the code
doesn't have a space. An obvious reason would be the problem of an italics 'f'
being drawn outside the column. It may be better to draw the column with the
trailing space, but if one isn't specified, to draw one anyway.

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME

Comment 1

19 years ago
I don't see a problem with today's build.

If you still see a problem with the latest build, then a small test case makes
the problem more obvious would be greatly appreciated
(Reporter)

Comment 2

19 years ago
Adding testcase...
(Reporter)

Comment 3

19 years ago
Created attachment 2744 [details]
testcase

Updated

19 years ago
Status: RESOLVED → REOPENED

Updated

19 years ago
Resolution: WORKSFORME → ---

Comment 4

19 years ago
Thanks for the test case, now the problem is clear.

Updated

19 years ago
Assignee: troy → kipp
Status: REOPENED → NEW

Comment 5

19 years ago
Looks like a block/inline issue

Comment 6

19 years ago
Updating to default Layout Assignee...kipp no longer with us :-(

Comment 7

19 years ago
Why are you re-reassing layout bugs? Do NOT touch layout bugs.

The bugs are assigned to Kipp so they can stay neatly organized until we have a
new owner for the block/inline code.

Comment 8

19 years ago
mass moving all Kipp's pre-beta bugs to M15.  Nisheeth and I will
prioritize these and selectively move high-priority bugs into M13 and M14.

Updated

19 years ago
Summary: Problem with trailing spaces within a right justified row. → [TEXT] Problem with trailing spaces within a right justified row.
Whiteboard: [TESTCASE]
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase

Comment 10

19 years ago
kipp is very unlikely to fix these, since he's not working ont he project any 
longer.  so I'll take a look.
Assignee: kipp → buster

Comment 11

19 years ago
moving all buster m15 bugs to m16.
Target Milestone: M15 → M16

Comment 12

18 years ago
I don't think it's right to append a space at the end of right-aligned text.  
However, there should be a facility in our text measurement code to align the 
character properly, so that there is no bleeding into the padding/border of the 
container.
Severity: normal → minor
Status: NEW → ASSIGNED
Priority: P3 → P4
Target Milestone: M16 → M19

Comment 13

18 years ago
Here is the initial batch of layout [TEXT] bugs.  I'll search for more today, 
but this should keep you busy for a while!

Please review these for possible dogfood or nsbeta2 candidates, and assign your 
own priority and milestone for each.  The current settings were relative to my 
bug list, and they might not make sense any more.
Assignee: buster → erik
Status: ASSIGNED → NEW

Updated

18 years ago
Status: NEW → ASSIGNED
The case here we're appending a space is the one with an  .  Our current
behavior makes sense - we preserve the   but not the space.

Nav4 behaved differently at the right and the left - it removed spaces at the
left but not at the right.  Do we really need to emulate this?
*** Bug 28410 has been marked as a duplicate of this bug. ***
The duplicate shows another case - we *do* put space for the space when the line
is broken with BR.  So this is a bit strange...

Comment 17

18 years ago
reassign to shanjian. This is a P4 bug. Mark it as moz1.0 for now.
Assignee: erik → shanjian
Status: ASSIGNED → NEW
Target Milestone: --- → mozilla1.0

Comment 18

17 years ago
remove milestone.
Target Milestone: mozilla1.0 → ---

Comment 19

17 years ago
mark it as moz0.9.3
Target Milestone: --- → mozilla0.9.3
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 20

17 years ago
I haven't looked at it yet. Mark it to 1.0
Target Milestone: mozilla0.9.3 → mozilla1.0
I think our behavior here may be OK.  See also bug 4248.
(Assignee)

Updated

17 years ago
Target Milestone: mozilla1.0 → mozilla1.0.1
(Assignee)

Comment 22

16 years ago
For italic font, IE added some padding space. For regular font, this padding
space is not there. I thought about how to do this in mozilla, and it seems
there is no easy solution. The layout code has to know what kind of font it is
using, and only add padding space to the end of a line. When considering
wrapping, it make thing even more complicated. It also break the font
encapsulation. So I am going to mark this bug as wontfix, unless somebody come
up with a strong practical reason why this is important. 
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago16 years ago
Resolution: --- → WONTFIX
This doesn't have anything to do with italic fonts -- it has to do with how we
should handle the space at the end of the line, doesn't it?
(Assignee)

Comment 24

16 years ago
The only problem I saw with the existing testcase was that italic glyph extrude
outside the border. 
With or without trailing space does not make any difference. 
On my Linux build I'm still seeing line 1 be different from lines 2 and 3.
(Assignee)

Comment 26

16 years ago
this is true for 6.2. But with latest trunk build, I could not see any
difference between 2 and 3. I tried on both win2000 and RH7.2. 
But the problem was filed on the fact that there was a difference between 1 and
2 as well, and this bug report claims that, for compatibility, both 2 and 3
should be the same as 1.
You need to log in before you can comment on or make changes to this bug.