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

[Deri James]

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

I have been investigating the AFMs Branden found with a view to using them as
a way to recreate the grops fonts, particularly in situations where there have
been changes to the maps, encoding files and afmtodit itself. Since the last
release afmtodit, and dingbats map have been altered, and the grops fonts have
been hand edited by me to add the UTF-16 code as a comment. Afmtodit is to be
changed soon to add the new spacewidth algorithm and improvements to the font
comments.

For all these reasons it would be convenient to have an automated procedure
which generates the grops fonts. The attached grops-fonts-AFMs.tar.gz has
everything required to do this. It contains the afms from the
Adobe-Core35_AFMs-229.tar.gz from CTAN, with one change, the Symbol.afm has
been replaced with symbol.afm from the git grops directory, since I suspect
this has been edited to work best with eqn. Investigation showed that the
original Symbol.afm from the 229 tar.gz produced different italic corrections,
whereas the copy from the grops directory produces identical results.

All the AFMs have had the ellipsis kerning lines added, (see script
EllipsisFix.sh - a blatant rip off from Daves code in bug #58897 - except it
now operates on the KPX lines in the AFM files, so no need to run it again,
but left in place to show what was done).

The script BuildPSfonts.pl runs afmtodit with the correct parameters. It takes
4 parameters:-

BuildPSfonts.pl [-F font-directory] [-map directory-with-map-files] [-enc
directory-with-enc-files] [-afm directory-with-afm-files]

>From the build directory I ran it with this parameter:-

./BuildPSfonts.pl -F ./devps -enc ../font/devps -map ../font/devps/generate
-afm grops-fonts-AFMs

Note I used a separate directory for the new fonts so I could then compare
them with the current files for checking.

When you check the results you will notice a few differences:-

The final glyph in each file has a different UTF-16 comment, the new versions
are correct, mistake in my hand editing when I committed them, the new
generated files are correct.

In some fonts there is one case where the position of the ellipsis and period
kern lines are swapped, this has no effect, it happens when afmtodit is
processing a glyph alias (i.e. when two groff names refer to the same glyph,
contains just a name and a " in the font entry. In this case generates two
kern entries and sorts them alphabetically. Dave's sed script which added an
epsilon kern after each '.' kern, so the order would be like this:-

. rq -70
u2026 rq -70
. ' -70
u2026 ' -70

Whereas afmtodit sorts the kern list alphabetically so it becomes:-

. rq -70
. ' -70
u2026 rq -70
u2026 ' -70

This has no effect.

The S font has the most changes. There is a new glyph Upsilon which is not in
the current font, and it is given the groff name "u03A5" rather than *U,which
is assigned to 03D2 "GREEK UPSILON WITH HOOK SYMBOL", so I don't think this
will cause an issue. The rest of the difference are all to do with the comment
field and have no effect.

The SS font is a problem. There is a file called symbolsl.afm in the devps
directory which one could reasonably assume was used to produce the SS file
via afmtodit. However, if you look at the file you will see it has problems:-

C 33 ; WX 333 ; N exclam ; B 128 -13 240 686 ;

The width is shown as 333, but this produces:-

--- 296,598,15,137,-73,99   3   33  exclam

Where the width is now 296 (=333*.89) and the height goes from 673 (686-13) to
598 (=673*.89). The .89 factor is from the transformation applied to the
normal symbol file in the file symbolsl.ps:-

%%IncludeResource: font Symbol

/Symbol-Slanted
[.89 0.0 15.5 dup sin exch cos div .89 0.0 0.0]
/Symbol
MakeTransformedFont

Which seems to be a zoom factor plus either a rotate or shear transformation
(my maths is not up to it). I was 17 before I had my first proper maths
lesson, the benefits of going to a school where you are not expected to be
academic. :-)

So I don't think we can faithfully reproduce the SS font from source files,
unless someone is mathematical enough to apply a transformation to the llx,
lly, urx, ury (which defines a rectangle) so if someone can convert the
postscript transformation to a formula which converts the rectangle, we could
add it as an option to afmtodit

