bugGNU roff - Bugs: bug #65098, [PATCH] [devpdf,gropdf] support...

 
 

bug #65098: [PATCH] [devpdf,gropdf] support `SS` font

Submitter:  Deri James <deri>
Submitted:  Sat 30 Dec 2023 11:01:14 PM UTC
   
 
Category:  General Severity:  1 - Wish
Item Group:  Feature change Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.24.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 20 Jun 2025 04:34:39 PM UTC, comment #21: 


commit 74501979860cda474908f534ab67bf33a6bedb87
Author: Deri James <deri@chuzzlewit.myzen.co.uk>
Date:   Fri Jun 20 10:29:22 2025 +0000

    [devpdf,gropdf]: Support `SS` slanted-symbol font.

    Replace pseudo-slanted characters with a real font, improving typography
    of, e.g., slanted lowercase Greek letters as used in eqn(1).

    * font/devpdf/DESC.in: Mount new font `SS` prior to `S`.

    * font/devpdf/SS: New file describes new slanted-symbol font.  The
      metrics are hand-tweaked.  We can't run afmtodit on the symbolsl.afm
      file in grops because it produces incorrect metrics--the width/height
      values do not take into account the rescaling of the glyph sizes by
      .89.

    * font/devpdf/StandardSymSL.pfb: New PostScript font supplies slanted
      versions of glyphs in the standard Symbol font.

    * font/devpdf/devpdf.am (GROFF_FONT_FILES): Update macro definition to
      scan the build directory for file names matching font descriptions,
      excluding both symbol fonts.  Relocate definition to be closer to use.

      (devpdffont_DATA): Add new files "SS", "StandardSymSL.pfb", and
      "download.in".

      (font/devpdf/SS): New target is generated by copying from source tree
      to build tree if they differ.  As a side effect, also copy
      "StandardSymSL.pfb".

      (font/devpdf/util/BuildFoundries): Copy "download.in" file from source
      tree to build tree with new name "download".

      (font/devpdf/download): Set write permission on the target to work
      around GNU Automake "distcheck" feature that makes make(1)-generated
      files read-only; however we want "BuildFoundries" to rewrite the file
      in place.

      (mostlyclean_devpdf_extra): Clean the new files "SS" and
      "StandardSymSL.pfb", as well as "S" since the new regex used to
      populate the `GROFF_FONT_FILES` now overlooks it.

      (install_devpdf, uninstall_devpdf): Explicitly handle "S" font
      description file since the new regex used to populate the
      `GROFF_FONT_FILES` now overlooks it.

    * src/devices/gropdf/gropdf.pl: Support multiple specifications of `-F`
      option, populating new list `fdlist`.  Use the runtime path separator
      to populate scalar `fd` if `fdlist` is not a singleton.

    * tmac/pdf.tmac: Drop all 28 calls of `pdf:SS` macro for 24 lowercase
      Greek letters and 4 variant forms; the slanted-symbol font now
      supplies these.

    Fixes <https://savannah.gnu.org/bugs/?65098>.


G. Branden Robinson <gbranden>
Group administrator
Fri 20 Jun 2025 04:12:46 PM UTC, comment #20: 

comment #19:

> Thank you very much for your help, I know I am terrible at ChangeLog,


Apparently I am too--just look at all the typo fixes I end up committing to it.  :-|

> all that typing, sorry to put it on you.


Not a problem.  Describing the changes helps force me to understand what you did and why.

While I wait for my builds-prior-to-pushing to complete, I have some comments and questions, mostly matters of small detail.

First here's the ChangeLog entry; please review it for accuracy.


commit ed5c81c8486b5160c52b6198f9a6c0726a5c173c (HEAD -> master)
Author: Deri James <deri@chuzzlewit.myzen.co.uk>
Date:   Fri Jun 20 10:29:22 2025 +0000

    [devpdf,gropdf]: Support `SS` slanted-symbol font.

    Replace pseudo-slanted characters with a real font, improving typography
    of, e.g., slanted lowercase Greek letters as used in eqn(1).

    * font/devpdf/DESC.in: Mount new font `SS` prior to `S`.

    * font/devpdf/SS: New file describes new slanted-symbol font.  The
      metrics are hand-tweaked.  We can't run afmtodit on the symbolsl.afm
      file in grops because it produces incorrect metrics]--the width/height
      values do not take into account the rescaling of the glyph sizes by
      .89.

    * font/devpdf/StandardSymSL.pfb: New PostScript font supplies slanted
      versions of glyphs in the standard Symbol font.

    * font/devpdf/devpdf.am (GROFF_FONT_FILES): Update macro definition to
      scan the build directory for file names matching font descriptions,
      excluding both symbol fonts.  Relocate definition to be closer to use.

      (devpdffont_DATA): Add new files "SS", "StandardSymSL.pfb", and
      "download.in".

      (font/devpdf/SS): New target is generated by copying from source tree
      to build tree if they differ.  As a side effect, also copy
      "StandardSymSL.pfb".

      (font/devpdf/util/BuildFoundries): Copy "download.in" file from source
      tree to build tree with new name "download".

      (font/devpdf/download): Set write permission on the target to work
      around GNU Automake "distcheck" feature that makes make(1)-generated
      files read-only; however we want "BuildFoundries" to rewrite the file
      in place.

      (mostlyclean_devpdf_extra): Clean the new files "SS" and
      "StandardSymSL.pfb", as well as "S" since the new regex used to
      populate the `GROFF_FONT_FILES` now overlooks it.

      (install_devpdf, uninstall_devpdf): Explicitly handle "S" font
      description file since the new regex used to populate the
      `GROFF_FONT_FILES` now overlooks it.

    * src/devices/gropdf/gropdf.pl: Support multiple specifications of `-F`
      option, populating new list `fdlist`.  Use the runtime path separator
      to populate scalar `fd` if `fdlist` is not a singleton.

    * tmac/pdf.tmac: Drop all 28 calls of `pdf:SS` macro for 24 lowercase
      Greek letters and 4 variant forms; the slanted-symbol font now
      supplies these.

    Fixes <https://savannah.gnu.org/bugs/?65098>.


The stuff is not gating my push; this ticket simply seems like a good place to discuss some remaining fine details.


