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)
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   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> :</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 ‧ 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 ‧ samples I tested, please don't break when correcting   problem.
Updated•17 years ago
|
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.
Description
•