I think CYFI has characters in the PUA for "lost sign" and "damaged sign".
Both are shaded squares using different patterns.
On Wed, Dec 21, 2016 at 3:49 PM, Richard Wordingham <
richard.wordingham_at_ntlworld.com> wrote:
> On Wed, 21 Dec 2016 02:29:59 +0000
> Martin Mueller <martinmueller_at_northwestern.edu> wrote:
>
> > I’m new to this list. Please excuse my technical incompetence.
> > Is there a Unicode character that says “I represent an alphanumerical
> > character, but I don’t know which”. This is a very common problem in
> > the transcription of historical texts where you have lacunas. Often,
> > the extent of the lacuna is known, and the alphabet is known as well.
>
> U+FFFD REPLACEMENT CHARACTER says that one can't represent (or
> interpret) the specified character as Unicode.
>
> U+3013 GETA MARK says the character isn't encoded, and I suspect
> implies not being available as a usable PUA character.
>
> U+0359 COMBINING ASTERISK BELOW can mean that we have to take someone's
> word for what the character is - he claimed he knew, but we can't see
> the evidence. (That is the meaning given when the character was
> added, but it can have other meanings - I've seen a Thai dictionary
> use it as a nukta.)
>
> The concept here is 'no-one in communication knows for sure what the
> character is'. The usual notation for this is diagonal shading, for
> which CSS mark-up repeating-linear-gradient is now available.
> Graphically, the best character, which may not be considered completely
> appropriate, is
>
> U+26C6 RAIN
>
> Having a general class of symbol_other, just like U+3013, it should
> have the appropriate Unicode properties. I'm just not sure that one
> can justify it as 'something washed the character out' -:) Script
> should only matter if there is a known combining character, in which
> case we are heading for the territory of partial damage marks, which
> generally feel like mark-up.
>
> If we add a bespoke character, it might belong in a punctuation block,
> just as u+3013 does. It represents a gap, like SPACE, but this time,
> generally a hole in the medium of the text.
>
> Richard.
>
>
Received on Wed Dec 21 2016 - 18:00:27 CST
This archive was generated by hypermail 2.2.0 : Wed Dec 21 2016 - 18:00:28 CST