Another issue which applies to SS, is that because it is defined in DESC fonts
before the S font and will be searched first, it is important that only the
symbol glyphs we want to become slanted (i.e. lowercase greek for equations)
are named, the rest need to be unnamed (---) so groff will look for them in
the normal symbol font instead. This script does that as well.

I have done a fair bit of work on this, because I think it is important we
have the ability to recreate the grops fonts, but I am now stuck: need help
with the maths outlined above and also guidance on implementing this as a make
target.

(file #56053)

[bug #62916] list things to deprecate

[Dave]

Follow-up Comment #8, bug #62916 (group groff):

Related: bug #65724 seeks to deprecate EBCDIC.  However, if it goes through as
contemplated, it won't make it onto the list proposed by this ticket, because
there won't be a release where it's deprecated but still functional.


___

Reply to this item at:

  

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

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

[G. Branden Robinson]

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

So here's what got lost last week.

I did in fact implement a string comparison conditional operator in GNU
_troff_ in my working copy.

And it worked.


$ git stash show -p 1
diff --git a/src/roff/troff/input.cpp b/src/roff/troff/input.cpp
index 8d828a01e..7288f31c5 100644
--- a/src/roff/troff/input.cpp
+++ b/src/roff/troff/input.cpp
@@ -6002,6 +6002,25 @@ static bool do_if_request()
 }
 result = is_abstract_style(nm);
   }
