Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: Marc Simpson <marc@0branch.com>
Newsgroups: gnu.groff.bug
Subject: Re: FAMILY-dependent apostrophe behaviour with -mom
Date: Mon, 2 Dec 2019 22:13:52 -0800
Lines: 76
Approved: bug-groff@gnu.org
Message-ID: <mailman.184.1575353654.1979.bug-groff@gnu.org>
References: <CAMbwm8_6uVsLCqCSFM232TmTNCnDtvXnrDb+cyvtqMC_wq2uuA@mail.gmail.com> <2403810.z0MjTcnAeh@pip> <CAMbwm88tHJJFkTiWArtpXVqDVZ1EMMxZud3YpDasScQzyqVBPQ@mail.gmail.com> <4248113.Arxy1sOjue@pip> <CAMbwm8_WMZmV0r6ZiZOFHTFXZefjk15HAV=zM9OHUf4eBwu=Yw@mail.gmail.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Cc: bug-groff@gnu.org, Dale Snell <dalesnell54@gmail.com>
To: Deri <deri@chuzzlewit.myzen.co.uk>
Envelope-to: bug-groff@gnu.org
In-Reply-To: <4248113.Arxy1sOjue@pip>
Precedence: list
Xref: csiph.com gnu.groff.bug:1573

Hi Deri,

[Accidentally sent this off-list earlier; resending.]

On Mon, Dec 2, 2019 at 4:06 PM Deri <deri@chuzzlewit.myzen.co.uk> wrote:
> On Monday, 2 December 2019 19:26:02 GMT Marc Simpson wrote:
>
> Hmmph!  This is a bug in gropdf, it came to my notice recently, when
> dealing with a huge chinese font (>12000 glyphs), that my original
> design decision for gropdf to access the font using the ascii
> character number was a mistake, although it works fine with all the
> standard fonts.  [...]

Thanks for your investigation.

> I was misled by assuming that the "t" command documented in
> groff_out was always an ascii string, and the "c" command was used
> to access the named glyphs in the font.  However, the individual
> characters in the "t" string should be treated as individual glyph
> names, which is what grops does correctly.

Interesting.

> I am intending to fix this in gropdf at some point.

Great to hear.

> There is a workaround which should work for pdfmom which seems to
> work with CODE as well.  I changed the following lines in the
> GeorgiaR font file in devpdf.  The change is the number in the
> fourth column.
> [...]
> What this does is move the "quoteright" glyph to the 39th position
> in the font, which is the position it occupies in the standard
> fonts.

Thanks for your suggestion.  Looking at two of the fonts that I've
converted on this machine, Garamond Premier Pro ('Garamond', below)
and Georgia, I see the following entries for `quote(single|right)' in
the devpdf font files:

  $ awk '/quote(single|right)$/ {
      print FILENAME ":\t" $1 "\t" $4 "\t" $5 }' Garamond* Georgia*
  GaramondB:      aq      39      quotesingle
  GaramondB:      '       270     quoteright
  GaramondBI:     aq      39      quotesingle
  GaramondBI:     '       2974    quoteright
  GaramondI:      aq      39      quotesingle
  GaramondI:      '       2130    quoteright
  GaramondR:      aq      39      quotesingle
  GaramondR:      '       1090    quoteright
  GeorgiaB:       aq      39      quotesingle
  GeorgiaB:       '       715     quoteright
  GeorgiaBI:      aq      39      quotesingle
  GeorgiaBI:      '       545     quoteright
  GeorgiaI:       aq      39      quotesingle
  GeorgiaI:       '       444     quoteright
  GeorgiaR:       aq      39      quotesingle
  GeorgiaR:       '       363     quoteright

Are you suggesting that `quoteright' ought to be 39 in each instance
by swapping values with the font's `quotesingle' value (exchanging 39
and 270 for GaramondB, 39 and 2974 for GaramondBI etc)?  If so,

- Would this have any negative impact on rendering `quotesingle'?
- Since these fonts are actually symlinks to devps, should the edits
  be made solely to the devpdf copies?
- Does this problem apply to other characters?
- Are there benefits to making font edits over just defining ' as
  \[cq] with .char?
  - I've already defined a macro that wraps mom's FAMILY to do just
    this, which seems to be a simpler workaround.

Thanks,
Marc