diff --git a/font/devpdf/DESC.in b/font/devpdf/DESC.in
index 5cb254f37..a5f5b5a71 100644
--- a/font/devpdf/DESC.in
+++ b/font/devpdf/DESC.in
@@ -6,6 +6,6 @@ unitwidth 1000
 sizes 1000-10000000 0
 styles R I B BI
 family T
-fonts 8 0 0 0 0 0 0 S ZD
+fonts 9 0 0 0 0 0 0 SS S ZD
 tcommand
 postpro gropdf


I'd like to change that a bit.  The "DESC" file for "PS" looks like this:


$ cat ~/groff-1.23.0/share/groff/1.23.0/font/devps/DESC
res 72000
hor 1
vert 1
sizescale 1000
unitwidth 1000
sizes 1000-10000000 0
styles R I B BI
family T
fonts 9 0 0 0 0 0 SS S ZD ZDR
tcommand
postpro grops
broken 0
papersize letter
print lpr


Since the PDF device doesn't need the "ZDR" font at all, I suggest making the font mounting positions "line up" between the two output devices.  So like this.


-fonts 9 0 0 0 0 0 0 SS S ZD
+fonts 8 0 0 0 0 0 SS S ZD


What do you think?


diff --git a/font/devpdf/SS b/font/devpdf/SS
new file mode 100644
index 000000000..a61fa8b7a
--- /dev/null
+++ b/font/devpdf/SS
@@ -0,0 +1,50 @@
+# This file has been generated with GNU afmtodit (groff) version 1.20.1
+#
+#   FullName Symbol Slanted
+#   Version 001.008
+#   FamilyName Symbol
+#
+# The original AFM file contains the following comments:
+#
+#   Notice Copyright (c) 1985, 1987, 1989, 1990, 1997 Adobe Systems Incorporated. All rights reserved.
+#   Comment Copyright (c) 1985, 1987, 1989, 1990, 1997 Adobe Systems Incorporated. All rights reserved.
+#   Comment Creation Date: Thu May  1 15:12:25 1997
+#   Comment UniqueID 43064
+#   Comment VMusage 30820 39997


I'd like to add an annotation to this comment header indicating that the file is manually maintained, and to explain why.  I'd probably copy the same wording I used in the ChangeLog entry, but if you'd like to propose some language, I'd be eager to see it.


+font/devpdf/SS: font/devpdf/download
+       $(AM_V_at)$(MKDIR_P) $(top_builddir)/font/devpdf
+       if [ "$(top_srcdir)" != "$(top_builddir)" ]; then \
+           cp -u $(top_srcdir)/font/devpdf/SS \
+           $(top_srcdir)/font/devpdf/StandardSymSL.pfb \
+           $(top_builddir)/font/devpdf; \
+       fi
+


I'd like to get rid of the side effect of this target, and add a real one for "StandardSymSL.pfa", which we'd generate in the build tree from "StandardSymSL.pfb" using our own pfbtops(1) program.  I piloted this in bug #67207 and it passed a smoke test, at least.


@@ -84,7 +96,12 @@ font/devpdf/util/BuildFoundries: \
                 $(devpdf_srcdir)/util/BuildFoundries.pl \
                 >$(top_builddir)/font/devpdf/util/BuildFoundries; \
           fi \
-       && chmod +x $(top_builddir)/font/devpdf/util/BuildFoundries
+       && chmod +x $(top_builddir)/font/devpdf/util/BuildFoundries \
+       && cp -f $(top_srcdir)/font/devpdf/download.in \
+                $(top_builddir)/font/devpdf/download
+
+GROFF_FONT_FILES=`cd $(top_builddir)/font/devpdf \
+  && grep -ls internalname [A-CEG-RT-Z]*`

 MOSTLYCLEANFILES += font/devpdf/DESC
 font/devpdf/DESC: $(devpdf_srcdir)/DESC.in


Any reason we can't just run "BuildFoundries" with "perl -f", and not bother with changing its permissions?


@@ -134,7 +152,12 @@ mostlyclean_devpdf_extra:
        rm -rf $(top_builddir)/font/devpdf/enc \
          $(top_builddir)/font/devpdf/map;
        if test -d $(top_builddir)/font/devpdf; then \
-         for f in $(GROFF_FONT_FILES); do \
+         for f in $(GROFF_FONT_FILES) S; do \
+           $(RM) $(top_builddir)/font/devpdf/$$f; \
+         done; \
+       fi
+       if [ "$(top_srcdir)" != "$(top_builddir)" ]; then \
+         for f in SS StandardSymSL.pfb; do \
            $(RM) $(top_builddir)/font/devpdf/$$f; \
          done; \
        fi
@@ -144,7 +167,7 @@ install_devpdf:
        @echo Installing devpdf files
        -@test -d $(DESTDIR)$(devpdffontdir) \
          || $(mkinstalldirs) $(DESTDIR)$(devpdffontdir)
-       @for f in $(GROFF_FONT_FILES); do \
+       @for f in $(GROFF_FONT_FILES) S; do \
          $(RM) $(DESTDIR)$(devpdffontdir)/$$f; \
          if test -f $$f; then \
            $(INSTALL_DATA) $$f $(DESTDIR)$(devpdffontdir)/$$f; \
@@ -160,7 +183,7 @@ uninstall_groffdirs: uninstall_devpdf
 uninstall_devpdf:
        @echo Uninstalling devpdf files
        if test -d $(DESTDIR)$(devpdffontdir); then \
-         for f in $(GROFF_FONT_FILES); do \
+         for f in $(GROFF_FONT_FILES) S; do \
            $(RM) $(DESTDIR)$(devpdffontdir)/$$f; \
          done; \
          if test -d $(DESTDIR)$(devpdffontencdir); then \


As previewed in bug #67207, I'd prefer to migrate to a statically populated macro listing "ps" device fonts we expect to support.  As PostScript is now a withdrawn and abandoned standard, I don't think we need to pursue maximum flexibility here.


diff --git a/tmac/pdf.tmac b/tmac/pdf.tmac
index 98fa3ef0e..9571e0148 100644
--- a/tmac/pdf.tmac
+++ b/tmac/pdf.tmac
@@ -38,34 +38,6 @@
 .de pdf:SS
 .      fchar \\$1 \\S'16'\\$1\\S'0'
 ..


