01.11.2014 Views

A Proposal for Bidi Isolates in Unicode

A Proposal for Bidi Isolates in Unicode

A Proposal for Bidi Isolates in Unicode

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

●<br />

unicode-bidi:isolate-override: If the element is not a conta<strong>in</strong><strong>in</strong>g block, entails simulat<strong>in</strong>g an<br />

LRI or RLI at the start of the element (whichever would give the smaller level jump) and a<br />

PDI at the end of the element. Furthermore, whether the element is a conta<strong>in</strong><strong>in</strong>g block or<br />

not, entails simulat<strong>in</strong>g an LRO or RLO (aga<strong>in</strong> depend<strong>in</strong>g on the element’s direction style)<br />

at the start of the element, after the LRI or RLI, and a PDF at the end of the element,<br />

be<strong>for</strong>e the PDI.<br />

Please note that we have not proposed <strong>for</strong>matt<strong>in</strong>g characters that comb<strong>in</strong>e isolation with<br />

directional override <strong>for</strong> <strong>Unicode</strong> (the direct equivalent of CSS’ unicode-bidi:isolate-override)<br />

because they are not likely to be very useful, and can be simulated by comb<strong>in</strong><strong>in</strong>g <strong>for</strong>matt<strong>in</strong>g<br />

characters as above, admittedly at the cost of us<strong>in</strong>g higher level number jumps.<br />

At a paragraph break <strong>in</strong>side an isolate that is not a conta<strong>in</strong><strong>in</strong>g block, the CSS specification to<br />

emit the <strong>for</strong>matt<strong>in</strong>g codes appropriate <strong>for</strong> the end of the element be<strong>for</strong>e the paragraph break, and<br />

to re-emit the <strong>for</strong>matt<strong>in</strong>g codes appropriate <strong>for</strong> the start of the element after the paragraph break<br />

would still apply. Thus a with<strong>in</strong> would first<br />

simulate a PDI, then the newl<strong>in</strong>e, and then an LRI. Similarly, a with<strong>in</strong> would put an FSI after the newl<strong>in</strong>e. If the same<br />

occured <strong>for</strong> <strong>in</strong>stead of a , i.e. <strong>in</strong> a conta<strong>in</strong><strong>in</strong>g block, no <strong>for</strong>matt<strong>in</strong>g codes would be<br />

<strong>in</strong>volved, not even <strong>for</strong> unicode-bidi:pla<strong>in</strong>text (although of course the usual rules P2 and P3 would<br />

be apply to its paragraphs).<br />

Un<strong>for</strong>tunately, however, such an implementation would not agree with the current CSS<br />

specification. Its behavior would differ from that implied by the current specification <strong>in</strong> two<br />

respects:<br />

● A paragraph break with<strong>in</strong> an isolate that is not a conta<strong>in</strong><strong>in</strong>g block would constitute a<br />

paragraph break <strong>in</strong> the content surround<strong>in</strong>g the isolate. The current specification implies<br />

that, although a paragraph break <strong>in</strong>side an isolate should start a new paragraph with<strong>in</strong><br />

the isolate, it should not affect the paragraph with<strong>in</strong> which the isolate appears. The<br />

outside paragraph should cont<strong>in</strong>ue to flow on the other side of the isolate, as if the isolate<br />

were a neutral character.<br />

● Each isolate would start one or two levels higher than its surround<strong>in</strong>gs. The current<br />

specification implies that it should start at level 0 or 1.<br />

We are there<strong>for</strong>e work<strong>in</strong>g on chang<strong>in</strong>g the CSS specification <strong>for</strong> isolates to base it on the<br />

proposed <strong>Unicode</strong> isolate <strong>for</strong>matt<strong>in</strong>g characters as described above. This has the side benefit of<br />

simplify<strong>in</strong>g the CSS specification.<br />

Obviously, such a change <strong>in</strong> the CSS specification can not be made be<strong>for</strong>e <strong>Unicode</strong> isolates<br />

have been accepted <strong>in</strong>to the <strong>Unicode</strong> standard, so our CSS specification modification proposal<br />

is currently hypothetical.<br />

One could ask, however, why we are not propos<strong>in</strong>g that <strong>Unicode</strong> isolates behave more like

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!