Shanjian Li Assignee
	Description • 23 years ago

This problem is spawn from bug 128181. See steps and test case in the bug 128181. 

For non-truetype font, ie. raster font, there is no way to get accurate cmap. 
What we are doing now is to assume code point from 0x00 to 0xff in current 
charset. But this is not true. There is some holes in this area. Unfortuately, 
some of these holes are valid code points.

	Shanjian Li Assignee
	Comment 1 • 23 years ago

assign to myself.

	Shanjian Li Assignee
	Comment 3 • 23 years ago

I verified this on winnt en, win2k sc, win98 en. It seems reasonable to skip those 
code points. Some fonts (like courier on win98) does have some valid glyph in those 
area, but those characters are infrequently used, and we will resort to truetype 
font available in system to cover those glyph. User shouldn't be able to notice the 
possible side-effect, it there is any. 

ready for r/sr

	Yuying Long
	Comment 4 • 23 years ago

Since this is splited from bug 128181, I copy the keywords there - nsbeta1+,
adt3.  And according to Frank's comment, the problem here is more important.

 

	Shanjian Li Assignee
	Comment 5 • 23 years ago

rbs, could you review my patch?

	rbs
	Comment 6 • 23 years ago

Comment on attachment 77108 [details] [diff] [review]
proposed patch

r=rbs

	Shanjian Li Assignee
	Comment 7 • 23 years ago

Marc, could you sr?

	Marc Attinasi
	Comment 8 • 23 years ago

Comment on attachment 77108 [details] [diff] [review]
proposed patch

sr=attinasi

	Frank Tang
	Comment 9 • 23 years ago

I think this is a adt2 problem, not a adt3 problem since it may cause some
garbage display in html form widget . 
shanjian, can you make a test case and a screenshot.

	Asa Dotzler [:asa]
	Comment 10 • 23 years ago

Comment on attachment 77108 [details] [diff] [review]
proposed patch

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

	Frank Tang
	Comment 14 • 23 years ago

Impact Summery
Impact Platform: ALL
Impact language users: 560M 100%
Probability of hitting the problem: MID
Severity if hit the problem in the worst case: some of the characters won't show
up correctly.
Way of recover after hit the problem: none
Risk of the fix: low, local to window code only when we deal with raster font.
Won't impact truetype font display. 
Potential benefit of fix this problem: other text display problem

	Frank Tang
	Comment 15 • 23 years ago

shanjian said the screenshot show
AFTER patch in the left and BEFORE patch in the right
compare 137, 138, 139, 142, 145

between the left and the right

this is also true for euro sign, which is a big deal. 
I think this is a very low risk mid impact bug, and please + this one. 

	Jaime Rodriguez, Jr.
	Comment 16 • 23 years ago

adt1.0.0+ (on ADT's behalf) approval for checkin into 1.0.

	Frank Tang
	Comment 17 • 23 years ago

jaimejr forgot to put + after adt1.0.0, add that for him

	Shanjian Li Assignee
	Comment 18 • 23 years ago

fix checked in. 

	Shanjian Li Assignee
	Comment 19 • 23 years ago

testers,
When verify this bug, please only pay attention to the left column of the buttons. 
Right column button was specified with NCR, that problem is covered by another bug. 

	Yuying Long
	Comment 20 • 23 years ago

The buttons in first column are displayed fine on 04-08 trunk build /
WinXP-SimpChinese.

	Yuying Long
	Comment 21 • 23 years ago

This bug was verifid before 1.0 branch, so it will affect both trunk and branch
build.  Mark as verified1.0.0.

	Simon Montagu :smontagu
	Comment 22 • 19 years ago

*** Bug 106803 has been marked as a duplicate of this bug. ***