Re: Allowing \N to accept hex numbers?

[Dorai Sitaram]

 Hi Oliver,

Actually, thank you for independently confirming that there's no easy way to 
access the ZD code points using hex.

The appeal of the ZD (ITC Zapf Dingbats) font is that it offers quite a large 
collection (201) of useful Unicode symbols without the need to install a 
special Unicode font. The downside of course is that since it's an old-style 
font, it packs all its goodies in a small 256-element table, so the code points 
it uses are definitely not going to match what the same glyphs occupy in a 
bona-fide Unicode font.

Still, almost all of us use UTF8-encoding in our input documents, it is 
convenient to use UTF8 versions of these symbols while text-editing, and have 
Groff seamlessly translate them into the corresponding Zapf Dingbats. That was 
the primary motivation for my question, and I've resigned myself to referring 
to ZD codepoints using decimal. (Hex would have been preferred, because font 
layouts are almost invariably given in hex notation, as, e.g., in 
https://en.wikipedia.org/wiki/Zapf_Dingbats .)

I've uploaded my translation tmac file to https://gitlab.com/ds26gte/zdutf8 for 
those that are interested. Free to use, of course.

--d

     On Monday, January 18, 2021, 07:38:39 AM EST, Oliver Corff 
<oliver.corff@email.de> wrote:  
 
 Hi Dorai,

oops, I did neither anticipate or expect such a behaviour (and use
case). I am sorry.

The question is if whether you intend to access the complete Dingbats
font in this way or just a few characters in it.

If you need every single character of the font, my suggestion for a
workaround will be clumsy, but if it is just a few characters, you can
define one or more strings as in the following example for letter 0x41
(uppercase A).

.\" Define String equivalent from hex input to target output:
.\" This example is ASCII uppercase A first in hex, then in decimal notation
.ds 41 65
.\" Use that string as argument to \N
\N'\*[41]' \" will print char 0x41, or "A"

This is my humble suggestion for a workaround; the elegant way would be
a small function that returns the decimal value of a hex input as to
cover all characters of that font.

If you need just a handful of characters, I think this is the easiest
way; you can pack all ".ds hex dec" definitions in a small file which
you call with
.so myhextodec_lut.roff

Oliver.


On 18/01/2021 02:53, ds26gte--- via wrote:
>  I'm trying to access a code point in a non-Unicode font, namely the ITC Zapf 
>Dingbats font that comes with groff. E.g., the code point 0x6E in Dingbats is 
>a black square, and so far I see no way of using the hex number directly to 
>typeset a black square. I have to convert it to 110 decimal, e.g., 
>\f(ZD\N'110'\fP.
>
> Following your message, I tried using \f(ZD\[u006E]\fP, but no dice. U+006E 
> is of course n, and groff tries to find "special character \n", even though 
> the prevailing font when \[u006E] is being invoked is a non-Unicode font.
>
> --d
>
>      On Sunday, January 17, 2021, 05:46:30 PM EST, Oliver Corff 
><oliver.corff@email.de> wrote:
>
>  Hi Dorai,
>
> is there any constraint that forces you to use \N, or can you use other
> expressions as well? In that case, \[uxxxx] might be the desired answer
> for you, where xxxx is a hex representation of a Unicode code point.
>
> Oliver.
>
>
> On 17/01/2021 19:34, Dorai Sitaram wrote:
>> \N'num' takes a number num and typesets the glyph corresponding to the code 
>> point num in the prevailing font. Currently, num can only be in decimal 
>> format. Is there a downside to allowing hex numbers, with the usual 
>> distinguishing prefix 0x?
>>
>> --d
>>
>