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

[G. Branden Robinson]

Hi onf,

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"?

grout is essential to groff's architecture.  "groff -a" might in fact be
useful for verifying that you're getting the character entities you
desire.  It'd probably be more useful for that if we had some knobs
to, in that mode, (1) in fact enable UTF-8 output and (2) resolve
character definitions to their constituent components.

https://savannah.gnu.org/bugs/?55799
https://savannah.gnu.org/bugs/?66242

> > 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.

> 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.

> (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...)

I'm not sure of the historical reasons.  They may have to do with
shebang line support not being implemented or reliable in some places
but that's just a guess.

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 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.

Regards,
Branden

signature.asc
Description: PGP signature