Re: Greek letters not slanted in -Tps eqn output

[G. Branden Robinson]

[looping in groff@ again due to a shift in discussion focus to
development]

At 2022-08-09T19:14:25+0200, joerg van den hoff wrote:
> On 09.08.22 17:05, Deri wrote:
> > groff and grops can find the SS file, which gives the widths of the
> > SS glyphs, but grops cannot find the Symbolsl.pfa file because it is
> > not listed in the download file it finds.
> 
> question: is there a deeper reason, why grops does not traverse all
> known font locations/dirs and scan all found `download' files until,
> hopefully, a hit is found? I mean except "someone would need to
> volunteer to implement it" :).

That is sadly pretty much it.  The output drivers rely on functions
implemented in libgroff to open files with cognizance of the font search
path.  These functions were written in the expectation that when
searching for one of these files, it would contain all the information
you needed to satisfy the demand.  This works great for "DESC" and files
like "TR".  You either find one that will tell you everything you need
to know, or you won't.

"download" is different.  It's not insane to keep traversing the font
search path even after finding one, because having done so is not a
guarantee that the file will have what you need.

It is possible for device or font description files to be incomplete; if
they are missing essential information, they will fail validation and
the output driver will issue diagnostics.  groff Git is much more
fastidious about such validation than 1.22.4 was.

Are you not getting a diagnostic message from grops(1) when it can't
find "Symbolsl.pfa"?  Are you running groff 1.22.4 or Git?  If the
latter then this is something I want to fix.  Even if I or someone else
implements further searching, we'll need that diagnostic for when all
download files are exhausted without a match.

> I have now read groff_font, which I think is quite clear and finally
> found the statement regarding "first file found is used". so it *is*
> spelled out but it still is easily overlooked (as I am proof of...).

A failure to emit a diagnostic message when a required resource is
unavailable also doesn't help people to understand the situation.  :(

> I also would find it more "natural" if grops/gropdf where doing that.

I agree, and the same thing occurred to me when reviewing the code.

> > Contrary to what it says in the gropdf man page (which I cobbled
> > from the grops man page), gropdf does do what you expect. It builds
> > a map from all download files found. I, too, was not aware that
> > grops didn't.
> 
> oh, is that true!? then I can revert the "merge" of my private
> `download' with the default one for gropdf :). and the manpage might
> be adjusted to explicitly emphasize that gropdf behaves that way,
> possibly?

Please do test that, Joerg!  :D

Yes, updating the gropdf man page sounds appropriate.  Deri, would
prefer to handle this or would you like me to?

> well, if the (newer) gropdf does that, maybe it should be "backported"
> to grops :).

A simple matter of rewriting Perl code in C++.  ;-)

> > > if yes, I can understand that after the `alpha beta gamma... `
> > > sequence groff/eqn presume a different position of last greek
> > > letter than actually is going to be true downstream when the ps
> > > oder pdf is generated. and so groff/eqn would position whatever
> > > comes next on a wrong horizontal position relative to the greek
> > > letters.
> > 
> > After the greek characters comes the horizontal line between 1/2. If
> > the move to the start of the line before drawing is a relative
> > movement from the end of greek characters then it will be in the
> > wrong position.
> 
> ok, in this case, yes. I would have expected the relative movement
> being relative to the fraction bar itself, but that's obviously not
> what eqn does.

This part I cannot speak to, as I have only barely begun coping with GNU
eqn's source code.  If someone else knows, I hope they will clarify.

Regards,
Branden

signature.asc
Description: PGP signature