Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.groff.bug > #1573
| From | Marc Simpson <marc@0branch.com> |
|---|---|
| Newsgroups | gnu.groff.bug |
| Subject | Re: FAMILY-dependent apostrophe behaviour with -mom |
| Date | 2019-12-02 22:13 -0800 |
| 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> |
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
Re: FAMILY-dependent apostrophe behaviour with -mom Marc Simpson <marc@0branch.com> - 2019-12-02 22:13 -0800
csiph-web