[bug #65716] We don't seem to be using the "latest" glyphlist.txt to generate the tables for afmtodit.

[Deri James]

URL:
  

 Summary: We don't seem to be using the "latest" glyphlist.txt
to generate the tables for afmtodit.
   Group: GNU roff
   Submitter: deri
   Submitted: Wed 08 May 2024 11:47:44 PM UTC
Category: Utilities
Severity: 3 - Normal
  Item Group: Build/Installation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Wed 08 May 2024 11:47:44 PM UTC By: Deri James 
As an example current glyphlist.txt has:-

bqsquare;33C3
braceex;F8F4
braceleft;007B

but our afmtodit.tables file has:-

  "bqsquare", "33C3",
  "braceleft", "007B",

"braceex" is missing. (300+ lines missing). Is there a reason for this? It
seems to have been created 2022-10-09 which is later than the last change to
glyphlist.txt. I have been writing a little tool to document the glyph
properties of the fonts we deliver with groff. The braceex is used in our S
font (see the "Private Use Area" unicode block in S.pdf).
 






___
File Attachments:


---
Name: S.pdf  Size: 47KiB


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-bb6ac47258d6ad8e166786c81860d8aedf63a25a.tar.gz

___

Reply to this item at:

  

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

[bug #64155] [troff] specifying -fZD on command line generates warnings

[Dave]

Follow-up Comment #39, bug #64155 (group groff):

Self-followup:

[comment #37 comment #37:]
> in a way back compatible to almost any older troff.

Obviously, this specific example is not AT due to the long names,
but the logic can be written portably.


___

Reply to this item at:

  

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

[bug #65710] [preconv] require disambiguation of U+00A0 on input

[Dave]

Follow-up Comment #1, bug #65710 (group groff):

[comment #0 original submission:]
> an input U+00A0...: is it a fixed-width non-breakable space, or a
> variable-width non-breakable space?  Unicode does not distinguish.

Unicode intentionally provides some latitude to rendering engines to make the
best typographical decisions they can.  That is, Unicode is not really a
driving factor here; the only Unicode requirement of U+00A0 is that it be
nonbreaking, and both "\ " and "\~" meet that requirement.

Since 2003 ([http://git.savannah.gnu.org/cgit/groff.git/commit/?id=48615a44
commit 48615a44]), groff_char(7) has said "the ISO Latin-1 no-break space is
mapped to `\~', the stretchable space character."  While this claim was
erroneous until bug #58962 addressed it (and remains erroneous with certain
fonts, per bug #65693), it has always been the most typographically sound
solution.

I think groff should strive to do by default what makes most typographic
sense, and (as #58962 argued) there are few if any situations where "\ " is
preferable to "\~".

> This is analogous to how we don't know whether a man page
> author means a hyphen or a minus sign when they type `-`.

Weakly analogous:
* Hyphens and minus signs are different semantically.  The two types of
nonbreaking spaces are different only presentationally.
* Hyphens and minus signs must copy to the clipboard as different characters;
both types of nonbreaking spaces will possibly copy as U+00A0, though more
probably (and more usefully to the user in most cases) copy as an ordinary
space.

> 2.  Add an option instructing preconv which escape sequence to
> transform U+00A0 into.

I don't oppose an option to _override_ the default escape preconv uses, but
its current default is sound.  (Still, I would question the need for such an
option, since users can always specify either escape directly in the source,
and preconv won't touch it.)


___

Reply to this item at:

  

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