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