As previewed in bug #67207, I'd like to kill off this (undocumented) macro definition too, since we no longer use it, and it is easy for a document author to recreate if they desire it.

Now that I've finished typing this comment, all 4 builds have finished too so I will go ahead and push.  Of course I can amend the ChangeLog entry if you find an error in it.  The commit message is unrevisable, but I'm resigned to that being an aspect of life in Git.

G. Branden Robinson <gbranden>
Group administrator
Fri 20 Jun 2025 03:38:08 PM UTC, comment #19: 

Thank you very much for your help, I know I am terrible at ChangeLog, all that typing, sorry to put it on you.

Deri James <deri>
Group Member
Fri 20 Jun 2025 03:25:30 PM UTC, comment #18: 

(Strictly speaking I didn't apply to master as it appears on Git Savannah; I have 2 unrelated commits before Deri's SSv3...but it still works.)


commit c9cbe4ba3cd3d44b7e1535fd5de987013fd302a6
Author: Dave Kemper <saint.snit@gmail.com>
Date:   Mon Jun 16 05:56:45 2025 +0000

    [troff]: Fix Savannah #67219.

    * src/roff/troff/env.cpp (distribute_space): Fix expression involving
      C++ `static_cast<>` operator to stop permitting integer division
      within, leading to undesired loss of precision when reporting the
      amount of "spread" applied when performing adjustment, as configured
      by the `spreadwarn` request.

      Fixes <https://savannah.gnu.org/bugs/?67219>.  [Problem introduced by
      me in commit 8b6ccbce48, 13 May.  --GBR]

commit 083bb21c6d0db6341761721177feb65063151e1a
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Thu Jun 19 12:28:15 2025 -0500

    ChangeLog: Clarify and correct entry.


G. Branden Robinson <gbranden>
Group administrator
Fri 20 Jun 2025 03:24:25 PM UTC, comment #17: 

Quoting bug #67207:

comment #31:

