Custom characters (was: Re: Private Use Area in Use)

[John]

It occurs to me that the existing DNS system was designed to map 32bit numbers to domain names. So a hypothetical UTF64 format, with 32 bits of provider ID could be co-opted into the DNS system under a different record domain (Similar to how there is A records, and MX records, there could be UTF records.)




Then all that would need defining would be some kind of directory hierarchy convention. Like /codepoint-number/font-type/font-size or whatever, and rendering engines could automatically lookup DNS, download from the web site via HTTP the font or bitmap or whatever, and seamlessly show you the right character. It wouldn’t be overly hard to implement, and a format without headers like this one, in the same general style as UTF-16 and UTF-32, wouldn’t upset the normal programming style of working with characters, so programming languages and existing apps wouldn’t have that much difficulty in upgrading. Mostly just a matter of upgrading the character size.




I think this stuff could be relatively easy to define and standardise. You could basically define the entire technology in 1 A4 document. People have just got to want it badly enough to agree on it, and give it the imprimatur of the consortium.


—
Chris

On Thu, Jun 4, 2015 at 6:49 PM, William_J_G Overington
<wjgo_10009 at btinternet.com> wrote:

> Chris expressed an idea, hypothetically starting:
>> Characters are 64 bit.
> The following posts might be helpful.
> http://www.unicode.org/mail-arch/unicode-ml/y2011-m08/0277.html
> http://www.unicode.org/mail-arch/unicode-ml/y2011-m08/0307.html
> For 64 bits, or somewhere in that region, maybe just a few bits less, a longer sequence of high surrogate characters followed by a low surrogate character could possibly be used.
> I did also find the following post.
> http://www.unicode.org/mail-arch/unicode-ml/y2012-m11/0256.html
> I thought that I would mention it, though I cannot quite at the moment understand the issue.
> William Overington
> 4 June 2015
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20150604/b5828cf9/attachment.html>