371099 - font family is ignored if text contains particular special characters

Status: RESOLVED DUPLICATE of bug 332649

(Core :: Graphics, defect)

Description

[j.j.]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070220 Minefield/3.0a3pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070220 Minefield/3.0a3pre

Displayed alt attributes containing special characters like ⇓ and ⇑ (and prob. others) are partial overlapped of following text.

I don't see this with FF 2.0.0.1 but on current trunk.

Reproducible: Always

Steps to Reproduce:
1. see testcase

Comment 1

[j.j.]

Attachment: testcase

Comment 2

[j.j.]

Attachment: screenshot

Comment 3

[-fullmetaljacket-]

wfm, no overlapping

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a3pre) Gecko/20070220 Minefield/3.0a3pre ID:2007022018 [cairo]

Comment 4

[j.j.]

Attachment: dynamic testcase

This depends on font-family.
The browser replaces the font-family (because the special character is unknown?) but does not provide more space needed by the new font.

Comment 5

[j.j.]

Attachment: inline-block testcase

argh... it turnes out this is a general inline-block problem rather than alt text displaying.

Why is all of the text inside <span> displayed with replacing font rather than only the special character?

Comment 6

[j.j.]

Summary changed:
<img alt="...&dArr;..." src=unknown> causes overlap (overflows background)
==>
inline-block containing special characters like &dArr; cause overlap by using wider font
(please correct my english)

Comment 7

[j.j.]

Attachment: general testcase

I' realy stupid, sorry for the spam:
This is a general inline problem

Comment 8

[-fullmetaljacket-]

now i see it.... but dup of bug 167408 ?

Comment 9

[j.j.]

No. This is a regression on trunk. Regression window would be nice.
I assume this:
It is related with font and unicode handling.
The selected font can't display the special character, so it's replaced. But not the whole text should be affected by replacement.

Comment 10

[j.j.]

Attachment: general testcase

Summary and component changed

Comment 11

[j.j.]

Attachment: general testcase, screenshot

Comment 12

[j.j.]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070305 Minefield/3.0a3pre

Now the arrow ⇓ isn't displayed at all (only as placeholder).
So the bug doesn't appear.  

Comment 13

[-fullmetaljacket-]

(In reply to comment #12)
> Now the arrow ⇓ isn't displayed at all (only as placeholder).

that was bug 372636

Comment 14

[j.j.]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070307 Minefield/3.0a3pre

As expected, this bug is back today with fixing bug 372636

Comment 15

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/20070307 SeaMonkey/1.5a] (nightly) (W2Ksp4)

Tested the 2 testcases, with SeaMonkey:
*overlapping text: can't reproduce.
*overlapping background: depending, can be 0 to a few pixels, yes.
*wrong font: (I don't know how to check ... The 3 fonts of the 2nd testcase seems to work !?)

Comment 16

[Justin Kerk]

Dunno about the overlapping, but the font changing is bug 332649.

Comment 17

[Stuart Parmenter]

yeah, i believe this is a dup of that bug (or at least that it will be fixed by that bug)

Comment 18

[Jean-Marc Desperrier]

Can we break this bug in two ? One part is why all the text inside the span changes (bug 332649), but another is that measurement is completely broken.

Try to select a word near the ⇓ character to see what I mean (cut and paste elsewhere to check what you really selected).
Or just try to type text with that character in a text field :-)