> A final tweak to avoid the distcheck pause (for 'y' entry).
> Please just apply SSv3.patch to master and confirm there are no build problems, font SS is embedded in groff-man-pages.pdf and I am good to go for commit.
>
> (file #57308)


Yes, I get a successful build in 4 scenarios:

out-of-tree "make all" and "make distcheck"
in-tree "make" and "make distcheck"

I'll compose a "ChangeLog" entry for this and commit.

G. Branden Robinson <gbranden>
Group administrator
Sat 14 Jun 2025 11:30:39 PM UTC, comment #16: 

Adding dep on bug #67207.

G. Branden Robinson <gbranden>
Group administrator
Tue 10 Jun 2025 11:07:49 PM UTC, comment #15: 

comment #14:

> Hi Deri,
>

[...]

> I won't prevail upon you to do that.  I think it'd be better if we had a
> superior font construction story in the first place so we don't have to
> duplicate such workarounds for other fonts in the future.


I have some ideas for improving font handling in groff. Thanks to Kubo Koichi I have a proof of concept version of gropdf which imbeds TrueType/OpenType fonts into pdfs. It also provides ttftodit, avoiding passing through an afm stage where some information can be lost. My ideal would be that groff's font handling was extended so that as well as the current system directories there would be a local cache of fonts (.local/groff - or wherever the proper place for such files should be). This would contain just groff fonts and an index. Further, the .ft and .fam (& .special) would have an extended syntax so that if the name contained a path it is assumed to be a proper system font and groff will search the index in the local cache and if not found groff will run the appropriate tool (afmtodit/ttftodit) and generate a groff font, update the cache index so that if that particular path is used again it will just use the groff font it has just generated. If the path is found in the cache index there is no need to generate the groff font again. It is likely the syntax will also have to include some flags which need to be passed to the *todit generators, although most of the flags currently required can probably be algorithmically determined by analysing the unicode coverage of the glyphs, i.e. the block and category. Similar to what is shown in the attached pdf (glyph coverage of the U-S font).

> I still hold out hope for resolving bug #62932 some day.
>
> > I have noticed commit 66df2be1a90c88efda979305cde588c1ed3e3b7c
> > actually stops gropdf picking up the unicode number from the comment
> > field because it replaced "--\tcode" with "-- code", (I'm splitting
> > the line on tabs so it is one field less), but I do like the intention
> > of the patch, to stop the comment output if there is no unicode.
>
> Ah, I didn't notice any collateral damage.


Yes, if you want a bookmark which contains a named glyph such as \[em], other than names such as \[uXXXX] where the UTF-16 can be arrived at from the name.

> > > I ask for all this stuff because it's hard to get gropdf to find
> > > "StandardSymSL.pfb" to embed it when running it from a build tree
> > > that is not also the source tree.  That is a supported build
> > > scenario (and my usual one).  The "download" file doesn't have any
> > > concept of source tree and build tree; to it, everything is an
> > > installation.
> >
> > I hope the patch to allow multiple -F flags simplifies the problem, SS
> > and the pfb file sit in the src until make install, the same way grops
> > treats its SS.
>
> It quite possibly will, and I'm eager to test it.  I should observe in
> the meantime that I don't think anything else in groff parses a, uh,
> "search path supplementation option" (`-I` and `-M` come to mind on top
> of the aforementioned `-F`) as having an additional list structure, with
> the "runtime path element separator" serving as a field separator.  Only
> the values of environment variables work this way.


gropdf already allowed multiple -I flags, since troff.1 specifically mentions that multiple -I are allowed. -M is not passed to gropdf I believe.

> It's fine if gropdf(1) supports `-F foo:bar` as an extension, though.
>
> I'll double check that claim about other groff programs' `-[FIM]`
> options when I'm not in the midst of non-groff tasks, but if some
> language in troff(1) misleads the reader into thinking otherwise, please
> let me know.


Well it confused me (I know - easy) because the man page specifically mentions multiple instances of -I, whereas the other two refer to environment variables which allow "stacked" directories with ':'.


(file #57284)

Deri James <deri>
Group Member
Tue 10 Jun 2025 06:44:27 PM UTC, comment #14: 

Hi Deri,

At 2025-06-10T12:13:19-0400, Deri James wrote:

> Follow-up Comment #13, bug #65098 (group groff):
> comment #9:
> [...]
> > Also, if you could regenerate the "SS" file using a contemporary
> > afmtodit that records more information, that would be helpful.  Do
> > you have an "afm" file for "StandardSymSL.pfb"?
>
> Not one that "works", for the same reason we can't run afmtodit on the
> symbolsl.afm file in grops, it produces the wrong values because the
> width/height values do not take into account the transformation by
> .89.


I understand (now).

> The > best way of producing the gropdf/SS file is:-
>
> grep -v "^---" src/font/devps/SS
>
> Grops's SS file is the only place with the correct numbers!


Hah!

> I might be able to write a script which tekes the symbol afm file and
> adjusts the numbers so that when run with afmtodit -i 50 it will
> actually generate the correct numbers.


I won't prevail upon you to do that.  I think it'd be better if we had a
superior font construction story in the first place so we don't have to
duplicate such workarounds for other fonts in the future.

I still hold out hope for resolving bug #62932 some day.

> I have noticed commit 66df2be1a90c88efda979305cde588c1ed3e3b7c
> actually stops gropdf picking up the unicode number from the comment
> field because it replaced "--\tcode" with "-- code", (I'm splitting
> the line on tabs so it is one field less), but I do like the intention
> of the patch, to stop the comment output if there is no unicode.


Ah, I didn't notice any collateral damage.

> > I ask for all this stuff because it's hard to get gropdf to find
> > "StandardSymSL.pfb" to embed it when running it from a build tree
> > that is not also the source tree.  That is a supported build
> > scenario (and my usual one).  The "download" file doesn't have any
> > concept of source tree and build tree; to it, everything is an
> > installation.
>
> I hope the patch to allow multiple -F flags simplifies the problem, SS
> and the pfb file sit in the src until make install, the same way grops
> treats its SS.


It quite possibly will, and I'm eager to test it.  I should observe in
the meantime that I don't think anything else in groff parses a, uh,
"search path supplementation option" (`-I` and `-M` come to mind on top
of the aforementioned `-F`) as having an additional list structure, with
the "runtime path element separator" serving as a field separator.  Only
the values of environment variables work this way.

It's fine if gropdf(1) supports `-F foo:bar` as an extension, though.

I'll double check that claim about other groff programs' `-[FIM]`
options when I'm not in the midst of non-groff tasks, but if some
language in troff(1) misleads the reader into thinking otherwise, please
let me know.

G. Branden Robinson <gbranden>
Group administrator
Tue 10 Jun 2025 04:13:13 PM UTC, comment #13: 

comment #9:

> Hi Deri,
>

[...]

> Also, if you could regenerate the "SS" file using a contemporary afmtodit that records more information, that would be helpful.  Do you have an "afm" file for "StandardSymSL.pfb"?


Not one that "works", for the same reason we can't run afmtodit on the symbolsl.afm file in grops, it produces the wrong values because the width/height values do not take into account the transformation by .89. The best way of producing the gropdf/SS file is:-

grep -v "^---" src/font/devps/SS

Grops's SS file is the only place with the correct numbers! I might be able to write a script which tekes the symbol afm file and adjusts the numbers so that when run with afmtodit -i 50 it will actually generate the correct numbers.

I have noticed commit 66df2be1a90c88efda979305cde588c1ed3e3b7c actually stops gropdf picking up the unicode number from the comment field because it replaced "--\tcode" with "-- code", (I'm splitting the line on tabs so it is one field less), but I do like the intention of the patch, to stop the comment output if there is no unicode.

> I ask for all this stuff because it's hard to get gropdf to find "StandardSymSL.pfb" to embed it when running it from a build tree that is not also the source tree.  That is a supported build scenario (and my usual one).  The "download" file doesn't have any concept of source tree and build tree; to it, everything is an installation.


I hope the patch to allow multiple -F flags simplifies the problem, SS and the pfb file sit in the src until make install, the same way grops treats its SS.

Deri James <deri>
Group Member
Tue 10 Jun 2025 01:10:50 PM UTC, comment #12: 

Hi Deri,

Thanks for the prompt and helpful feedback!

At 2025-06-10T08:17:47-0400, Deri James wrote:

> Follow-up Comment #11, bug #65098 (group groff):
> No the source for the .pfb file is actually the URW font for
> Symbol.pfb. I explained how I generated it:
> https://lists.gnu.org/archive/html/groff/2023-06/msg00114.html. It
> also explains some of the problem.


I used that exact message (or a copy of it in Savannah?) to inform the
next commit I have pending after your patch in this ticket. :)


commit 22d65a77d3ac9f0c3b00b538d6d19b2061db3401 (HEAD -> master)
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Mon Jun 9 18:05:28 2025 -0500

    [devpdf]: Add `SS` font support (2/2).

    Ship "StandardSymSL.pfb" embeddable font file and "SS" font description
    file for it.

    * font/devpdf/devpdf.am (DEVPDFFONTFILES_FROM_DEVPS): Add `SS`.
      (font/devpdf/download): Use sed(1) to interpolate an entry for
      "Symbol-Slanted" into the "download" file.

      (install-data-local, install_devpdf, uninstall-local)
      (uninstall_devpdf): Hook into Automake {,un}installation targets to
      cope with heretofore latent bug: gropdf doesn't know how about build
      trees that differ from source trees.  (In fact, it doesn't know about
      environments that aren't installations at all, which is mostly a good
      thing.)  Unfortunately this limitation prevents the
      "StandardSymSL.pfb" file from being embedded in "groff-man-pages.pdf",
      where we'd like to use it for the eqn(1) man page.  As the comment
      notes, if we generate "StandardSymSL.pfb" from source, we can add a
      make(1) rule for it, put its name in the `devpdffontdata` macro, and
      not have to mess with it in these {,un}install hooks at all.  (We
      might want to retain the uninstall hook to remove the `devpdffontdir`
      directory.)

    Fixes <https://savannah.gnu.org/bugs/?65098> (2/2).


> It seems that, although the devps/generate/Makefile has a rule for
> generating freeeuro from source, it only gets run in "maintainer
> mode".  The usual build of freeeuro.pfa is to run psstrip on the
> freeeuro.ps in font/devps to move it from src to dest.


I see.  I wonder if we might contrive something similar for
StandardSymSL.pfb, then.  Maybe generate a PFA version for "maintainer
mode", then convert to PFB.

> Also pertinent is comment #31 in bug #63018 particularly wrt the grops
> SS font. The problem is that each entry in a font has a cell size and
> a glyph shape, the transformation to reduce and slant the glyphs is
> done, it does not apply to the cell size, just the glyph shape, so
> when you ask fontforge to write out the afm file the original cell
> sizes are used for the glyphs width and height, rather than them being
> reduced 89%! There may be a fontforge command to transform the cell
> size on its own, hence my message to the list asking for help and why
> this bug has stalled.


Ah.  Well, we may need to get louder about this.  Maybe Werner can help?
I seem to remember that he's a maintainer of FreeType, and knows a lot
about digital font formats.

I suppose there's always the possibility of shipping an "incorrect" AFM
file, letting users notice it and complain, drawing more light upon this
issue and possibly motivating some annoyed person with expertise to
actually pitch in and help.

> Almost all the groff "static font files" (i.e. files which go straight
> from source directory to install directory) are not touched during a
> make, couldn't SS and StandardSymSL.pfb be treated in a similar
> manner? Alternatively, do what we do with grops symbolsl.ps which uses
> psstrip to essentially move a file from src to dest, cat may be
> useful. :-)


Yeah, we could do a null transformation on the file.  We will need to
rename it, or make(1) will become confused.

I can't push yet, I think because of this very problem.  "make
distcheck" doesn't work because when that target attempts to sanity
check the tar archive constructed by the "dist" target, by conducting an
in-tree build in an oddball location, a problem arises.


for d in /home/branden/src/GIT/groff/build/groff-1.23.0.3392-22d65/_build/sub/doc /home/branden/src/GIT/groff/build/groff-1.23.0.3392-22d65/_build/sub/../../doc; do \
  if [ -f "$d"/groff.info ]; then \
    cp "$d"/groff.info* /home/branden/src/GIT/groff/build/groff-1.23.0.3392-22d65/_inst/share/info; \
    install-info --info-file="$d"/groff.info \
      --info-dir=/home/branden/src/GIT/groff/build/groff-1.23.0.3392-22d65/_inst/share/info; \
    break; \
  fi; \
done
test -d /home/branden/src/GIT/groff/build/groff-1.23.0.3392-22d65/_inst/share/groff/1.23.0/font/devpdf \
  || /bin/bash /home/branden/src/GIT/groff/build/groff-1.23.0.3392-22d65/build-aux/install-sh -d /home/branden/src/GIT/groff/build/groff-1.23.0.3392-22d65/_inst/share/groff/1.23.0/font/devpdf
/usr/bin/install -c -m 644 ../../font/devpdf/StandardSymSL.pfb \
  /home/branden/src/GIT/groff/build/groff-1.23.0.3392-22d65/_inst/share/groff/1.23.0/font/devpdf/StandardSymSL.pfb
/usr/bin/install: cannot stat '../../font/devpdf/StandardSymSL.pfb': No such file or directory
make[4]: *** [Makefile:17568: install_devpdf] Error 1
make[4]: Leaving directory '/home/branden/src/GIT/groff/build/groff-1.23.0.3392-22d65/_build/sub'
make[3]: *** [Makefile:13957: install-am] Error 2
make[3]: Leaving directory '/home/branden/src/GIT/groff/build/groff-1.23.0.3392-22d65/_build/sub'
make[2]: *** [Makefile:11725: install-recursive] Error 1
make[2]: Leaving directory '/home/branden/src/GIT/groff/build/groff-1.23.0.3392-22d65/_build/sub'
make[1]: *** [Makefile:13950: install] Error 2
make[1]: Leaving directory '/home/branden/src/GIT/groff/build/groff-1.23.0.3392-22d65/_build/sub'
make: *** [Makefile:13859: distcheck] Error 1


I'll keep whacking on this.

Regards,
Branden

G. Branden Robinson <gbranden>
Group administrator
Tue 10 Jun 2025 12:17:41 PM UTC, comment #11: 

Hi Branden,

No the source for the .pfb file is actually the URW font for Symbol.pfb. I explained how I generated it: https://lists.gnu.org/archive/html/groff/2023-06/msg00114.html. It also explains some of the problem. It seems that, although the devps/generate/Makefile has a rule for generating freeeuro from source, it only gets run in "maintainer mode". The usual build of freeeuro.pfa is to run psstrip on the freeeuro.ps in font/devps to move it from src to dest.

Also pertinent is comment #31 in bug #63018 particularly wrt the grops SS font. The problem is that each entry in a font has a cell size and a glyph shape, the transformation to reduce and slant the glyphs is done, it does not apply to the cell size, just the glyph shape, so when you ask fontforge to write out the afm file the original cell sizes are used for the glyphs width and height, rather than them being reduced 89%! There may be a fontforge command to transform the cell size on its own, hence my message to the list asking for help and why this bug has stalled.

Almost all the groff "static font files" (i.e. files which go straight from source directory to install directory) are not touched during a make, couldn't SS and StandardSymSL.pfb be treated in a similar manner? Alternatively, do what we do with grops symbolsl.ps which uses psstrip to essentially move a file from src to dest, cat may be useful. :-)

Cheers

Deri


Deri James <deri>
Group Member
Tue 10 Jun 2025 10:32:15 AM UTC, comment #10: 

On second thought I think I'll break the stuff from comment #9 into a new ticket.  What it discusses is essentially a long-latent bug affecting gropdf only when it runs from a build tree that is not the same as the source tree, which is a headache only for developers, not for end users.

G. Branden Robinson <gbranden>
Group administrator
Mon 09 Jun 2025 09:16:08 PM UTC, comment #9: 

Hi Deri,

Do you have some kind of source form for the file "font/devpdf/StandardSymSL.pfb"?

I can open it with FontForge, so the answer might be "no".

But it would be convenient for our build process if you did, because then I could (maybe) treat it the way we treat "freeeuro.pfa", namely by generating it.

Also, if you could regenerate the "SS" file using a contemporary afmtodit that records more information, that would be helpful.  Do you have an "afm" file for "StandardSymSL.pfb"?

I ask for all this stuff because it's hard to get gropdf to find "StandardSymSL.pfb" to embed it when running it from a build tree that is not also the source tree.  That is a supported build scenario (and my usual one).  The "download" file doesn't have any concept of source tree and build tree; to it, everything is an installation.

G. Branden Robinson <gbranden>
Group administrator
Mon 09 Jun 2025 07:28:11 PM UTC, comment #8: 

I'm having problems with this in terms out outcomes after application, but it will probably be easier for others to help if I got ahead and push.

One reason this got held up for so long was that a lot of changes to "devpdf.am" were necessary.

Here's a preview.


commit 5e739c45a4e0bae26af2410e9e231f9dff72a580
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Sun Jun 8 12:42:57 2025 -0500

    font/devpdf/devpdf.am: Refactor.

    This change also ships font description file names for the "pdf" output
    device corresponding to the 8 new font description files for CJK script
    support recently added for the "{x,}html", "ps", and "utf8" devices.

    These are intended as abstractions of faces to permit consistent naming
    while permitting customization, just as with the 12 text typefaces
    supported across output devices for Latin scripts in groff (three
    families of four styles each).  These CJK font descriptions are not
    organized into groff font families, but are similar.  They are not
    mounted by default.

            CSH: Simplified Chinese, Hei style
            CSS: Simplified Chinese, Song style
            CTH: Traditional Chinese, Hei style
            CTS: Traditional Chinese, Song style
            JPG: Japanese, Gothic style
            JPM: Japanese, Mincho style
            KOG: Korean, Gothic style
            KOM: Korean, Mincho style

    * font/devpdf/devpdf.am: Make this Automake script more
      Automake-idiomatic (I think) and more closely resemble other groff
      Automake scripts.

      (devpdf_builddir): Define macro.

      (GROFF_FONT_FILES, ENC_FILES, MAP_FILES): Drop macros populated by
      shell command substitution in favor of static file lists...

      (DEVPDFFONTFILES_FROM_DEVPS): ...like this...

      (DEVPDFFONTFILES_FOR_URW) [HAVE_URW_FONTS]: ...and this.

      (DEVPDFFONTFILES): New macro contains only
      `DEVPDFFONTFILES_FROM_DEVPS` plus the "download" and "DESC" files.

      (devpdffontdata, devpdffontencdata): Rationalize contents, aligning
      files and macro contents with installation requirements so Automake
      takes care of installing and uninstalling them.

      (MOSTLYCLEANFILES): Add `devpdffontdata`, `devpdffontencdir`,
      `devpdffontmapdir`, so that Automake takes care of cleaning them.

      ($(DEVPDFFONTFILES_FROM_DEVPS)): New target copies "ps" device's font
      descriptions to build's "pdf" device data directory.

      ($(devpdffontencdata)): Now that the "text.enc" encoding file name is
      stored in a macro, use it and compute its basename instead of using
      literals.

      ($(DEVPDFFONTFILES_FOR_URW)): Make the "pdf" device's "download" file
      depend on this macro's contents, which may be empty if
      `HAVE_URW_FONTS` is not defined by the "configure" script.

      (font/devpdf/stamp): Respell dependencies using above macros.

      (mostlyclean-local, mostlyclean_devpdf_extra) (install-data-local,
      install_devpdf) (uninstall_groffdirs, uninstall_devpdf): Drop targets
      made redundant by better population of `devpdf*data` macros above.

commit 267783cbf72d5dd9db9945726bf2cfe0fa0552b8
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Mon Jun 9 13:18:47 2025 -0500

    font/devutf8/devutf8.am: Tweak generated "DESC".

    * font/devutf8/devutf8.am (DEVUTF8FONTS): Tweak ordering of mounted CJK
      faces in "DESC" file generated for "utf8" output device.  Consistently
      arrange the Hei (~serif) faces before the Song (~sans-serif) ones.

commit 2468cfbca307ba643b52531f3adb22adff6893cd
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Mon Jun 9 13:51:29 2025 -0500

    font/devpdf/devpdf.am: Fix up "download" file gen.

    * font/devpdf/devpdf.am (font/devpdf/download): Explicitly remove the
      target before (re)constructing it because if we don't, BuildFoundries
      will opportunistically open it and modify it in place, leading to the
      banner created with `echo` below being uselessly repeated.
      (Potentially, it could retain stale data in other respects.)

commit f44e96fc4d537b1e849d6818721ba36a9aa1e0e8
Author: Deri James <deri@chuzzlewit.myzen.co.uk>
Date:   Mon Jul 3 15:44:29 2023 +0100

    [gropdf]: Add `SS` font support.

    Replace pseudo-slanted characters with a real font, improving typography
    of, e.g., slanted lowercase Greek letters as used in eqn(1).

    * font/devpdf/StandardSymSL.pfb:
    * font/devpdf/SS: Add new files.

    * font/devpdf/DESC.in: Mount `SS` font at position 6.
    * tmac/pdf.tmac: Drop `pdf:SS` macro defining fallback character with a
      slant of 16 degrees for the argument, and 28 calls of it for 24
      lowercase Greek letters and 4 variant forms.

    Fixes <https://savannah.gnu.org/bugs/?65098>.


G. Branden Robinson <gbranden>
Group administrator
Sun 18 Aug 2024 12:16:19 PM UTC, comment #7: 

Retitling to reflect smaller remaining scope.  Deri mentioned somewhere that all of his new features have been merged except slanted symbol font, which looks like it requires some afmtodit work.

There are several items to be written about gropdf for the "NEWS" file as well.

G. Branden Robinson <gbranden>
Group administrator
Mon 08 Jan 2024 02:30:49 AM UTC, comment #6: 

Deri posted a helpful dependency graph of the new gropdf features.

One update is required: the changes to "pdf.tmac" that expose the new "pdfpagenumbering" convenience macro are merged, but other changes to that file are not (yet).

G. Branden Robinson <gbranden>
Group administrator
Wed 03 Jan 2024 12:11:03 PM UTC, comment #5: 

Made some headway here.


8d320bd7b gropdf(1): Recast `pagenumbering` description.
8dc1df406 [gropdf]: Add `pdfpagenumbering` macro.
7256dfb9f gropdf(1): Update.
fbde1f13b [build]: Increment Perl dependency to 5.8.
77fb2e809 [gropdf]: Add font subsetting and Type 1 parser.


G. Branden Robinson <gbranden>
Group administrator
Wed 03 Jan 2024 12:30:33 AM UTC, comment #4: 

Red Tree
========
I assume you have built my branch at some point, any Titian hues?

Special Pleading (MR)
=====================
You were correct I was bending a general case to try to fit a special case.

For Iterator
============
I can see many uses for this mechanism. One of my design goals for the new gropdf was to allow non-latin languages to use groff to use all the pdf features available to latin languages, particular using the currently available fonts which cover a wide range of languages. The size of these fonts are huge so the current practice of embedding the entire font is probably a non-starter, hence the need for subsetting and being able to use more than 256 glyphs from the font.

Part of this requires unicode to be passed to gropdf, to cater for code such as:-

.pdfbookmark 1 "Chinese text"

Preconv will have converted the chinese text to a group of \[uXXXX] which in turn is converted by troff to nodes, so the for loop will set N for each chinese character and I end up with an empty string. The same problem occurs if chinese is used to set a named destination within the pdf, but it is worse because the destination name is also used in the pdf:look array and if each call results in the empty string, it will not work.

So, I have a few doubts it will completely remove the need for stringhex, but you may find a way.

Cheers

Deri

Deri James <deri>
Group Member
Tue 02 Jan 2024 10:39:19 PM UTC, comment #3: 

comment #2:

> Dealing with gropdf.pl separately, I have cobbled together a document
> which may help you in the task. It is a list of all the diffs with a
> following comment which describes what the changes accomplish. One way
> of handling this is to introduce each file as a separate commit and
> include a description of what the changes in each file achieve (from
> the embedded comments). Note that I have removed from the diff changes
> to master since deri-gropdf-ng was branched.


Yes!  That sounds much more tractable.  Thank you--I'll have a look.

> Gropdf.pl is a slightly different kettle of fish, it has grown by over
> 25% (over 1000 lines), and the number of new lines of code is more
> than that because there has been significant code deletion as well.


Yes.

> You may remember there was a code freeze for over 6 months before
> 1.23.0 and after 3 months I got an "itch" and wrote the new version,
> you then suggested I start a new branch, so I slammed the new version
> into that. I have already written about the two main drivers for the
> change: making gropdf subset fonts in the pdf, and switching from a
> word based input model to an input stream of glyph names (you said
> that my description  was helpful).


Indeed.

> So just as adding a new program to a project does not lead to a raft
> of commits detailing every new function in the code, but rather the
> commit would describe what new features the new program adds to the
> project, it would probably be best to treat the new gropdf in a
> similar way - describing what has been added to groff's capabilities.


True, but gropdf _is_ an existing program, so for maintainability I
think that ideally, we'd handle it the same way as the changes described
in the first paragraph above.  This would also be consistent with other
major changes to groff features we see in the commit and changelog
histories, particularly in the Werner Lemberg era of maintenance.

That said, I don't want to gate the merge of your changes on such a
documentary record.  Perfect being the enemy of the good and all that.

> I'm afraid I did not get your red tree reference, my only experience
> with red/black trees is in "binary chop" and there is a self balancing
> algorithm for that.


Right, sorry about that.  I refer to a convention in continuous
integration (and some other development) systems such that builds are
automated after every commit, and if a build fails on any of the N
supported configurations, the "tree (of source code) goes red", that is,
becomes unacceptable for deployment to production.  Normally, the tree
is "green", and ready to ship any time a manager/release engineer/"Agile
scrum master" elects to do so.

> Maintainability is more concerned with understanding the code as it
> is, the git log may help you understand how it got there but
> understanding what the code actually achieves can only be understood
> by reading the code. For example if I want to know what
> ps_output::put_string does then git log tells me that isascii got
> changed to is_ascii in 1994, but it tells me nothing about what the
> routine does. Maintainability of code is far more about the quality of
> code and the knowledge and experience of the person looking at the
> code.


I think I got lost here with respect to which of these distinct aspects
is more important to maintainability, but I agree that they're both
virtues.

> I've had a rethink about an.tmac and stripped out all the stuff added
> to MR, since it was only there to support internal links to other
> pages within a man page book (such as groff_man_pages.pdf), and I have
> found an alternative way of achieving the same thing without touching
> an.tmac. All that is left is stuff to make it work with the new
> gropdf, don't use \E* do use \\*, and add support for UR/UE and MT/ME.


Oh, that's interesting.  The "special pleading" for `MR` was one of the
things that felt not-quite-baked to me.

> I know you are working on/planning your for iterator, but please don't
> hold up merging my branch to wait for it, since in its current state
> it all works without it.


Agreed.  It is hard for me to predict when any particular thunderbolt
will appear in my bucket ready for hurling.  I thought resolution of bug
#62471 was months in the future for a long time (a year or more?), and
then all of a sudden the fog lifted and, prompted by
a discussion with
Colin Watson and наб in a man-db merge request, I was able to land a fix
with little effort by attacking the problem from a different angle.

> When your code is complete we can revisit which parts are helpful for
> gropdf.


Agreed, and this can likely serve as a form of regression test to boot.

> Just out of interest: what does ch contain if N is set (i.e. it is a
> node).


Stage 1: I was thinking it would return nothing, an empty string.  You'd
just pump the iterator again to get the next thing.

But that's pretty weak sauce because we need a way to signal that
iteration has stopped.  Python raises a StopIteration exception, for
example.  But the *roff language has neither exceptions or even return
values, strictly considered.

So, initially, your iterator "character" would contain nothing if you
had hit a node or the end of the iterand.

That will not actually be unworkable because:

1.  If you use the `for` or `rfor` requests, they will only exit
    (barring a `break`) once iteration has stopped.

2.  I don't at this point imagine a more primitive means of driving an
    iterator, but if that should happen, one can always use the
    `length` request beforehand to measure the iterand, and make sure
    not to pump the iterator more than $length times.

But that seems to me only a little less fiddly than the existing things
we have to do when iterating strings.  So...

Stage 2: Add a new conditional operator, "N".


.ie N ch .tm it's a node
.el      .tm it's not a node


That seems like it should be easy/simple to do.  So if `ch` interpolates
nothing and is not a node, iteration has stopped.

Stage 3: Add a new `pnode` request to dump information about a node to
the standard error output.  Not useful for *roff programming (that is,
it's not really "in the language" per se), but potentially very valuable
for *roff development (including applications).

My instincts tell me I'd want all 3 of these together, so these stages
would not necessarily be distantly separated.  If they prove to be easy,
they might be a sequence of adjacent commits in a single push.

Feedback very much desired.

Regards,
Branden

G. Branden Robinson <gbranden>
Group administrator
Tue 02 Jan 2024 09:06:45 PM UTC, comment #2: 

Dealing with gropdf.pl separately, I have cobbled together a document which may help you in the task. It is a list of all the diffs with a following comment which describes what the changes accomplish. One way of handling this is to introduce each file as a separate commit and include a description of what the changes in each file achieve (from the embedded comments). Note that I have removed from the diff changes to master since deri-gropdf-ng was branched.

Gropdf.pl is a slightly different kettle of fish, it has grown by over 25% (over 1000 lines), and the number of new lines of code is more than that because there has been significant code deletion as well. You may remember there was a code freeze for over 6 months before 1.23.0 and after 3 months I got an "itch" and wrote the new version, you then suggested I start a new branch, so I slammed the new version into that. I have already written about the two main drivers for the change: making gropdf subset fonts in the pdf, and switching from a word based input model to an input stream of glyph names (you said that my description  was helpful). So just as adding a new program to a project does not lead to a raft of commits detailing every new function in the code, but rather the commit would describe what new features the new program adds to the project, it would probably be best to treat the new gropdf in a similar way - describing what has been added to groff's capabilities.

I'm afraid I did not get your red tree reference, my only experience with red/black trees is in "binary chop" and there is a self balancing algorithm for that.

Maintainability is more concerned with understanding the code as it is, the git log may help you understand how it got there but understanding what the code actually achieves can only be understood by reading the code. For example if I want to know what ps_output::put_string does then git log tells me that isascii got changed to is_ascii in 1994, but it tells me nothing about what the routine does. Maintainability of code is far more about the quality of code and the knowledge and experience of the person looking at the code.

I've had a rethink about an.tmac and stripped out all the stuff added to MR, since it was only there to support internal links to other pages within a man page book (such as groff_man_pages.pdf), and I have found an alternative way of achieving the same thing without touching an.tmac. All that is left is stuff to make it work with the new gropdf, don't use \E* do use \\*, and add support for UR/UE and MT/ME.

I know you are working on/planning your for iterator, but please don't hold up merging my branch to wait for it, since in its current state it all works without it. When your code is complete we can revisit which parts are helpful for gropdf. Just out of interest: what does ch contain if N is set (i.e. it is a node).



(file #55511)

Deri James <deri>
Group Member
Sat 30 Dec 2023 11:24:59 PM UTC, comment #1: 

original submission:

> I thought it might be helpful to have a place where we can see
> progress on this.


I agree.  This is difficult because the main blocker I'm experiencing is
finding enough spoons to properly changelog the giant change to
gropdf.pl.  This could also involve dividing it into discrete change
sets (commits), but that seems even more daunting (under the "don't make
the tree go red" principle) and this merge has been held up for a while.

> I have noticed some cherry picking from the branch happening so I'm
> hopeful there will be movement on the rest.


Yes.  I was very happy to see that these bug fixes were independent of
the "next generation" code changes.  :)

> If you are too snowed under at the moment just assign it back to me
> and I can do the merge of the rest.


It's not the merging per se that is the hard part; it is bundling the
merge with enough developer-facing information that we don't degrade the
maintainability of the system.

I guess I could mention that some of the changes on the branch that
aren't to gropdf.pl, like an.tmac-related stuff, is not in the "final
form" I envision it taking.  I'd like to clean up the design (and
implement missing formatter or macro package features where
appropriate).  But as a proof of concept it's fine and I'm glad it's
getting good exercise in the Linux man-pages, with Alejandro's
enthusiastic adoption.  That gives me a good baseline from which I can
measure (and hopefully avoid) regressions.

Now that we have a dependency graph, I think I'd be a good idea if I
created a "1.24 release goals" ticket, and made it depend on this one.

Thoughts?

Regards,
Branden

G. Branden Robinson <gbranden>
Group administrator
Sat 30 Dec 2023 11:01:14 PM UTC, original submission:  

I thought it might be helpful to have a place where we can see progress on this.

I have noticed some cherry picking from the branch happening so I'm hopeful there will be movement on the rest. If you are too snowed under at the moment just assign it back to me and I can do the merge of the rest.

Deri James <deri>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #57284:  S.pdf added by deri (47KiB - application/pdf)
file #55511:  diff.html added by deri (60KiB - text/html)

 

Depends on the following items: None found

Items that depend on this one

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by deri (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 18 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-06-20 gbranden StatusIn Progress Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.24.0
        Summary[PATCH] [gropdf] support `SS` font [PATCH] [devpdf,gropdf] support `SS` font
    2025-06-20 gbranden DependenciesRemoved dependency to bugs #67207 -
    2025-06-14 gbranden Dependencies- Depends on bugs #67207
    2025-06-10 deri Attached File- Added S.pdf, #57284
    2025-06-10 gbranden StatusNeed Info In Progress
        Assigned toderi gbranden
    2025-06-09 gbranden StatusIn Progress Need Info
        Assigned togbranden deri
    2024-08-18 gbranden Summarymerge branch deri-gropdf-ng to master [PATCH] [gropdf] support `SS` font
    2024-01-03 gbranden StatusNone In Progress
    2024-01-02 deri Attached File- Added diff.html, #55511
    2024-01-01 gbranden CategoryCore General
        Item GroupBuild/Installation Feature change
    2023-12-31 gbranden Dependencies- bugs #65099 is dependent
    2023-12-31 gbranden SummaryMerging branch deri-gropdf-ng with master merge branch deri-gropdf-ng to master

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code