Sorry, I did not see that these characters were part of the proposed BPA : U+2E22, U+2E23, ⸢ ⸣, TOP LEFT HALF BRACKET, TOP RIGHT HALF BRACKET U+2E24, U+2E25, ⸤ ⸥, BOTTOM LEFT HALF BRACKET, BOTTOM RIGHT HALF BRACKET
So this resolves the issue for authors of mixed Latin/Arabic and Latin/Hebrew. I just hope that these paired punctuations will get a better support in core fonts of arious OSes (suggestion: include them in all fonts in the Arial, Verdana, Times New Roman, Courier New, and Segoe UI families on Windows, and Helvetica, Times and Courier on Mac OS; I have nothing to propose for Linux, distributions can easily be updated to include them rapidely in their updates of their free core fonts ; core fonts for smartphones OSes should also include them). 2012/6/6 Philippe Verdy <[email protected]>: > Great. I really hope that all major web browsers being updated to > implement it in their renderers. > > This is the most urgent need, even before word processors whose > rendering is much more predictable in their rich text formats, and > even if the text encoding was specially contrieved to work with UBA > only. > > BPA should not be enabled automatically when opening a word processor > document created with a version where it was not explicitly enabled, > but new documents may still be created and will be storing an internal > meta data specifying that BPA was enabled. Word processor documents > have all the capabilities to support version tracking, so this is much > less a problem for stability than in web formats (mostly HTML). > > Plain-text documents (*.txt) are another problem, but they are created > only with a single left-margin, or a single right-margin alignment > were they are correctly readable. I've not found many of them > contrivied in such a way that its Arabic content (when the document is > written in Arabic) looks correct when reading it with a LTR > document-level presentation. It is assumed that this document-level > presentation will be changed immediately by the user opening the file > for display, if the "notepad-like" application does not autodetect > this preferred presentation. > > But BPA will be highly desirable and should be enable by default for > presenting short plain-text data fields (limited to one line or less, > without any line-break). E.g. in document titles or filenames. > > In fact, even if BPA does not resolve all ambiguities, in most texts > it will offer a good solution to avoid directional control formats as > well : surround the problematic embedded texts by parenthese-like > pairs. > > Ideographic quotation marks are included (those that look like half > square brackets, or corners). > > But the usual quotation marks used in Latin/Greek/Cyrillic keep their > ambiguity (because their pairing is language dependant), but we still > have no suitable quotation marks for RTL scripts that would allow > using BPA as well for them > > The solution offered for now by this BPA to text authors could be to > use the ideographic truncated square brackets as well in mixed RTL/LTR > contexts, but in my opnion they are too high, not suitable for use > with mixed Latin/Arabic or Latin/Hebrew, and I would highly prefer > that they pair correctly both under the baseline or both above the > Hebrew Arabic points and Latin diacritics, in a smaller version where > their vertical line just goes from the ascender line to the middle of > the x-height, or from the descender line up to the baseline, and with > an horitontal width equal to this vertical height, and a very narrow > side-bearing on their internal side (the external side-bearing below > allowed to be a bit larger); they could also use the metrics of > existing square brackets. > > This would mean desunifying the existing ideographic corner brackets > to support a more suitable use with > Latin/Greek/Cyrillic/Hebrew/Arabic. For now, this BPA just resolves > cleanly the case of text mixing LTR East Asian scripts (sinograms, > Hangul/Jamos, kanas, "wide" Latin, Bopomofo) and RTL scripts, because > these ideographic square brackets are suitable for them. But not > really for the common Latin/Arabic and Latin/Hebrew cases. In their > desunified versions, these corner brackets would have very different > metrics, including in their representative glyph in the charts (and > they are definitely not the same as the "NOT SIGN", or the corners in > Box drawing symbols (wrong placement of the horizontal segment, and > wrong joining) > > 2012/6/6 <[email protected]>: >> The Unicode Technical Committee is seeking feedback on a proposal to enhance >> the Unicode Bidirectional Algorithm (UAX #9) with additional logic--a >> bidirectional parenthesis algorithm (BPA)--for processing paired punctuation >> marks such as parentheses. This proposal is intended to produce better >> bidi-layout results in common text sequences that involve paired punctuation >> marks. Details of the proposal, with questions for reviewers and a detailed >> background document are available through the PRI #231 page: >> http://www.unicode.org/review/pri231/
