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?

Reassigning back to category gropdf, per comment #9.

There may indeed be at least two other bugs we can spawn from this one.

1. Should eqn ever emit \[sr] or \[radicalex] special characters itself?  Per my analysis in comment #12, it doesn't.  But I can't think of a reason for it to.  If the glyphs aren't available in the full panoply of styles you'll get them from an unstyled font regardless, and if you want to format them in a non-mathematical context, don't use eqn, right?

2. As Deri points out in comment #13, the ps.tmac has a pretty wacky redefinition of \[radicalex].  While it doesn't seem to break anything, is it doing anything useful with the extra motions?  Can we simplify it, or remove it, without losing anything?  (We'd still want to leave the fallback definition of \[sqrtex], I think.)

I confess I haven't attempted to reproduce anything with the XITMSR font yet.

If anyone wants to follow up on either of the above points, please consider filing a new ticket.

I also found this on wikipedia https://en.wikipedia.org/wiki/Symbol_(typeface)

The character at 0x60 does not appear in Unicode. It is described in the Adobe map as "RADICAL EXTENDER", with the Adobe glyph name "radicalex", and is mapped to the PUA code point U+F8E5. It is an over-bar for extending the radical sign over the operands of the radical operator. Some versions of the font implement this as a non-spacing character so that it can be combined (like non-spacing diacritical marks) with the operands it covers. The Unicode overbar character is shown here.

comment #10:

> eqn has a hardcoded name for the bar glyph of radicalex.

This turns out not to be true.  GNU eqn always puts out the special characters \[sqrt] and \[sqrtex] (which are "special" even among special characters, i.e., they are intended for non-text fonts), and has no provision for writing out the text glyphs \[sr] and \[radicalex].

https://git.savannah.gnu.org/cgit/groff.git/tree/src/preproc/eqn/sqrt.cpp#n42

So where in blazes do those "Cradicalex" commands come from in the "grout" output, then?

ps.tmac has done us a...favor.
 

.char \[radicalex] \h'-\w'\[sr]'u'\[radicalex]\h'\w'\[sr]'u'
.fchar \[sqrtex] \[radicalex]

https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/ps.tmac#n34

On the ps device, \[radicalex] is unconditionally rewritten at formatting time to move left by the width of the text glyph \[sr], written, and then move right by the same amount.  (Because "radicalex" is a special character, it is always written out using the 'C' output command, which does not imply motion by the width of the written glyph.  That is, an uninterrupted series of C commands will overstrike at the same position.)

(You will also observe that the re-definition appears to be circular.  The groff Texinfo manual documents a "special anti-recursion feature" of the `char` family of requests that prevents this.)

Since this redefinition of \[radicalex] seems to work all right, I have no complaint about it per se.  I do wonder if it shouldn't be eqn's job to do this, though...

But the PostScript font descriptions we supply with groff don't actually define any glyphs for "sqrtex".  They aren't even aliased to "radicalex" in the font description files.

That means that as far as the formatter is concerned, when these fonts are mounted (and only these, not any third-party fonts installed by the user), the "sqrtex" special character never exists in any font; '.if c \[sqrtex]' would always fail.  So the `fchar` line we see above, defining a "fallback" character, is always interpreted.

That, I believe, is why the "C radicalex" command stubbornly appears in GNU troff output.

I haven't installed XITS Math myself yet, but I'll work on that.  In the meantime I tried the following patch.

diff --git a/font/devps/S b/font/devps/S
index ae8b3a902..ed2cf3a8c 100644
--- a/font/devps/S
+++ b/font/devps/S
@@ -90,6 +90,7 @@ rB    "
 pp     658,674 3       94      perpendicular
 _      500,0,125,2,2   3       95      underscore
 radicalex      500,917,0,590   3       96      radicalex
+sqrtex "
 *a     631,500,18      3       97      alpha
 *b     549,741,223     3       98      beta
 *x     549,499,231     3       99      chi
diff --git a/tmac/ps.tmac b/tmac/ps.tmac
index 8b796e376..dbb251683 100644
--- a/tmac/ps.tmac
+++ b/tmac/ps.tmac
@@ -32,7 +32,7 @@
 .fchar \[u2011] -
 .
 .char \[radicalex] \h'-\w'\[sr]'u'\[radicalex]\h'\w'\[sr]'u'
-.fchar \[sqrtex] \[radicalex]
+.char \[sqrtex] \h'-\w'\[sqrt]'u'\[sqrtex]\h'\w'\[sqrt]'u'
 .char \[mo] \h'.08m'\[mo]\h'-.08m'
 .char \[nm] \h'.08m'\[nm]\h'-.08m'
 .char \[parenlefttp] \[parenlefttp]\h'.016m'

