bugGNU roff - Bugs: bug #62923, [gropdf] glyph aliases in font...

 
 

bug #62923: [gropdf] glyph aliases in font description files not parsed correctly

Submitter:  None
Submitted:  Fri 19 Aug 2022 10:15:22 PM UTC
   
 
Category:  Driver gropdf Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  Fixed
Privacy:  Public Assigned to:  deri
Open/Closed:  Closed Planned Release:  1.23.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 07 Oct 2022 12:23:47 PM UTC, comment #19: 

Hi Deri,

I opened bug #63179 and got a big surprise...

G. Branden Robinson <gbranden>
Group administrator
Fri 07 Oct 2022 11:41:57 AM UTC, comment #18: 

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?

G. Branden Robinson <gbranden>
Group administrator
Fri 07 Oct 2022 10:54:39 AM UTC, 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. 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). The point is that eqn (or the definition in ps.tmac) only caters for the one case.

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

Deri James <deri>
Group Member
Fri 07 Oct 2022 12:43:14 AM UTC, comment #16: 

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.

G. Branden Robinson <gbranden>
Group administrator
Fri 02 Sep 2022 11:52:09 AM UTC, comment #15: 

comment #12:

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


Bug #62973 now seeks to clarify this terminology.

Dave <barx>
Group Member
Thu 25 Aug 2022 11:20:55 AM UTC, comment #14: 

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.


Deri James <deri>
Group Member
Wed 24 Aug 2022 08:30:31 PM UTC, comment #13: 

Yes, that's what I meant, \[sqrtex] is hard coded. :-)

When you install XITSMR repeat your test with .special XITSMR, then you can see the problem. With .special S everything looks normal.

In XITSMR sr is an alias for sqrt and radicalex is an alias for sqrtex (this one was added manually by Nikita, not by afmtodit). Without it groff complains about missing glyph radicalex. One unusual aspect of the font is that it was processed with text.enc and marked as "special" so it inherits a lot of kernpairs which sort of makes sense because it contains general text glyphs as well as maths symbols.


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


Good catch, you are Gunga Dinn! But this is crazy, my reading of this is it assumes an radicalex follows an sr step back the width of the sr stroke the radicalex and then step forward the width of the sr! I don't understand why it steps back the width of sr before stroking the glyph.

If you .rchar the char radicalex so you are using the naked glyph you get some interesting results which lead to an inescapeable, and surprising, conclusion!

Run the attached s.trf (no need for eqn) to be totally surprised. (If the excitement is too much, just look at s.pdf).

I'm not sure what the long term fix will be, for now Nikita can .rchar \[radicalex]. The proper fix may be in eqn to adjust depending on the italic correction of the sqrtex glyph to detect if it is an overscore following character or overscore itself type.

