Alternate Unicode

I have had extensive Unicode discussions with Unicode experts. We disagree on the concept of plain text. They believe that Unicode plain text should not include 2-dimensional placement with Cartesian coordinates.

My current I-D documents the character use of the Internet Community with ASCII and with PUA Unicode.

The official Unicode proposals represent an alternate design: exploring Unicode ideas and still evolving. For layout, it has been determined that we will require concepts that are not yet in Unicode and we will require additions to font specifications.

N4342 section C. Technical - Justification. Questions 5a asks "Are the proposed characters in current use by the user community?" The answer is incorrectly entered as "Yes". The characters in proposal n4342 are not used by the community. Those characters are only used in the n4342 proposal itself. The SignPuddle Standard is a proposal for SignWriting Text with characters and formal strings. This standard has been used by the community for years. These characters are necessary and complete. The set of characters has been stable since January 12, 2012 as defined in draft-slevinski-signwriting-text: Section 6.2.   D.1. N4015

Unicode proposal N4015 is a complete mapping of ISWA 2010 symbol encoding with fixed-width character identification of symbols. The incomplete mapping of plain text logograms requires the use of a lite markup similar to FSW and KSW   D.2. N4090

Unicode proposal N4090 introduces the concept of inherent characters. A break from the community use of fixed width characters that continues till this day. Because of the break between the proposal and the community, neither N4090 nor N4342 has ever been used by the community. Programmers agree, the inherent design is different then what we do. It breaks parsing and binary string compare. A fixed-width design is the basis of UTF-16. Every Unicode character can be named with 2 UTF-16 characters. It would be insanity to replace the UTF-16 trail character DC00 with the idea of an inherent character. It would break the UTF-16 implementations and require the programmers to rewrite a fixed-width character process as a variable-width character process. Any programmer worth his salt would see the damage to the fixed-width character model and write a program to fix the damaged data rather than rewrite the programming libraries. The community libraries are working and elegant for a fixed-width character design. The symbol encoding used by the community has nothing to do with diacritics. The inherent model fits a diacritic paradigm of symbol construction.

An alternate solution can be found in the 1984 SignWriter Dos typing model. SignWriting Typing used 2 keys to identify a base and then tapping the appropriate modifier keys to get the exact symbol. 5 characters would be sufficient: 2 fills ( F+ and F- ), 2 rotations ( R+ and R- ), and 1 mirror (M). we can identify every symbol on the 6 by 16 grid.



Alternate Symbol Identification Design

Normalization should reorder and reduce the 5 modifying characters. Using sort order F+, F-, R+, R-, M, any string of typed modifying characters will reduce to the expected character string. For reference, the above table is sorted in reverse. 2 M's cancel F+ and F- cancel F+, F+, F+ becomes F-, F-, F- F-, F-, F-, F- becomes F+, F+ R+ and R- cancel R+, R+, R+, R+ becomes R-, R-, R-, R- R-, R-, R-, R-, R- becomes R+, R+, R+

  D.3. N4342

Unicode proposal N4342</a> extends the diacritic concepts, further diverging from the user community. The creation of diacritic facial expressions is untested. It has never been used in software and there is no proof of concept application. </a> </a> D.4. N4xxx

A lot of development is still needed before we can see all of the symbols of the ISWA 2010 with any of the Unicode proposals. There is no specification for logographic sign construction. It would be counterproductive to encode any of the characters for the SignWriting script without knowing how to use them when constructing signs and sentences. Cross development should be integrated with the Writing Modes CSS document. A complete solution for SignWriting in Unicode should include Unicode characters and CSS defined layout and style. Additionally, modifications to existing font specifications may be necessary.