+  else if (c == '~') {
+tok.next();
+symbol nm1 = get_name(true /* required */);
+symbol nm2 = get_name(true /* required */);
+if ((nm1.is_null() || nm2.is_null())) {
+  skip_branch();
+  return false;
+}
+macro *rm1 = static_cast(request_dictionary.lookup(nm1));
+macro *rm2 = static_cast(request_dictionary.lookup(nm2));
+macro *m1 = rm1->to_macro();
+macro *m2 = rm2->to_macro();
+if ((0 /* nullptr */ == m1) || (0 /* nullptr */ == m2)) {
+  error("cannot perform equality comparison on a request");
+  skip_branch();
+  return false;
+}
+result = (*m1 == *m2);
+  }
   else if (tok.is_space())
 result = false;
   else if (tok.is_usable_as_delimiter()) {


But I immediately thought better of it.

1.  We already have 


.if '\?foo\?'\?bar\?' .tm strings are equal


2.  The `\?` escape sequence is already a GNU _troff_ extension.

3.  I didn't feel good about adding syntactic sugar for this form of
expression.

4.  String comparisons are rare outside of macro files.

5.  Macro files desiring to do string comparisons should decide whether they'd
rather let them be formatted (a popular choice, even in _groff_'s own macro
files) or not.  In most cases there is no harm in performing formatting on the
comparands.  (Where there is, you _must_ use `\?`.)

...

This is growing long.  I will return to it later.


___

Reply to this item at:

  

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

[bug #65724] drop support for CCSID (code page) 1047 (EBCDIC)

[G. Branden Robinson]

Follow-up Comment #2, bug #65724 (group groff):


commit 25b0662e69c1d63b910262deee61915c59f13dc5
Author: G. Branden Robinson 
Date:   Sat May 11 09:40:49 2024 -0500

Start dropping CCSID (code page) 1047 (EBCDIC).

Begin withdrawing support for CCSID (code page) 1047 (EBCDIC).

* tmac/X.tmac:
* tmac/Xps.tmac:
* tmac/dvi.tmac:
* tmac/html.tmac:
* tmac/ps.tmac: Stop loading "latin1.tmac" or "cp1047.tmac" depending on
  the special character `\[char97]` matching "a".

* tmac/troffrc: Simplify logic; map special character `\[char160]` to
  `\~` unconditionally.

Begins fixing .

commit 2d04649dafa60f182765ea87e8e5b08ddeec3dc1
Author: G. Branden Robinson 
Date:   Mon May 13 13:13:30 2024 -0500

[docs]: De-document {latin1,cp1047}.tmac loading.




___

Reply to this item at:

  

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

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

[G. Branden Robinson]

Update of bug #64155 (group groff):

  Status: In Progress => Fixed  
 Open/Closed:Open => Closed 

___

Follow-up Comment #41:

I'll follow up with a brief (I hope) recapitulation of my lost comment.

The following bug-closing context will help reduce the length of that.


commit 609d962fc02e517744ee4f68160648a78df3a020
Author: G. Branden Robinson 
Date:   Sat May 11 09:54:35 2024 -0500

[tmac]: Perform actual string comparisons.

* tmac/fallbacks.tmac:
* tmac/troffrc-end: Bracket comparands to formatted output comparison
  operator with `\?` escape sequences to perform a more elementary
  string comparison on them (cf. a comparison of _formatted text_).
  This way they continue to perform their function even if the default
  font family has no coverage of Basic Latin (not a bizarre choice when
  considering potential rendering of documents using Devanagari or East
  Asian languages).  Unfortunately this means of comparing strings,
  while long documented in the GNU troff Manual, is neither idiomatic
  for *roff macro programmers nor portable to AT troff.  (The *roff
  language historically _lacks_ a string comparison operator.)  Each
  macro package will have to decide for itself whether it wants to have
  portability at the expense of requiring Basic Latin coverage (possibly
  switching fonts before and after a formatted output comparison for the
  sole purpose of obtaining it).  These two files are unconditionally
  loaded by the stock `troffrc`, and therefore must be dealt with in any
  case.

Fixes .  Thanks to Dave Kemper for
the report, and to him, Peter Schaffter, and Deri James for the
discussion.

Previously:

$ echo | groff -fZD -a
troff:/.../groff/1.23.0/tmac/fallbacks.tmac:14: warning: character 'p' not
defined
troff:/.../groff/1.23.0/tmac/fallbacks.tmac:14: warning: character 's' not
defined
troff:/.../groff/1.23.0/tmac/fallbacks.tmac:14: warning: character 'a' not
defined
troff:/.../groff/1.23.0/tmac/fallbacks.tmac:14: warning: character 'c' not
defined
troff:/.../groff/1.23.0/tmac/fallbacks.tmac:14: warning: character 'i' not
defined
troff:/.../groff/1.23.0/tmac/fallbacks.tmac:16: warning: character 'l' not
defined
troff:/.../groff/1.23.0/tmac/fallbacks.tmac:16: warning: character 't' not
defined
troff:/.../groff/1.23.0/tmac/fallbacks.tmac:16: warning: character 'n' not
defined
troff:/.../groff/1.23.0/tmac/fallbacks.tmac:17: warning: character 'u' not
defined
troff:/.../groff/1.23.0/tmac/fallbacks.tmac:17: warning: character 'f' not
defined
troff:/.../groff/1.23.0/tmac/troffrc-end:7: warning: character 'h' not
defined
troff:/.../groff/1.23.0/tmac/troffrc-end:7: warning: character 'm' not
defined


Now:

$ echo | ./build/test-groff -fZD -a





___

Reply to this item at:

  

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

[bug #65729] tmac/an.tmac: macro 'EX' is defined with 'de1' but 'EE' is not

[G. Branden Robinson]

Update of bug #65729 (group groff):

  Status: In Progress => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:None => 1.24.0 
 Summary: an.tmac: macro 'EX' is defined with 'de1' but 'EE'
is not => tmac/an.tmac: macro 'EX' is defined with 'de1' but 'EE' is not

___

Follow-up Comment #2:


commit f66cd8444ebd1531f81f69530ac7bc2f0c740a97
Author: G. Branden Robinson 
AuthorDate: Mon May 13 13:02:27 2024 -0500

[man]: Fix Savannah #65729 (`de1 EE`).

* tmac/an.tmac (EE): Define macro with `de1` request, not `de`.

Fixes .  Thanks to Bjarni Ingi
Gislason for the report.  Problem introduced by me in commit 15f8188656,
21 February 2022.

As a comment in the file notes:

Macros that are part of the external interface (TH, SH, P, etc.) or that
are called by traps of any kind must be defined with `de1` because they
might be called from a context where compatibility mode is enabled.  For
other macros, `de` suffices.




___

Reply to this item at:

  

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