On 5/29/2012 7:16 PM, information wrote: > I'm new to this discussion , but I would say "discount" what all other > software (software out in the wild for rendering text)does and stick to > recognized methods for dealing with diacritical marks (and lets start by > calling them what they are) > if necessary provide Two API access points so that people using the system > can choose. (dumps should use 1) > 1. Unicode > 2. Combined character+ diacritical > But store internally in OL with 1.
I do not think you fully understand the issue. The categories you propose dont' make any sense. Unicode data can be represented in multiple ways, both combined and decomposed with regard to certain diacritics. It's all "unicode". That's what we've been talking about in this thread. But some forms some classes of software are known to not reliably render, and other forms and judged more reliable (and in some cases even recommended by Unicode). Recommend reviewing: http://unicode.org/reports/tr15/ This can be a confusing topic if you are not already familiar with it. I think any developers working with unicode data really need to become familiar with it, however. Engaging in discussion without being familiar with it will only lead to confusion for all. _______________________________________________ Ol-tech mailing list [email protected] http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech To unsubscribe from this mailing list, send email to [email protected]
