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.
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → WORKSFORME
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
Thanks for the test case, now the problem is clear.
Looks like a block/inline issue
Updating to default Layout Assignee...kipp no longer with us :-(
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.
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.
Summary: Problem with trailing spaces within a right justified row. → [TEXT] Problem with trailing spaces within a right justified row.
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
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
moving all buster m15 bugs to m16.
Target Milestone: M15 → M16
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
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
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...
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
Target Milestone: mozilla1.0 → ---
mark it as moz0.9.3
Target Milestone: --- → mozilla0.9.3
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.
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: 20 years ago → 17 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?
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.
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.