Closed Bug 386890 Opened 17 years ago Closed 17 years ago

  should not be automatically no-break, please implement UTR 14

Categories

(Firefox :: General, defect)

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 346969

People

(Reporter: webmestre, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

It looks like   never allows for a break (see http://hapax.qc.ca/espacesfines.html), this is not conforming to Unicode Technical Report (http://www.unicode.org/reports/tr14). Thin spaces are of class "BA" (break after) and should break between alphabetic and numeric for instances.

This should not be confused with ‧ which is an unconditional no-break narrow space (to be used for "espace fine insécable" in French to be sure it never breaks according to the UTR rules).


Reproducible: Always

Steps to Reproduce:
1. Load file <http://hapax.qc.ca/espacesfines.html>
2. Reduce window width until the line should break
3. The first line (using &thinsp; between every word except after :) does not break appropriately, the second one does.
Actual Results:  
Does not break.

Expected Results:  
Break between words and digits, do not break in this single case here <code>&thinsp;:</code> (which correspond to the UTR 14 classes BA and IS, there is   no break opportunity between them (represented by a ^ in Table 2, see also rule 13).

As above ! Implement UTR 14, make sure &#x2027; nevers breaks and does not rely on the glyph being found in the corresponding font (should be 1/4 em or -- but not traditional -- 1/5 em). Seems to be the case for the &#x2027; samples I tested, please don't break when correcting &thinsp; problem.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.