As further confirmation I checked the S font in fontforge and the radicalex glyph is shown with a red question mark and if you go into a screen called Math Kerning you can see a filled box (the line outside the bounding box.



(file #53603, file #53604)

Deri James <deri>
Group Member
Wed 24 Aug 2022 11:41:32 AM UTC, comment #12: 

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

G. Branden Robinson <gbranden>
Group administrator
Tue 23 Aug 2022 06:28:06 PM UTC, comment #11: 

Hi Deri,

comment #10:

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


Thanks, this largely clears things up for me.  Sounds like it might be a bug in eqn, then.

Per groff_char(7) from Git HEAD:


       In AT&T troff, \(rn (“root en extender”) served as the horizontal
       extension of the radical (square root) sign, \(sr, and was drawn
       at the maximum height of the typeface’s bounding box; this
       enabled the special character to double as an overline (see
       subsection “Rules and lines” above).  A contemporary font’s
       radical sign might not ascend to such an extreme.  In groff, you
       can instead use \[radicalex] to continue the radical sign \[sr];
       these special characters are intended for use with text fonts.
       \[sqrt] and \[sqrtex] are their counterparts with mathematical
       spacing.


It seems like eqn should always be using \[sqrtex] to extend radical signs.

...but it's a separate issue, and I (or someone else) can file it.  For this ticket, I think you should keep the credit for the swift fix.  :)

G. Branden Robinson <gbranden>
Group administrator
Tue 23 Aug 2022 06:19:22 PM UTC, comment #10: 

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.

Deri James <deri>
Group Member
Tue 23 Aug 2022 03:38:09 PM UTC, comment #9: 


commit 26523d0bb2d2c0cca6b3b0759888069d6846fb1f
Author: Deri James <deri@chuzzlewit.myzen.co.uk>
Date:   Sat Aug 20 01:29:12 2022 +0100

    Bug #62923 - problem using aliased glyphs

    With a large font if 2 characters above the 255 code
    point limit are aliased, the aliased glyph has incorrect meta
    data.

    * src/devices/gropdf/gropdf.pl: Instead of duplicating a pointer
    to the font metadata, duplicate the data itself. Then, if the
    glyph is remapped to a code point under 256, the metadata is
    preserved.

    Fixes <https://savannah.gnu.org/bugs/?62923>.


G. Branden Robinson <gbranden>
Group administrator
Tue 23 Aug 2022 03:37:50 PM UTC, comment #8: 

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.

G. Branden Robinson <gbranden>
Group administrator
Sat 20 Aug 2022 10:54:21 PM UTC, comment #7: 

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

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.

I'm afraid I have not been able to pin down exactly what is happening, but I will document what I have discovered so far. First I extended the example to include the same equation but using the standard symbol font. This produces this groff_out:-


x T pdf
x res 72000 1 1
x init
x F /usr/share/groff/1.22.4/tmac/eqnrc
x F t.trf
p1
V85173
H72000
DFd
x font 39 XITSMR
f39
s10000
v457
md
Csqrt
Cradicalex
h1660
Cradicalex
x font 38 TI
f38
h8390
V85173
tx
h530
n13173 0
x font 11 S
f11
V110455
H72000
Csqrt
Cradicalex
h740
Cradicalex
f38
h5520
V109173
tx
h530
n12000 0
x trailer
V792000
x stop


You can see that in both cases the sqrt is immediately followed by the radicalex without an intervening "h" command. So although this looks suspicious, on its own it can't be the underlying issue.

So, if you look at what eqn actually eventually outputs for both equations:-


XITSMR=\&\E*[0sfont]\f[I]\s'\En[0ssize]u'\Z\(EQ\s[10000u]\v'--457u'\[sqrt]\l'5740u\&\[sqrtex]'\s[10000u]\(EQ\Z\(EQ\h'15020u-5740u+9280u/2u'\,x\/\(EQ\h'15020u'\E*[0rfont]\x'-(9673u-85M)'

S     =\&\E*[0sfont]\f[I]\s'\En[0ssize]u'\Z\(EQ\s[10000u]\v'--1282u'\[sqrt]\l'5740u\&\[sqrtex]'\s[10000u]\(EQ\Z\(EQ\h'11230u-5740u+5490u/2u'\,x\/\(EQ\h'11230u'\E*[0rfont]


(Captured as a .tm of the value of \*(10 which eqn builds).

In both cases the sqrt, within a \Z, is immediately followed by a line created by repeated sqrtex characters, with some overlapping to create a line of the desired length, to fit over the "x". I am  not sure there is a significant difference between the two, differences in numbers can mostly be traced back to the meta-data in the respective font files.

Here's the postscript which is produced:-


/F0 10/XITSMath-Regular@@0 SF -9.28(\(,)72 85.63 S(,)6.86 E/F1 10
/Times-Italic@0 SF(x)4.31 -.457 M/F2 10/Symbol SF 4.22 -5.49(\326` `)72
110.455 T F1(x)6.01 -1.282 M 0 Cg EP


The only interesting thing here is the Symbol version is output with the T operator while the XITSMath version uses the S operator. Probably a complete red herring, but unfortunately I've reached the boundary of my current knowledge! I place all the information here hopeful it will be seen by a "Gunga Din".

It is possible that the reason the .char fixes it for the XITSMR font (but messes it up for the S font) is because the 2nd parameter is treated as a string and dealt with in its own environment, which forces the previous glyph to be treated "normally", i.e. a "c" followed by its width in an "h" command. Incidentally, the "fix" still works if you do .char \[radicalex] \[radicalex] instead, so it does not look like its to do with glyph aliases in the XITSMR file.


Deri James <deri>
Group Member
Sat 20 Aug 2022 07:10:10 PM UTC, comment #6: 


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!

G. Branden Robinson <gbranden>
Group administrator
Sat 20 Aug 2022 06:54:45 PM UTC, comment #5: 

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

comment #4:

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

Nikita Ivanov <nikitaivanov>
Sat 20 Aug 2022 01:06:06 PM UTC, comment #4: 

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.

G. Branden Robinson <gbranden>
Group administrator
Sat 20 Aug 2022 01:04:14 PM UTC, comment #3: 

Re-opening due to comment #2.

G. Branden Robinson <gbranden>
Group administrator
Sat 20 Aug 2022 07:03:17 AM UTC, comment #2: 

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


Anonymous
Sat 20 Aug 2022 12:04:14 AM UTC, 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;
            }


Deri James <deri>
Group Member
Fri 19 Aug 2022 10:15:22 PM UTC, original submission:  

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.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #53603:  s.trf added by deri (1KiB - application/octet-stream)
file #53604:  s.pdf added by deri (13KiB - application/pdf)
file #53586:  file.troff added by None (115B - application/octet-stream)
file #53587:  XITSMath-Regular.pfa added by None (1MiB - application/x-font-type1)
file #53588:  file.pdf added by None (689KiB - application/pdf)
file #53589:  XITSMR added by None (155KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by barx (Posted a comment)
  • -email is unavailable- added by nikitaivanov (Posted a comment)
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by deri (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 21 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-10-07 gbranden CategoryPreprocessor eqn Driver gropdf
    2022-10-06 deri CategoryDriver gropdf Preprocessor eqn
    2022-10-06 gbranden Summary[gropdf] glyph aliases in in font description files not parsed correctly [gropdf] glyph aliases in font description files not parsed correctly
    2022-08-24 deri Attached File- Added s.trf, #53603
        Attached File- Added s.pdf, #53604
    2022-08-23 gbranden StatusNeed Info Fixed
        Assigned toNone deri
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.23.0
    2022-08-23 deri Assigned toderi None
    2022-08-23 gbranden StatusIn Progress Need Info
    2022-08-20 gbranden CategoryGeneral Driver gropdf
        Item GroupNone Incorrect behaviour
        StatusFixed In Progress
        SummaryBroken aliases in PDF font description file [gropdf] glyph aliases in in font description files not parsed correctly
    2022-08-20 deri StatusNone Fixed
        Assigned toNone deri
    2022-08-19 None Attached File- Added file.troff, #53586
        Attached File- Added XITSMath-Regular.pfa, #53587
        Attached File- Added file.pdf, #53588
        Attached File- Added XITSMR, #53589

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code