[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Dave]

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

Don't read too much into my opening multiple tickets: they're not saying
"THESE THINGS MUST BE DONE" but giving venues to consider and discuss separate
issues without cluttering this bug.  At least that was the theory. ;-}  Any
ticket can be closed without action taken if that ultimately seems the right
approach.

[comment #22 comment #22:]
> If vintage afm files are not forthcoming, then (2 - makefile
> target) is moot.

Perhaps, or perhaps it's worth implementing anyway so as to be ready if the
files ever materialize.  Either way, that discussion has little to do with
this ticket's focus (the ZD characters).

> But this already has its own bug #65659 which is assigned to
> me and I'm doing font research.

(This presumably means bug #65619, as 65659 is for another project.)

Bug #65619 seems to cover different ground than bug #65697.  Neither one seems
dependent on the other to me, though if I'm wrong, savannah now allows showing
bug dependencies.


___

Reply to this item at:

  

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

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Deri James]

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

Speaking about afmtodit only.

If vintage afm files are not forthcoming, then (2 - makefile target) is moot.

Only (1) is not dependent and that will be done when I rejig afmtodit to:-

Look for different 'spaces' to set 'spacewidth'.
Implement -ww switch - force even if 'space' found.
Warn if -w used and 'space' found (but advise rerun with -ww to override).
Document if -w or -ww used in font header comments.

But this already has its own bug #65659 which is assigned to me and I'm doing
font research.


___

Reply to this item at:

  

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

[bug #65702] tmac/doc.tmac: previous state of compatibility (register '.cp') is not restored at end

[Dave]

Update of bug #65702 (group groff):

  Status:None => Need Info  

___

Follow-up Comment #1:

This situation dates back to primordial groff.

The current .cp line was introduced in the 2001 rewrite of doc.tmac in
[http://git.savannah.gnu.org/cgit/groff.git/commit/?id=058f72af8 commit
058f72af8].  That rewritten version did not save/restore the previous mode,
and no one seems to have added such logic subsequently.

The pre-2001 doc.tmac file was imported (from a Berkeley version) in 1992 in
groff 1.05 ([http://git.savannah.gnu.org/cgit/groff.git/commit/?id=a48ab7b6d
commit a48ab7b6d]), when it lived at macros/tmac.doc.  This version of the
file also blindly did a ".cp 0" without saving or restoring the previous mode
(presumably a James Clark customization of the Berkeley file).

So it seems intentional, or at least hasn't caused any reported misbehavior in
over 30 years.  Do you see any properly formed mdoc document misbehaving
because of the hard-coded mode?

[comment #0 original submission:]
> previous state of compatibility (register '.cp') is not restored 

The request to change the mode is ".cp".  The corresponding register is ".C".


___

Reply to this item at:

  

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

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Dave]

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

True for the third ticket of that trio, but the first two can be implemented
regardless of the fate of the old AFM files.

As for the third, it documents a different issue from this ticket and should
have its own venue, so that when this ticket is closed, side conversations
about development goals aren't forgotten.  If a fix proves not doable --
whether because the original AFM files are lost in the mists of time, or for
any other reason -- that ticket can document the reason(s).


___

Reply to this item at:

  

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

[bug #65702] tmac/doc.tmac: previous state of compatibility (register '.cp') is not restored at end

[Bjarni Ingi Gislason]

URL:
  

 Summary: tmac/doc.tmac: previous state of compatibility
(register '.cp') is not restored at end
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Mon 06 May 2024 08:36:27 PM UTC
Category: Macro package mdoc
Severity: 3 - Normal
  Item Group: Incorrect behaviour
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Mon 06 May 2024 08:36:27 PM UTC By: Bjarni Ingi Gislason 
Subject: tmac/doc.tmac: previous state of compatibility (register
'.cp') is not restored at end

  There is only this

.do if d Dd .nx
.
.
.cp 0
.
.
.\" Define a string for use in diagnostic messages.








___

Reply to this item at:

  

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

[bug #65701] tmac/doc.tmac: extra '.ec'

[Bjarni Ingi Gislason]

URL:
  

 Summary: tmac/doc.tmac: extra '.ec'
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Mon 06 May 2024 08:25:51 PM UTC
Category: Macro package mdoc
Severity: 3 - Normal
  Item Group: Lint
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Mon 06 May 2024 08:25:51 PM UTC By: Bjarni Ingi Gislason 
Subject: tmac/doc.tmac: extra '.ec'

.ec
.
.blm doc-empty-line
.
.
.ec
.
.








___

Reply to this item at:

  

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

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Deri James]

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

This might be a bit previous! Whether we should regenerate the grops font
files is rather dependent on whether Branden is successful in locating afm
files of a suitable vintage so that running current afmtodit will generate
fonts with compatible meta-data capable of duplicating existing documents.

The problem is shown in https://savannah.gnu.org/bugs/?63018#comment14


___

Reply to this item at:

  

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

[bug #57506] Suspicious "slant" values in devps/TI, devlbp/HI, devlbp/HBI

[Dave]

Follow-up Comment #15, bug #57506 (group groff):

[comment #2 comment #2:]
> It seems to me that these files should be regenerated, if not
> on every build, then at least for every release.

Now bug #65699.


___

Reply to this item at:

  

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

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Dave]

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

[comment #13 comment #13:]
> In fact I see two issues springing thence.  So, to summarize.
> 
> 1.  Make comment headers of font description files we generate
> with tools more informative.

Now bug #65697.

> 2.  Add "maintainer-font-descriptions" _make_(1) targets for
> _afmtodit_ and maybe _hpdftodit_ and _tfmtodit_.

Now bug #65698.

> 3.  Update the procedure documented in "FOR-RELEASE" to include
> the effects of item 2 above.

Now bug #65699, depending on the previous one.


___

Reply to this item at:

  

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

[bug #65699] Update the procedure documented in "FOR-RELEASE"

[Dave]

Update of bug #65699 (group groff):

  Depends on: => bugs #65698


___

Reply to this item at:

  

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

[bug #65699] Update the procedure documented in "FOR-RELEASE"

[Dave]

URL:
  

 Summary: Update the procedure documented in "FOR-RELEASE"
   Group: GNU roff
   Submitter: barx
   Submitted: Mon 06 May 2024 11:18:05 AM CDT
Category: Utilities
Severity: 1 - Wish
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Mon 06 May 2024 11:18:05 AM CDT By: Dave 
Branden wrote in bug #63018:

Update the procedure documented in "FOR-RELEASE" to include the effects of
[bug #65698, which proposes to add new make(1) targets for *todit utilities].







___

Reply to this item at:

  

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

[bug #65698] Add "maintainer-font-descriptions" make(1) targets for *todit utilities

[Dave]

URL:
  

 Summary: Add "maintainer-font-descriptions" make(1) targets
for *todit utilities
   Group: GNU roff
   Submitter: barx
   Submitted: Mon 06 May 2024 11:12:29 AM CDT
Category: Utilities
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 06 May 2024 11:12:29 AM CDT By: Dave 
Branden wrote in bug #63018:

Add "maintainer-font-descriptions" _make_(1) targets for _afmtodit_ and maybe
_hpdftodit_ and _tfmtodit_.  (This might depend on what source material we
already have in the tree.  If such material is missing (or so stale we should
toss it out), we might need to document further maintainer-mode build
dependencies in "INSTALL.REPO".)







___

Reply to this item at:

  

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

[bug #65697] Add info to comment headers of font description files groff tools generate

[Dave]

URL:
  

 Summary: Add info to comment headers of font description
files groff tools generate
   Group: GNU roff
   Submitter: barx
   Submitted: Mon 06 May 2024 11:03:53 AM CDT
Category: Utilities
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 06 May 2024 11:03:53 AM CDT By: Dave 
As mentioned in bug #63018, afmtodit's generated headers could additionally
include the names of the source files that generate them, and the
presence/values of command-line options that affect the generated contents.

Branden also notes there, "Could affect _afmtodit_, _hpftodit_, _tfmtodit_,
_addftinfo_, and _xtotroff_."







___

Reply to this item at:

  

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

[bug #65585] [gropdf] problems introduced by commit cd9fde325f

[G. Branden Robinson]

Update of bug #65585 (group groff):

  Status:   Need Info => Fixed  

___

Follow-up Comment #9:


commit a951b44fd9d2acf060067b24c994604351a27888
Author: Deri James 
Date:   Tue Apr 30 15:25:49 2024 +0100

[gropdf] Re-arrange pattern matches.

* src/devices/gropdf/gropdf.pl: Correct order of pattern
match.

Fixes https://savannah.gnu.org/bugs/?65585 (again!)




___

Reply to this item at:

  

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

[bug #62300] [preconv] does not handle U+00A0 (NBSP) as it should

[Dave]

Follow-up Comment #9, bug #62300 (group groff):

[comment #7 comment #7:]
> if the above is in fact the case, one of us should open a new bug report.

Bug #65693


___

Reply to this item at:

  

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

[bug #65693] exceptions to NBSP statement in groff_char(7) should be documented

[Dave]

URL:
  

 Summary: exceptions to NBSP statement in groff_char(7) should
be documented
   Group: GNU roff
   Submitter: barx
   Submitted: Mon 06 May 2024 02:06:11 AM CDT
Category: Core
Severity: 2 - Minor
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Mon 06 May 2024 02:06:11 AM CDT By: Dave 
groff_char(7) states, "a no-break space... is mapped to \~, the adjustable
non-breaking space escape sequence."

But as Deri and Bjarni point out in bug #62300, some fonts (including many URW
fonts groff installs for devpdf) include a u00A0 glyph, which is necessarily
of a fixed width.

Demonstration (when using -Tpdf):

.ft U-TR
a b c
.brp
a b\~c
.brp
a b\[u00A0]c
.brp

The results are the same if "\[u00A0]" is replaced with the corresponding
Latin-1 character.







___

Reply to this item at:

  

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