bug-groff
[Top][All Lists]
Advanced

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




reply via email to

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