Follow-up Comment #12, bug #65098 (group groff):

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 <[email protected]>
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



    _______________________________________________________

Reply to this item at:

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

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

Attachment: signature.asc
Description: PGP signature

Reply via email to