[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Greek letters not slanted in -Tps eqn output

From: joerg van den hoff
Subject: Re: Greek letters not slanted in -Tps eqn output
Date: Wed, 10 Aug 2022 13:24:04 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

On 09.08.22 21:38, G. Branden Robinson wrote:
[looping in groff@ again due to a shift in discussion focus to

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,

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


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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]