Re: UTF-8 in grout and a performance regression (was: synchronous and asynchronous grout)

[onf]

Hi Branden,

On Fri Dec 20, 2024 at 7:45 PM CET, G. Branden Robinson wrote:
> At 2024-12-20T14:15:43+0100, onf wrote:
> > On Fri Dec 20, 2024 at 3:45 AM CET, G. Branden Robinson wrote:
> > > Yes.  I think we could do more to encourage people to understand the
> > > availability of the grout format as a resource on more occasions, in
> > > a similar way that Dave Kemper finally got the value of "groff -a"
> > > output through my thick skull.
> > 
> > Does it have any other use nowadays besides regression testing?
>
> Which--grout, or "groff -a"?

Oops, sorry for such ambiguity. I meant groff -a.

> [...]
> > > I agree.  For situations like that, UTF-8-empowered grout would be
> > > an advantage.
> [...]
> > The reason I would like to see it is not necessarily to aid in
> > troubleshooting glyph selection, but in navigating the output.
> > When I have several pages of text and there's a problem near one
> > of the words, being able to find that word easily would be handy.
> > In fact I took the example above from just such a document and
> > locating the word I saw in PDF output in grout took me way much
> > longer than it should have.
>
> That's a fair point.  It's probably much harder than it needs to be to
> orient oneself in the grout stream if the document is in any language
> but English.  The utility of the 't' and 'u' commands attenuates for all
> others.

Yeah. The impression I have from all this is that this would be great:
  ttéměř
  wh3117
  ttři

and this would be workable:
  Ct
  h5444
  Cé
  h5444
  Cm
  h5444
  Cě
  h5444
  Cř
  wh7649
  Ct
  h4532
  Cř
  h4532
  Ci
  h3117

('w' being on its own line would help a lot here)
but this is terrible:
  tt
  C'e
  h5444
  tm
  Cu0065_030C
  h5444
  Cu0072_030C
  wh7649
  tt
  Cu0072_030C
  h4532
  ti

> > I've been using afmtodit to install fonts; it seemed to work better
> > than install-font.sh the last time I tried.
>
> install-font.sh runs afmtodit as part of its operation.

I am aware of that, but when I tried it, it seemed to work worse than
just running afmtodit directly.

> > (By the way, can anyone explain to me the rationale behind giving
> > scripts filetype suffixes? I thought the standard way is to give them
> > a shebang and make them executable...)
>
> [...]
> My own practice is to use an extension when I want to (1) not have a
> shebang line, (2) keep the executable bit off, and (3) keep the tool
> outside of the $PATH.  Typically this is because it is not a fully
> fledged program that has rigorous argument and input validation, a usage
> message, a man page, and so forth.

I see. I tend to simply make it a runnable script outside $PATH in such
cases.

> > I thought the reason for not having good Unicode coverage was simply
> > that either the font never had it in the first place, or PostScript
> > fonts did not support it well enough.
>
> I think age explains the advertised coverage of the PostScript fonts
> supported by stock groff.  As I recall, Deri has pointed out many times
> that the URW foundry fonts have _much_ improved coverage relative to the
> traditional ones in the (now withdrawn) PostScript specification.

I thought the U-* fonts come from URW, but I haven't noticed any
significant improvement in Unicode support compared to their
non-prefixed counterparts.

~ onf