Re: Greek letters not slanted in -Tps eqn output

[joerg van den hoff]

On 09.08.22 21:38, G. Branden Robinson wrote:
> [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.

running 1.22.4. no warnings from grops whatsoever :(.

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

I trust deri :). but of course I will revert the gropdf `download' and
report if any problems occur in the future.

> 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++.  ;-)

see? I have never looked at the sources. I did not know that gropdf is Perl.
then it would be obviously more work...

best,
joerg

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