Re: Merging the new gropdf

[G. Branden Robinson]

Hi Deri,

At 2023-11-04T13:21:21+0000, Deri wrote:
> I was wondering how the merging of the new gropdf branch was going (I
> think you very kindly offered to help merging with master). Recently
> you have written on the list:-

Slowly.  I landed two small changes this weekend, but they're not things
most folks are looking for.

> "Also, when Deri James's gropdf improvements are merged for groff
> 1.24, the file size of groff-man-pages.pdf should come _way_ down.".
> 
> If you can't help me, I am quite happy to "give it a go", but I
> probably won't do it as well! Since I announced the new gropdf I have
> had one bug report (which is fixed), so it would be helpful to get
> further testing from users who are using master.

I agree.  I've been trying to separate the changes into functional
units, albeit not diced as finely as would for changesets of my own.

I've been facing a few challenges:

* The sheer magnitude of changes to gropdf.pl itself, and my own
  ignorance of details of PDF that the new functionality is
  implementing.

* An uneasiness I feel about some of the solutions you adopted insofar
  as they have effect outside of gropdf.pl itself.  For instance:

  1.  Changing the format of font description files to add yet another
      field, mapping character names to Unicode code points.  In the
      rest of groff, this is not necessary because we have glyphuni.cpp.

      
https://git.savannah.gnu.org/cgit/groff.git/tree/src/libs/libgroff/glyphuni.cpp

      I'd like to honor the DRY principle here.  What's a good way to
      achieve that?

  2.  I don't know the provenance of a new font you have proposed for
      shipping with groff, StandardSymSL.pfb.  We need to make sure it
      is freely licensed.  If it is mechanically generated from a
      PostScript Type 1 font that we can expect to find on the system,
      maybe we should perform that procedure during the build.  (On the
      other hand, I'm not sure I love the idea of adding a
      build-dependency on fontforge or similar.)

  3.  The new `stringhex` request you've proposed for troff.  As noted
      elsewhere, I'd prefer to solve this a different way.

      https://savannah.gnu.org/bugs/index.php?63074

      ...but I haven't implemented my idea yet, so I don't object to
      `stringhex` as a temporary measure.

* There were _tons_ of seemingly unrelated whitespace changes to
  gropdf.pl, which frustrates code review.  (This has happened before; I
  don't remember when, but Dave might.)  I went through the file and
  attempted to impose a consistent style on it, but I'm not sure how
  you'll feel about it.  More importantly, it would be helpful to get
  your text editor to do better here.

Also your most recent commit to your branch says that it's starting work
on a new thing.  Should I omit that from my merge?

https://git.savannah.gnu.org/cgit/groff.git/commit/?h=deri-gropdf-ng&id=a2b5541142a1571e9f9f5a8321c1e21c721469aa

I'm attaching a "git log -p --format=fuller" of my staging branch so you
can see where I am.

I look forward to hearing your thoughts on next steps.

Regards,
Branden

mail.diff
Description: Text Data

signature.asc
Description: PGP signature