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


Groups > gnu.groff.bug > #1573

Re: FAMILY-dependent apostrophe behaviour with -mom

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> (permalink)
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"
X-Trace usenet.stanford.edu 1575353654 8392 209.51.188.17 (3 Dec 2019 06:14:14 GMT)
X-Complaints-To action@cs.stanford.edu
Cc bug-groff@gnu.org, Dale Snell <dalesnell54@gmail.com>
To Deri <deri@chuzzlewit.myzen.co.uk>
Envelope-to bug-groff@gnu.org
DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=0branch-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9/Fenujj8Hwr1a4g0BHRREJ/jip75Gmg45ZpXeW6bjI=; b=j9tkqI0RZbU83B0h+h6a8Xvh08FDmneiKAGAXv5MLYE/6X5DjJDVxHbgMZVOu/l0Jh nBC3XZFkwJBVzMEbR48ys0k2qq25rTMK8wBb0l/TMk+WFHFUAUEgAZ8mTV/sUsH13WyC 51/BTRNtjcX2+5VsPG4a2l+ervUyh5n+sZLOBJtJOWLNDztFozWs1z3dyC5afvKyn/47 /6zOBjmXNq9/5kD3riOUKmP+YpyHW1ahw0S/Pi6Bq5+o4YfGZk4Iz2W+KHcX/cFhJpRD f4bvQtpsyE87enQTVFnH5IiDGD/DNT3Fi06fHLNh9sBJ3KVOs+Jkz6HPJ6gJ/dh3XHmR 5nsg==
X-Google-DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9/Fenujj8Hwr1a4g0BHRREJ/jip75Gmg45ZpXeW6bjI=; b=nlgGtopvp//+GtglpoLq15kV8wLwsPhQphX+svfX7eTOCt2ADeONbw2u1C6VdKd7E4 rLWYv6pA0hiU1U8KKnwvxZsmEB2hifRO8ndEdX8WMrz7QgTkjh6qYrD7MWyOaDiu5dzb QTZkSZke+hiQ3d8IsjDIJmRFZYh0Vc1U+2QVqb7STIw8AJGQ+r7STAv4SztpSWzHsutR c9D4h3avZoZYCm9FKcBIOVMSDhI164m2BnVx0UWXKAbRsgfvgQD0EJmX+QPxBNNIZZKj PFfjp0qbO6bfi7XGYGpVpPVxWm1FkhOLg8Mj58V5BxB3E6kPOvHXaK1Z+aZk+XQds0rN p5Jg==
X-Gm-Message-State APjAAAWlT9ssGWHR+c8ZAlINWyIuZ9AEUt+vjJnsQEynR65ufKOwBzNm RDuqmtt6iKVRXGbEvn9prt8pEzbO3XE048+8Lr0q2g==
X-Google-Smtp-Source APXvYqy93m4aQGAAqo6+AOJpr9A7AE34pippMcc1mjmejFLcgYQuxzdaR+iy8ZkLn5Nj1JU9IoJFS3b48xrniU8HUAk=
X-Received by 2002:a19:c3ca:: with SMTP id t193mr1655690lff.40.1575353644050; Mon, 02 Dec 2019 22:14:04 -0800 (PST)
In-Reply-To <4248113.Arxy1sOjue@pip>
X-detected-operating-system by eggs.gnu.org: Genre and OS details not recognized.
X-Received-From 2a00:1450:4864:20::141
X-BeenThere bug-groff@gnu.org
X-Mailman-Version 2.1.23
Precedence list
List-Id "Bug reports for the GNU version of nroff, troff et al" <bug-groff.gnu.org>
List-Unsubscribe <https://lists.gnu.org/mailman/options/bug-groff>, <mailto:bug-groff-request@gnu.org?subject=unsubscribe>
List-Archive <https://lists.gnu.org/archive/html/bug-groff>
List-Post <mailto:bug-groff@gnu.org>
List-Help <mailto:bug-groff-request@gnu.org?subject=help>
List-Subscribe <https://lists.gnu.org/mailman/listinfo/bug-groff>, <mailto:bug-groff-request@gnu.org?subject=subscribe>
X-Mailman-Original-Message-ID <CAMbwm8_WMZmV0r6ZiZOFHTFXZefjk15HAV=zM9OHUf4eBwu=Yw@mail.gmail.com>
X-Mailman-Original-References <CAMbwm8_6uVsLCqCSFM232TmTNCnDtvXnrDb+cyvtqMC_wq2uuA@mail.gmail.com> <2403810.z0MjTcnAeh@pip> <CAMbwm88tHJJFkTiWArtpXVqDVZ1EMMxZud3YpDasScQzyqVBPQ@mail.gmail.com> <4248113.Arxy1sOjue@pip>
Xref csiph.com gnu.groff.bug:1573

Show key headers only | View raw


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

Back to gnu.groff.bug | Previous | Next | Find similar | Unroll thread


Thread

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

csiph-web