You can see there is a potentially important distinction here, not between "radicalex" and "sqrtex", but in the horizontal motions that bracket them.  "sr" is a "text" special character, meaning it's normally drawn from a text font.[1]  "sqrt" is a "special" special character, meaning that it is drawn from a font that is expected to lack text glyphs (i.e., to lack glyphs that vary in the four traditional styles of roman, italic, bold, and bold-italic).  So we can imagine that glyph registration might be off if the XITS Math font's "sqrtex" is used with the groff PostScript Symbol font's "sqrt".

The foregoing changes made the (GNU troff) output less surprising, without PostScript output looking worse.  Here is my test file.

$ cat EXPERIMENTS/sqrtex.roff
.sp
.EQ
sqrt x
.EN
.sp 4v
.EQ
gsize 48
sqrt x
.EN
.sp
.EQ
gsize 8
sqrt x
.EN

> the XITSMR font has a glyph sqrtex

My hypothesis is therefore as above: glyph registration is incorrect because "sqrtex" is being used with the spacing of groff PostScript Symbol font's "sr" instead of the XITS Math font's "sqrt".

At this point I think what I need to do is look more closely at the particulars of XITS Math.

> I have done my analysis of the problem and confirmed that it affects grops as well as gropdf with identical (wrong) output. Since this has nothing to do with a bug in gropdf, I have removed myself from the assignation.
>
> Hopefully you can check the analysis I have already done and do your own analysis.

Okay.  The product of that analysis so far is given above.

[1] Nevertheless, in groff's PostScript font descriptions, "sqrt" appears only in the "special font", "S" (with "sr" aliased to it).  I believe it is Werner Lemberg who created the distinction between "text" radicals and extensions (\[sr], \[radicalex]) and "math" radicals and extensions (\[sqrt], \[sqrtex]), about 20 years ago.  The reasons are not entirely clear to me, though if somebody is making fonts with bold, italic, and bold-italic radical signs grouped with their basic Latin alphabetical neighbors, their proper semantics in groff are indeed "text".

I'm not sure what extra information you require, I fixed and closed the original bug, confirmed by the submitter.

Then a second bug was raised about the misalignment of the square root extension bar. It has a tenuous link to aliased glyphs because the XITSMR font has a glyph sqrtex but eqn has a hardcoded name for the bar glyph of radicalex. I have done my analysis of the problem and confirmed that it affects grops as well as gropdf with identical (wrong) output. Since this has nothing to do with a bug in gropdf, I have removed myself from the assignation.

Hopefully you can check the analysis I have already done and do your own analysis.

Putting on my bug tracker administriviator's hat...

comment #7:

> This probably deserves its own bug number, since the original problem is now fixed.

Did this turn out to be the same issue as bug #62934?

> This second reported issue is not specific to PDF output, the same problem exists with postscript, which is indicative the issue is other than the output driver, or something which is common to both, such as the pfa font file.

...this seems to suggest it's not, since that was gropdf-specific.

I'll leave this open until that question is resolved, but once we have a separate bug number for the issue mentioned above, it should be -> Closed, -> 1.23.0, and -> Fixed.

Setting to "Need Info" in the meantime.

comment #5:

> I've just created an account. The output is really easy to understand (thanks to groff_out(5))!

Hello and welcome!  I'm glad to hear that about groff_out(5); that is a man page that I have not rewritten yet, though I have plans to.

I will try not to make it worse!

Would the submitter care to identify themselves?  I like to credit helpful reporters in the ChangeLog, and it's not every day we get a ticket submitter who understands the troff output format.

Thank you for fixing it! I applied the fix you provided and it works but I noticed that one thing is still broken: if you add an alias with name radicalex to sqrtex in XITSMR, the radicalex is rendered on the same position as sqrt (in groff_out there's no h command after Csqrt):

.special XITSMR
.EQ
sqrt x
.EN

It somehow gets fixed if I add this line at the top:

.char \[radicalex] \[sqrtex]

comment #1:

> Thanks for this report. I have duplicated the issue and now have a fix which I will be committing soon.
>
> It is a one line change to the gropdf program which is a perl script probably in /usr/bin or /usr/local/bin.
>

> Around line 2414 change:-
>
>
>             if ($r[1] eq '"')
>             {
>                 $fnt{NAM}->{$r[0]}=$fnt{NAM}->{$lastnm};
>                 next;
>             }
>
> To this:-
>
>             if ($r[1] eq '"')
>             {
>                 $fnt{NAM}->{$r[0]}=[@{$fnt{NAM}->{$lastnm}}];
>                 next;
>             }

GROFF VERSION:
1.23.0.rc1.2845-342a1-dirty

OS:
GNU/Linux

COMPILER:
clang

COMMAND LINE:
groff -e file.troff -Tpdf > file.pdf

DESCRIPTION OF INCORRECT BEHAVIOUR:
On line 4427 of XITSMR (font description file) I defined an alias with name bracerightex for braceleftex but the PDF output looks very broken (file.pdf). PS output is rendered just fine to some reason. Interestinly, if I copy braceleftex char info and replace the name with bracerightex (effectively making the alias), the output is rendered as expected.