[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #62923] [gropdf] glyph aliases in font description files not parsed
From: |
G. Branden Robinson |
Subject: |
[bug #62923] [gropdf] glyph aliases in font description files not parsed correctly |
Date: |
Fri, 7 Oct 2022 07:41:58 -0400 (EDT) |
Follow-up Comment #18, bug #62923 (project groff):
[comment #17 comment #17:]
> Whilst you are correct the original submission matched the title, this was
fixed in comment #1. All further comments then onwards are an entirely
different issue which affects grops as well as gropdf. It seems odd to have an
open ticket asigned to gropdf for a problem which has been fixed.
I agree. Where we seem to have a difference of opinion is regarding whether
this ticket is currently open or closed. :)
Savannah is showing me that it is closed, and the history says that it was
closed (by me) on 24 August, and never reopened by anyone.
> The outstanding issue in the following comments concerns whether radicalex
is a non-spacing character in the special font or not, in S it is, in XITSMR
it is not (or vice-a-versa, I can't remember).
As I understand it, there's not really any such thing as spacing vs.
non-spacing glyphs in *roff. All glyphs have a width, but whether the drawing
position is changed after writing them depends on the "grout" command that was
used to do so. (In AT&T device-independent troff, motion was _never_ implied
by writing a glyph. _All_ motions were explicit. So in that sense, all
glyphs were non-spacing.)
If there is some distinction between S and XITSMR in this regard, I'm curious
to see how that difference is expressed in the font description files.
> The point is that eqn (or the definition in ps.tmac) only caters for the one
case.
I'm not convinced that that's the problem here.
> Since this ticket was originally closed when the problem to which the title
refers was fixed, but you subsequently reopened when a different issue was
reported in comment #2 I am unsure what to do.
Oh, I see part of the problem now. You set the Status to "Fixed" around the
time of comment #1, _but didn't close the ticket_. These are separate bits in
Savannah. No, I'm not sure that's a good design. A ticket can be open and
fixed, open and "won't fix", closed and "in progress"...it's a free-for-all!
I did indeed switch the status to "in progress" on the 20th, but by the 23rd I
had been convinced by the discussion that you had identified and fixed a
gropdf problem, so I set the status _back_ to "Fixed", but also assigned
responsibility to you, marked the "Planned Release" as "1.23.0", and _closed_
the ticket for the first time.
> The original issue was definitely a gropdf problem since it was not seen if
using grops, the second issue affected both grops and gropdf equally so is
indicative that the problem is not with gropdf.
>
> What is your advice Branden?
I think we agree on the disposition of the gropdf issue; I think there is a
distinct issue that demands further research, which should probably be
conducted in a new ticket.
What do you think?
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?62923>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/