On Sat, 3 Nov 2018 22:55:17 +0100
Philippe Verdy via Unicode wrote:
> I can also cite the case of Egyptian hieroglyphs: there's still no
> way to render them correctly because we lack the development of a
> stable orthography that would drive the encoding of the missing
> **semantic** characters
So you finally admit that I was right... And that the specs include
requirements that are not even needed to make UCA work, and that not even
used by wellknown implementations. These are old artefacts which are now
really confusive (instructing programmers to adopt the old deprecated
behavior, befo
I can take another example about what I call "legacy encoding" (which
really means that such encoding is just an "approximation" from which no
semantic can be clearly infered, except by using a non-determinist
heuristic, which can frequently make "false guesses").
Consider the case of the legacy H
Note also that some other scripts have their own dedicated "abbreviation
mark" encoded, but as distinctive punctuations or modifier letters: they
are NOT combining. I do not advocate changing these scripts at all.
As well I don't propose to instruct authors to use an after Latin/Greek/Letters/Ara
Le dim. 4 nov. 2018 à 18:34, Marcel Schneider a
écrit :
> On 04/11/2018 17:45, Philippe Verdy wrote:
> Marcel
> * As already repeatedly stated, I’m taking the one bit where TUS states
> that all natural languages shall be given a semantically unambiguous (ie
> not introducing new ambiguity) and i
Le dim. 4 nov. 2018 à 18:34, Marcel Schneider a
écrit :
> On 04/11/2018 17:45, Philippe Verdy wrote:
> Beyond that, the problem with *COMBINING ABBREVIATION MARK is that it
> needs OpenType support to work, while direct encoding of preformatted
> superscripts and use as abbreviation indicators fo
Sorry, I didn’t truncate the subject line, it was my mail client.
On 04/11/2018 17:45, Philippe Verdy wrote:
Note that I actually propose not just one rendering for the
but two possible variants (that would
be equally valid withou preference). Use it after any base cluster
(including with diac
On 04/11/2018 17:45, Philippe Verdy wrote:
Note that I actually propose not just one rendering for the
but two possible variants (that would
be equally valid withou preference). Use it after any base cluster
(including with diacritics if needed, like combining underlines).
- the first one can
Note that I actually propose not just one rendering for the but two possible variants (that would be equally valid
withou preference). Use it after any base cluster (including with
diacritics if needed, like combining underlines).
- the first one can be to render the previous cluster as superscrip
Philippe, I agree that we could have structured the UCA differently. It
does make sense, for example, to have the weights be simply decimal values
instead of integers. But nobody is going to go through the substantial work
of restructuring the UCA spec and data file unless there is a very strong
re
On 03/11/2018 23:50, James Kass via Unicode wrote:
When the topic being discussed no longer matches the thread title,
somebody should start a new thread with an appropriate thread title.
Yes, that is what also the OP called for, but my last reply though
taking me some time to write was sent w
11 matches
Mail list logo
