[bug #63354] Refine fallbacks.tmac

[G. Branden Robinson]

Update of bug #63354 (project groff):

                  Status:                    None => Need Info              

    _______________________________________________________

Follow-up Comment #27:

Hi Dave,

[comment #24 comment #24:]
> > And if you're right for troff devices that Symbol is _always_ there
> > and it _always_ defines this glyph, it _can't_ degrade typography.
> 
> This forgets the lesson I had to learn the hard way (see comment #3) that
.fchar definitions take precedence over special fonts.

Ah, yes.  I seem to keep forgetting that, too.  I have visions of a `pchar`
request that takes a character as an argument and makes the formatter report
how it resolves the damn thing.  Making people read through the eight-step
procedure documented in section 5.19.4 of our Texinfo manual--which I haven't
reviewed for correctness, incidentally--is simply sadistic.

Nevertheless `fchar` seems to be the right request, rather than `schar`,
because a _hyphen_ will nearly(?) always be something that is rendered
adjacent to glyphs from a _text_ (potentially styled) font.

>  So as things stand, the definition in fallbacks.tmac will always hide the
Symbol font's u2026, degrading typography when using fonts that lack their own
u2026.

(U+2026 is the ellipsis.)

But does that happen?  Do people ship text fonts that lack ellipses?

The PostScript Language Reference manual, 3e, suggests that text fonts are
reliable in providing ellipses.  The Symbol font seems to have one too (pp.
775-778).

>  And this hiding seems to happen even with the lowest-precedence member of
the .*char family, .schar: given the following input, groff uses the "schar"
definition rather than falling back to the u2026 in Symbol:
> 
> .schar \[u2026] FOO
> .ft ZD
> \[u2026]

Agreed.  That much at least is consistent with §5.19.4.  If I add a `special`
request, troff locates "S"'s ellipsis again.


$ cat EXPERIMENTS/zapf-hyphen.groff
.\" troff -R
.special S SS ZD
.schar \[u2026] FOO
A long time ago in a galaxy far, far away\[u2026]
$ troff -R EXPERIMENTS/zapf-hyphen.groff | grep -C3 u2026
tw
H226060
tay
Cu2026
h10000
n12000 0
x trailer

 
> > You might however be forgetting grodvi and grolbp, which don't
> > offer the PS Symbol font.
> 
> Indeed I was.  And offhand I'm not sure how to accommodate those without
also degrading PostScript.

Possibly the device tmac files should be making `special` requests, though I'm
a little leery of this since it may be contrary to the request's initial
purpose.  There is already a CSTR #54 procedure for searching special fonts.

This is not a question I feel can be resolved for groff 1.23.0.
 
> > On nroff devices, users of "ascii" and "latin1" devices
> > actually come out ahead of "utf8" users.
> 
> Luckily, we can easily test for terminal devices and give them different
fallbacks.

I'm not inclined to change things further in this respect at present; I may
think a half-width character cell ellipsis is ugly as hell, but I'm uneasy
with going out of my way to "protect" the user from it.
 
> For grodvi and grolbp, all I can do is observe that (a) terminal, PostScript
and PDF are likely more important output formats for a vast majority of users,
and (b) grodvi and grolbp had no u2026 fallback in prior releases, so lacking
one in 1.23 isn't a regression.

I have no real argument with this, I am simply trying to think in 
maintainerly, comprehensive way to serve all of groff's users, even those that
use exotic output devices.

> Thus I'm starting to think the best solution is to make the u2026 fallback
terminal-only for 1.23.  But if there's a way to keep the PostScript/PDF
behavior as it was in 1.22.4 but also improve other non-terminal output, I'm
open to that.

[comment #25 comment #25:]
> If fallbacks.tmac gets tweaked before 1.23 (or perhaps even before rc2), one
more trivial change I'd recommend.  Two lines in the file currently read:
> 
> .\" \[u2010] is always defined thanks to uniglyph.cpp.
> .\"fchar \[u2010] -\:\" hyphen
> 
> The first of these lines is worthwhile, in case someone comes along later
and is tempted to add a \[u2010] definition.  But the second seems misleading:
point (b) of comment #8 illustrates that even were the uniglyph.cpp definition
removed or circumvented, the fchar here wouldn't do what was intended.  So
it's a little dubious to put it in a shipped .tmac file, even in commented
form, as it implies to anyone reading the code that the construction _could_
work.
> 
> So my preference would be to see the second line removed entirely.  But this
is certainly not a blocker, since it's inactive code.

There are so many loose threads tugged on by this baby step toward Unicode
support, as if a toddler's leg is wrapped with several strands of dental
floss, each connected distally to a different precariously balanced piece of
fine china that I feel I must simply solicit a patch from you at this point.

I haven't lost my spirit to fight with these issues in general, but I feel
extremely constrained from whacking at them within the parameters I've imposed
on myself for getting to a 1.23.0 release.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63354>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/