It just crossed my mind that this branch of a discussion from
povray.off-topic might be of general interest and worth preserving:

Am 19.06.2018 um 08:57 schrieb clipka:
> Am 19.06.2018 um 02:39 schrieb William F Pokorny:
> 
>> Doesn't preclude the need for full plane 0+ support, but I'll mention a
>> few years ago I was playing in POV-Ray with Egyptian hieroglyphs in
>> particular - as well as a couple other plane 1 and plane 2 fonts.
>>
>> Using the AegyptusSubset.ttf at:
>>
>> https://mjn.host.cs.st-andrews.ac.uk/egyptian/fonts/newgardiner.html
>>
>> I could render the 13044 human with club/staff character with:
>>
>> #declare Text00 = text {





>> }
>>
>> In other words, while I never worked out how it works, once you find the
>> 'wrapped' base hex value you can index from there so long as working
>> with an extracted font with just the plane 1 or 2 values. I was already
>> working with font subsets of plane 1 and 2 so unsure how to extract just
>> plane 1 or plane 2 from a font with plane 0 too. A potential hack to get
>> at planes 1 and 2 today - for what it's worth I guess.
> 
> Actually that's still accessing the BMP, and it's not a hack but a
> feature of that particular font: Since it only deals in hieroglyphs, it
> can provide a mapping of all its glyphs into the Private Use Area of the
> BMP (U+E000 to U+F8FF).
> 
> "Complete" fonts do not have this luxury, as the currently assigned code
> points outside the BMP far exceed the 6400 code points of the BMP
> Private Use Area.
> 
> Also, even specialized fonts are not required to provide such a Private
> Use Area mapping.
> 
> Even if a font provides a PUA mapping, the mapping may be systematically
> different from the officially assigned mapping outside the BMP. For
> example, the PUA mapping might reflect an experimental mapping predating
> official inclusion into the Unicode standard.
> 
> And last not least, applications dealing with UCS characters are free to
> use Private Use Area code points for special purposes, so there's no
> guarantee that future versions of POV-Ray will continue to provide full
> support for this mechanism; for instance, in overhauling the parser I
> was (and still am) toying with the idea of setting aside 128 of those
> code points to internally represent non-ASCII octets from source files
> for which the character encoding is not (yet) known; such code points
> would be translated "back" by a later stage of the parser, even if they
> happen to have been entered via "\uNNNN".
>

Post a reply to this message