[bug #63018] font/devps/ZD: make glyphs accessible via their Unicode spellings

[Dave]

URL:
  

 Summary: font/devps/ZD: make glyphs accessible via their
Unicode spellings
 Project: GNU troff
   Submitter: barx
   Submitted: Mon 05 Sep 2022 05:17:12 AM CDT
Category: Font devps
Severity: 1 - Wish
  Item Group: Feature change
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Mon 05 Sep 2022 05:17:12 AM CDT By: Dave 
Only two glyphs in ZD have names (\[OK] and \[rh]); the rest must be accessed
with the \N escape.

But all of these glyphs have Unicode code points.  The font description file
ought to recognize those names (in \[u] format) as well.

The work here has already been done, submitted on the email list a while back
(http://lists.gnu.org/r/groff/2021-01/msg00061.html); it remains only to
integrate this into groff.

The devps/ZD that that post points to is nearly a drop-in replacement (minus a
few header lines) for font/devps/ZD in git, so I'm tempted to characterize
this ticket as a [PATCH].  However, for completeness, at least one additional
thing could be done: defining aliases (probably in tmac/ps.tmac) for \[OK] and
\[rh] so that they can also be represented respectively by \[u2713] \[u261E]
(the forms that, for instance, preconv will emit).







___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63018] font/devps/ZD: make glyphs accessible via their Unicode spellings

[Dave]

Follow-up Comment #1, bug #63018 (project groff):

Adding the author of the patched ZD to this ticket's cc: list in case he has
further thoughts on its integration into groff.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63018] font/devps/ZD: make glyphs accessible via their Unicode spellings

[Dave]

Follow-up Comment #2, bug #63018 (project groff):

[comment #0 original submission:]
> \[u2713] [and] \[u261E] (the forms that, for instance, preconv will emit)

...unless bug #58796's proposal grows up to be a real preconv switch.  (But
even that wouldn't remove the need for the \[u] forms, as it would be the
user's discretion whether to employ that preconv switch.)


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63018] font/devps/ZD: make glyphs accessible via their Unicode spellings

[Dave]

Follow-up Comment #3, bug #63018 (group groff):

[comment #0 original submission:]
> defining aliases (probably in tmac/ps.tmac) for \[OK] and \[rh] so
> that they can also be represented respectively by \[u2713] \[u261E]

On further thought, because these aliases should apply to both the ps and pdf
devices, they shouldn't be in a file that only the ps device reads.

Luckily, the font description file itself includes a mechanism to define
aliases for the same glyph.  From the info manual:

   A line in the 'charset' section can also have the form

 NAME "

identifying NAME as another name for the glyph mentioned in the preceding
line.

(On first blush, it may seem that defining this alias in font/devps/ZD still
only applies to the ps device.  However, font/devpdf is populated from
font/devps, so aliases in the devps font description file propagate to the
devpdf one.)


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63018] font/devps/ZD: make glyphs accessible via their Unicode spellings

[G. Branden Robinson]

Follow-up Comment #4, bug #63018 (group groff):

[comment #3 comment #3:]
> On further thought, because these aliases should apply to both the ps and
pdf devices, they shouldn't be in a file that only the ps device reads.
> 
> Luckily, the font description file itself includes a mechanism to define
aliases for the same glyph.  From the info manual:

>A line in the 'charset' section can also have the form
> 
>  NAME "
> 
> identifying NAME as another name for the glyph mentioned in the preceding
line.


> (On first blush, it may seem that defining this alias in font/devps/ZD still
only applies to the ps device.  However, font/devpdf is populated from
font/devps, so aliases in the devps font description file propagate to the
devpdf one.)

I like this idea.

If there's anything in ZDR that should be similarly mapped, let's take care of
that as well.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63018] font/devps/ZD: make glyphs accessible via their Unicode spellings

[Deri James]

Follow-up Comment #5, bug #63018 (group groff):

Probably the best way of doing this is by adding to dingbats.map, a suitable
one is attached (to replace the one in font/devps/generate). Also attached is
a replacement ZD file to be placed in fonts/devps. Doing make will propagate
the changes to devpdf and when U-ZD is created it will use the new
dingbats.map.

The attached .trf file includes all the characters in the unicode 2700 code
page (see U2700.pdf). When you run it you will see that some code points are
missing from the font, this probably because the font was created before
unicode and there have been numerous changes.

ZDR is a different kettle of fish! It does not make sense reversing many of
the glyphs, and they would not have unicodes anyway. We currently only have
one entry in reversed-dingbats.map, for \[lh]. For gropdf we have it defined
in pdf.tmac as:-

.char \[lh] \X'pdf: xrev'\[rh]\X'pdf: xrev'


(file #55989, file #55990, file #55991, file #55992)

___

Additional Item Attachment:

File name: ZD Size: 6KiB


File name: dingtst.trfSize: 1KiB


File name: dingbats.map   Size: 2KiB


File name: dingtst.pdfSize: 49KiB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-02a92bc3de37203138822bd2520e89ef55345685.tar.gz


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/