Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.groff.bug > #1573 > unrolled thread

Re: FAMILY-dependent apostrophe behaviour with -mom

Back to article view | Back to gnu.groff.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: FAMILY-dependent apostrophe behaviour with -mom Marc Simpson <marc@0branch.com> - 2019-12-02 22:13 -0800

#1573 — Re: FAMILY-dependent apostrophe behaviour with -mom

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

[toc] | [standalone]

Back to top | Article view | gnu.groff.bug

csiph-web