bugGNU roff - Bugs: bug #63018, [PATCH] make glyphs in ZD font...

 
 

bug #63018: [PATCH] make glyphs in ZD font accessible via their Unicode spellings

Submitter:  Dave <barx>
Submitted:  Mon 05 Sep 2022 10:17:12 AM UTC
   
 
Category:  Font devps Severity:  1 - Wish
Item Group:  Feature change Status:  None
Privacy:  Public Assigned to:  deri
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 14 May 2024 10:47:47 PM UTC, comment #31: 

I have been investigating the AFMs Branden found with a view to using them as a way to recreate the grops fonts, particularly in situations where there have been changes to the maps, encoding files and afmtodit itself. Since the last release afmtodit, and dingbats map have been altered, and the grops fonts have been hand edited by me to add the UTF-16 code as a comment. Afmtodit is to be changed soon to add the new spacewidth algorithm and improvements to the font comments.

For all these reasons it would be convenient to have an automated procedure which generates the grops fonts. The attached grops-fonts-AFMs.tar.gz has everything required to do this. It contains the afms from the Adobe-Core35_AFMs-229.tar.gz from CTAN, with one change, the Symbol.afm has been replaced with symbol.afm from the git grops directory, since I suspect this has been edited to work best with eqn. Investigation showed that the original Symbol.afm from the 229 tar.gz produced different italic corrections, whereas the copy from the grops directory produces identical results.

All the AFMs have had the ellipsis kerning lines added, (see script EllipsisFix.sh - a blatant rip off from Daves code in bug #58897 - except it now operates on the KPX lines in the AFM files, so no need to run it again, but left in place to show what was done).

The script BuildPSfonts.pl runs afmtodit with the correct parameters. It takes 4 parameters:-

BuildPSfonts.pl [-F font-directory] [-map directory-with-map-files] [-enc directory-with-enc-files] [-afm directory-with-afm-files]

From the build directory I ran it with this parameter:-

./BuildPSfonts.pl -F ./devps -enc ../font/devps -map ../font/devps/generate -afm grops-fonts-AFMs

Note I used a separate directory for the new fonts so I could then compare them with the current files for checking.

When you check the results you will notice a few differences:-

The final glyph in each file has a different UTF-16 comment, the new versions are correct, mistake in my hand editing when I committed them, the new generated files are correct.

In some fonts there is one case where the position of the ellipsis and period kern lines are swapped, this has no effect, it happens when afmtodit is processing a glyph alias (i.e. when two groff names refer to the same glyph, contains just a name and a " in the font entry. In this case generates two kern entries and sorts them alphabetically. Dave's sed script which added an epsilon kern after each '.' kern, so the order would be like this:-

. rq -70
u2026 rq -70
. ' -70
u2026 ' -70

Whereas afmtodit sorts the kern list alphabetically so it becomes:-

. rq -70
. ' -70
u2026 rq -70
u2026 ' -70

This has no effect.

The S font has the most changes. There is a new glyph Upsilon which is not in the current font, and it is given the groff name "u03A5" rather than *U,which is assigned to 03D2 "GREEK UPSILON WITH HOOK SYMBOL", so I don't think this will cause an issue. The rest of the difference are all to do with the comment field and have no effect.

The SS font is a problem. There is a file called symbolsl.afm in the devps directory which one could reasonably assume was used to produce the SS file via afmtodit. However, if you look at the file you will see it has problems:-

C 33 ; WX 333 ; N exclam ; B 128 -13 240 686 ;

The width is shown as 333, but this produces:-

---     296,598,15,137,-73,99   3       33      exclam

Where the width is now 296 (=333*.89) and the height goes from 673 (686-13) to 598 (=673*.89). The .89 factor is from the transformation applied to the normal symbol file in the file symbolsl.ps:-

%%IncludeResource: font Symbol

/Symbol-Slanted
[.89 0.0 15.5 dup sin exch cos div .89 0.0 0.0]
/Symbol
MakeTransformedFont

Which seems to be a zoom factor plus either a rotate or shear transformation (my maths is not up to it). I was 17 before I had my first proper maths lesson, the benefits of going to a school where you are not expected to be academic. :-)

So I don't think we can faithfully reproduce the SS font from source files, unless someone is mathematical enough to apply a transformation to the llx, lly, urx, ury (which defines a rectangle) so if someone can convert the postscript transformation to a formula which converts the rectangle, we could add it as an option to afmtodit

Another issue which applies to SS, is that because it is defined in DESC fonts before the S font and will be searched first, it is important that only the symbol glyphs we want to become slanted (i.e. lowercase greek for equations) are named, the rest need to be unnamed (---) so groff will look for them in the normal symbol font instead. This script does that as well.

I have done a fair bit of work on this, because I think it is important we have the ability to recreate the grops fonts, but I am now stuck: need help with the maths outlined above and also guidance on implementing this as a make target.

(file #56053)

Deri James <deri>
Group Member
Mon 13 May 2024 03:37:22 AM UTC, comment #30: 

comment #29:

> When it is a separate make target (bug #65698), if we wish to
> retain the epsilon kerns the make target must either re-apply
> the shell script after the font generation, or these "gold" AFMs
> should have the extra kerns added once before we pour aspic on them.


[s/epsilon/ellipsis]

Ah, I see.  In theory I can't see a reason it would matter which way it's done (though my font knowledge is far smaller than yours).  In practice, the script for fixing up the kernpairs section post-afmtodit already exists and has been tested (bug #58897).

> As far as I can tell the "slant" parameter does nothing for
> composite (e.g. a glyph plus an accent glyph on top of each
> other) placement.


As far as I can tell, too, but the sentence in afmtodit(1) says otherwise.  Perhaps it's erroneous.

> What it does do is affect both italic
> correction factors and the subscript correction,


That makes more sense to me.  But it still doesn't explain why, as you observed in comment #26, TI should have such a significant adjustment to the slant value (more than halving the original) but TBI have none.  The metrics between the two shouldn't be that different.

Dave <barx>
Group Member
Sun 12 May 2024 10:11:10 PM UTC, comment #29: 

Dave.

I think the implied question is: When it is a separate make target (bug #65698), if we wish to retain the epsilon kerns the make target must either re-apply the shell script after the font generation, or these "gold" AFMs should have the extra kerns added once before we pour aspic on them. The make targe then gets run whenever afmtodit, the maps, or the encoding files, are altered.

As far as I can tell the "slant" parameter does nothing for composite (e.g. a glyph plus an accent glyph on top of each other) placement. What it does do is affect both italic correction factors and the subscript correction, i.e. when a font switches from roman to italic for example.

Branden.

You piqued my curiosity about Hungarian umlauts, so I took a peak at the list archives. :-)

There are two issues with Gergő's predicament. His package was built with no URW fonts whatsoever, even though the required fonts are sitting in /usr/share/fonts/Type1/ as can be seen in the list of files supplied to Alex. I know this because the pdf he supplied had absolutely no embedded fonts in it, so if you cast your mind back to the games played with the URW font detection during configure, he has the setup where only the base 14 pdf fonts would be available (without warnings about missing fonts). The placement of the umlauts is because the standard fonts lack the four individual glyphs, so groff sends a composite:-

wx font 5 TR
f5
h13750
Ca"
to
wh13750
Ca"
tO
wh13750
Ca"
tu
wh13750
Ca"
tU

Where the U- foundry fonts have separate glyphs:-

wx font 42 U-TR
f42
h13750
Cu006F_030B
wh41250
Cu004F_030B
wh53460
Cu0075_030B
wh41250
Cu0055_030B

In the attached pdf you can see that in the U- fonts the height of the umlaut is fitted to the height of the letter, since the glyph is custom designed. It is always better to use a single glyph rather than composing a compose. I did send him some information how to access those URW fonts by just replacing the TR, TI... With 4 custom versions, but it was just an email, since I am no longer on the list, so it may get filed as "junk".

Also, because of the big pointsize, it is easier to see what is happening. In TI and TBI you can see the umlaut is slightly shifted to the right, this has nothing to do with "slant" it is just an artifact of the probable transformation applied to TR to arrive at TI when the font was designed.

(file #56036)

Deri James <deri>
Group Member
Sun 12 May 2024 04:35:07 PM UTC, comment #28: 

comment #27:

> And Dave just happens to be right here, ready for the spotlight. ;-)


Oh, heavens no, I still need at least 15 more minutes in makeup.  Have the emcee stall!

[If there's a question for me here, I'm not sure what it is.]

> > Maybe some people on the list may know.
>
> I'm afraid I don't have any insight into that decision.


Everything I know about it is in bug #57506.  It would help if afmtodit(1)'s claim "the slant ("angle") parameter in the font description file...is used by groff in the positioning of accents" were more forthcoming on just how groff uses this value so.

Dave <barx>
Group Member
Sun 12 May 2024 02:36:06 PM UTC, comment #27: 

comment #26:

> I have been investigating the AFMs contained in the tar files Branden referenced in comment #15.


Oh, cool, you tracked 'em down.  I couldn't remember if I had renamed them for my own benefit or if I found them on the Web with those names.

> Using the 229 versions it is possible to generate the 35 fonts for grops. The only difference is that our fonts include kerning data for the ellipsis font which is not included in the AFMs, because commit 81b4ffadc1ced modified the files via a shell script to duplicate the full stop kerning information to ellipsis.


And Dave just happens to be right here, ready for the spotlight. ;-)
 

> I have only tested the TR and TI fonts and I used the following afmtodit commands:-
>
> ./afmtodit -c -i0 -m -e ../font/devps/text.enc Adobe-Core35_AFMs-229/Times-Roman.afm font/devpdf/map/text.map DJTR
>
> ./afmtodit -c -i50 -a7 -e ../font/devps/text.enc Adobe-Core35_AFMs-229/Times-Italic.afm font/devpdf/map/text.map DJTI
>
> For italic fonts you need to ensure that the "slant" value (-a) matches the value used previously, (in case of Times-Italic the AFM has an Italic Angle of 15.5, but the groff font was clearly produced with a slant of 7, i.e. it was overridden with the -a flag). I don't know why this was done, it is the only one with such an override:-


[snip]

> Maybe some people on the list may know.


I'm afraid I don't have any insight into that decision.

More broadly, I wonder if this slant value selection is related to the gripe this month on the development list about Hungarian umlauts.

> It is a good thing Branden found the AFMs since the conversion from afm to a groff font is not completely reversible.


Maybe it is time we extended afmtodit with whatever features we need to make possible a fully automatic transformation from the Adobe AFMs, which are certainly fully fossilized by now, to groff font description files.

To that end, I am reassigning the ticket to you, Deri, but setting status to "None" so as to not prejudge the next step you take.

You can of course reassign it again if you like.

G. Branden Robinson <gbranden>
Group administrator
Sun 12 May 2024 02:22:46 PM UTC, comment #26: 

I have been investigating the AFMs contained in the tar files Branden referenced in comment #15. Using the 229 versions it is possible to generate the 35 fonts for grops. The only difference is that our fonts include kerning data for the ellipsis font which is not included in the AFMs, because commit 81b4ffadc1ced modified the files via a shell script to duplicate the full stop kerning information to ellipsis.

I have only tested the TR and TI fonts and I used the following afmtodit commands:-

./afmtodit -c -i0 -m -e ../font/devps/text.enc Adobe-Core35_AFMs-229/Times-Roman.afm font/devpdf/map/text.map DJTR

./afmtodit -c -i50 -a7 -e ../font/devps/text.enc Adobe-Core35_AFMs-229/Times-Italic.afm font/devpdf/map/text.map DJTI

For italic fonts you need to ensure that the "slant" value (-a) matches the value used previously, (in case of Times-Italic the AFM has an Italic Angle of 15.5, but the groff font was clearly produced with a slant of 7, i.e. it was overridden with the -a flag). I don't know why this was done, it is the only one with such an override:-

ABI:slant 10.5  ITCAvantGarde-BookOblique.afm:ItalicAngle -10.5
AI:slant 10.5   ITCAvantGarde-DemiOblique.afm:ItalicAngle -10.5
BMBI:slant 10   ITCBookman-DemiItalic.afm:ItalicAngle -10
BMI:slant 10    ITCBookman-LightItalic.afm:ItalicAngle -10
CBI:slant 11    Courier-BoldOblique.afm:ItalicAngle -11
CI:slant 11     Courier-Oblique.afm:ItalicAngle -11
HBI:slant 12    Helvetica-BoldOblique.afm:ItalicAngle -12
HI:slant 12     Helvetica-Oblique.afm:ItalicAngle -12
HNBI:slant 12   Helvetica-NarrowBoldOblique.afm:ItalicAngle -12
HNI:slant 12    Helvetica-NarrowOblique.afm:ItalicAngle -12
NBI:slant 16    NewCenturySchlbk-BoldItalic.afm:ItalicAngle -16
NI:slant 16     NewCenturySchlbk-Italic.afm:ItalicAngle -16
PBI:slant 10    Palatino-BoldItalic.afm:ItalicAngle -10
PI:slant 10     Palatino-Italic.afm:ItalicAngle -10
SS:slant 15.5   (S font with 15.5 degree transformation)
TBI:slant 15    Times-BoldItalic.afm:ItalicAngle -15
TI:slant 7      Times-Italic.afm:ItalicAngle -15.5
ZCMI:slant 14   ITCZapfChancery-MediumItalic.afm:ItalicAngle -14

Maybe some people on the list may know.

It is a good thing Branden found the AFMs since the conversion from afm to a groff font is not completely reversible.

Deri James <deri>
Group Member
Tue 07 May 2024 10:08:38 AM UTC, comment #25: 

comment #24:

> That's not, in my opinion, strictly coupled to the problem of determining the space width.  Certainly not a bad thing to do, but it should be a separate commit.  Oh, and even more so since as Dave points out below, it's a separate bug report too.


Please assign bug #65697 to yourself (or ask Dave or me to) if you want to claim it; it will help prevent a collision with other contributors.

G. Branden Robinson <gbranden>
Group administrator
Tue 07 May 2024 09:52:38 AM UTC, comment #24: 

Hi Deri & Dave,

comment #22:

> Speaking about afmtodit only.
>
> If vintage afm files are not forthcoming, then (2 - makefile target) is moot.


comment #23:

> Perhaps, or perhaps it's worth implementing anyway so as to be ready if the files ever materialize.  Either way, that discussion has little to do with this ticket's focus (the ZD characters).


In fact I think it's worth considering doing the reverse transformation once, or writing out own tool to interpret authentic vintage proprietary fonts and extract their metrics (and other uncopyrightable data), if such metrics files cannot be located.

We'd then ship those metrics files as part of groff, do the other Makefile stuff, and no future groff maintainers would have as much difficulty figuring out these procedures again.

comment #22:

> Only (1) is not dependent and that will be done when I rejig afmtodit to:-
>
> Look for different 'spaces' to set 'spacewidth'.
> Implement -ww switch - force even if 'space' found.
> Warn if -w used and 'space' found (but advise rerun with -ww to override).


I ask that we spell these '-w' (fallback) and '-W' (force), respectively.  Or maybe pick other another letter altogether for one (or both).

Generally, in Unix commands, repeating an option flag, when it is meaningful at all, means to do something "harder" or "more", not to do it differently.

> Document if -w or -ww used in font header comments.


That's not, in my opinion, strictly coupled to the problem of determining the space width.  Certainly not a bad thing to do, but it should be a separate commit.  Oh, and even more so since as Dave points out below, it's a separate bug report too.

comment #23:

> (This presumably means bug #65619, as 65659 is for another project.)
>
> Bug #65619 seems to cover different ground than bug #65697.  Neither one seems dependent on the other to me, though if I'm wrong, savannah now allows showing bug dependencies.


Anyway, to reëstablish where this ticket is, it's in "Need Info" state and assigned to me because I need to figure out if I can use the archive files in comment #15 with afmtodit to regenerate the devps font description files we have today.

G. Branden Robinson <gbranden>
Group administrator
Mon 06 May 2024 10:42:31 PM UTC, comment #23: 

Don't read too much into my opening multiple tickets: they're not saying "THESE THINGS MUST BE DONE" but giving venues to consider and discuss separate issues without cluttering this bug.  At least that was the theory. ;-}  Any ticket can be closed without action taken if that ultimately seems the right approach.

comment #22:

> If vintage afm files are not forthcoming, then (2 - makefile
> target) is moot.


Perhaps, or perhaps it's worth implementing anyway so as to be ready if the files ever materialize.  Either way, that discussion has little to do with this ticket's focus (the ZD characters).

> But this already has its own bug #65659 which is assigned to
> me and I'm doing font research.


(This presumably means bug #65619, as 65659 is for another project.)

Bug #65619 seems to cover different ground than bug #65697.  Neither one seems dependent on the other to me, though if I'm wrong, savannah now allows showing bug dependencies.

Dave <barx>
Group Member
Mon 06 May 2024 09:46:18 PM UTC, comment #22: 

Speaking about afmtodit only.

If vintage afm files are not forthcoming, then (2 - makefile target) is moot.

Only (1) is not dependent and that will be done when I rejig afmtodit to:-

Look for different 'spaces' to set 'spacewidth'.
Implement -ww switch - force even if 'space' found.
Warn if -w used and 'space' found (but advise rerun with -ww to override).
Document if -w or -ww used in font header comments.

But this already has its own bug #65659 which is assigned to me and I'm doing font research.

Deri James <deri>
Group Member
Mon 06 May 2024 08:47:47 PM UTC, comment #21: 

True for the third ticket of that trio, but the first two can be implemented regardless of the fate of the old AFM files.

As for the third, it documents a different issue from this ticket and should have its own venue, so that when this ticket is closed, side conversations about development goals aren't forgotten.  If a fix proves not doable -- whether because the original AFM files are lost in the mists of time, or for any other reason -- that ticket can document the reason(s).

Dave <barx>
Group Member
Mon 06 May 2024 07:34:25 PM UTC, comment #20: 

This might be a bit previous! Whether we should regenerate the grops font files is rather dependent on whether Branden is successful in locating afm files of a suitable vintage so that running current afmtodit will generate fonts with compatible meta-data capable of duplicating existing documents.

The problem is shown in https://savannah.gnu.org/bugs/?63018#comment14

Deri James <deri>
Group Member
Mon 06 May 2024 04:25:33 PM UTC, comment #19: 

comment #13:

> In fact I see two issues springing thence.  So, to summarize.
>
> 1.  Make comment headers of font description files we generate
> with tools more informative.


Now bug #65697.

> 2.  Add "maintainer-font-descriptions" make(1) targets for
> afmtodit and maybe hpdftodit and tfmtodit.


Now bug #65698.

> 3.  Update the procedure documented in "FOR-RELEASE" to include
> the effects of item 2 above.


Now bug #65699, depending on the previous one.

Dave <barx>
Group Member
Sat 04 May 2024 04:43:49 AM UTC, comment #18: 


comment #15:

> You've refreshed my memory.  There might not be a problem here.  I happen to have the following files lying around.  According to their time stamps, I grabbed them over 2 years ago.
>
> Adobe-Core35_AFMs-229.tar.gz
> Adobe-Core35_AFMs-314.tar.gz
>
> If I'm not mistaken, these generate the font description files in font/devps and font/devps/old.
>
> The proof of the pudding is of course in the afmtoditting.
>
> I'll report back when I know more.


Translating that last statement to a "status" and "assigned to" update.

G. Branden Robinson <gbranden>
Group administrator
Fri 03 May 2024 05:25:37 PM UTC, comment #17: 

It is a bit moot now. If Branden does have the original afms for the grops fonts, which produce identical meta-data as currently, then much better to run afmtodit on all of them as a refresh.

Deri James <deri>
Group Member
Fri 03 May 2024 05:18:13 PM UTC, comment #16: 

comment #14:

> I'm quite happy to put something in the header like "unicode
> names added by Deri 2024", but I certainly would not suggest
> removing the afmtodit header which documents the version used,


I agree, all metadata concerning the data's origins should be preserved, and documenting not just that the file was subsequently hand-edited, but specifically which part, is useful.

Dave <barx>
Group Member
Fri 03 May 2024 12:34:44 PM UTC, comment #15: 

comment #14:

> There is a slight wrinkle with this. Although we have the groff font files for devps, we don't have the original pfa and afm files which were used to generate those files. If we use the current generation of URW fonts, as the U-foundry in devpdf does, you will see differences between what is produced now, with current .afm files and afmtodit, and what was produced when the original grops fonts were created.


You've refreshed my memory.  There might not be a problem here.  I happen to have the following files lying around.  According to their time stamps, I grabbed them over 2 years ago.

Adobe-Core35_AFMs-229.tar.gz
Adobe-Core35_AFMs-314.tar.gz

If I'm not mistaken, these generate the font description files in font/devps and font/devps/old.

The proof of the pudding is of course in the afmtoditting.

I'll report back when I know more.

G. Branden Robinson <gbranden>
Group administrator
Fri 03 May 2024 12:19:38 PM UTC, comment #14: 

comment #9:

> Hi Dave,
>
> comment #8:
> > To clarify: my objection isn't the stale afmtodit version
>
> It is nevertheless a legitimate one.  We should be dogfooding the font description files that afmtodit generates.
>
> We also should not be advertising a file as automatically generated when it was hand-crafted.
>
> > (I doubt refreshing the file will change the data),
>
> If you mean re-running it as of groff 1.23.0 or recent Git, I agree: probably not.
>
> > but that the line claims afmtodit generated it at all: once Deri's ZD is committed, precious little of its content will be from afmtodit.
>
> I understood Deri as proposing to update "dingbats.map" and regenerating the ZD file using afmtodit with it...
>
> comment #5:
> > Probably the best way of doing this is by adding to dingbats.map, a suitable one is attached (to replace the one in font/devps/generate).  Also attached is a replacement ZD file to be placed in fonts/devps.
>
> ...hence the characterization of the "ZD" file as supplementary; I assume it was a demonstrator and/or a convenience for people who didn't want to fiddle with coming up with an afmtodit command invocation themselves.
>
> > Doing make will propagate the changes to devpdf and when U-ZD is created it will use the new dingbats.map.
>
> This matches my understanding.

There is a slight wrinkle with this. Although we have the groff font files for devps, we don't have the original pfa and afm files which were used to generate those files. If we use the current generation of URW fonts, as the U-foundry in devpdf does, you will see differences between what is produced now, with current .afm files and afmtodit, and what was produced when the original grops fonts were created.

You can see the difference between the two fonts TR (original grops file) and U-TR produced from latest afm file. Depending on which particular version of the URW fonts you have installed will affect your results, but on the version I have installed the original (copied from grops) has under 300 kernpairs defined but U-TR has about 4200. The actual glyph widths are largely the same, but the difference in the kerning data may make a difference in output.

I did a little test, using the U-foundry fonts to generate the groff_man_pages.pdf, and differences are not hard to spot, see the two screen shots. For this reason I don't think it is a good idea to refresh the original font files or everyone's documents will change slightly from what used to be produced. It may annoy a lot of users who have crafted a document to be "perfect" typographically (in their eyes) but will not appear again with such perfection. This was the reason I have the U-foundry in devpdf, you can choose if you want the traditional spacing or latest (which is not guaranteed to stay the same between versions because they are generated as part of the build), and having static groff font files makes checking for regressions between versions slightly easier.

As regards whether to describe my new ZD file as handcrafted or generated, it is of course, both. For the reasons given above, I consider it important to retain the traditional spacing in our stock fonts, so all the columns except the first are from the original afmtodit, as documented in the header, the name column has been updated with the groff unicode names, which is what would have happened if the current dingbats.map was used for the original run when ZD was first created. I'm quite happy to put something in the header like "unicode names added by Deri 2024", but I certainly would not suggest removing the afmtodit header which documents the version used, since that is the program which calculated the font meta-data, not me!

To try to clarify. The ZD file is not a demonstrator, it carefully preserves the original font meta-data adding the unicode name instead of "---". As to whether refreshing the file would alter the meta-data, the answer is yes, about 80 percent of the glyphs have different values for the meta-data. Admittedly the differences are very small umbers, and may not be noticeable unless someone is using a program to compare differences in the pdfs produced, but I would not want to put hand on heart to say there are NO differences since the values are changed for so many glyphs, which is why I made the effort to preserve the original meta-data rather than simply regenerate the font.


Deri James <deri>
Group Member
Fri 03 May 2024 04:19:10 AM UTC, comment #13: 

comment #12:

> comment #11:
> > It might help if we said so in the comment.  We could
> > furthermore include in that comment the presence/values of
> > command-line options that affect the generated contents.
>
> If you're talking about modifying afmtodit to include that information in its output, that seems like a good idea but well outside this ticket's scope.


Sure, just noting it so I don't forget.  It can become a separate ticket, as can comment #7.  In fact I see two issues springing thence.  So, to summarize.

1.  Make comment headers of font description files we generate with tools more informative.  Could affect afmtodit, hpftodit, tfmtodit, addftinfo, and xtotroff.

2.  Add "maintainer-font-descriptions" make(1) targets for afmtodit and maybe hpdftodit and tfmtodit.  (This might depend on what source material we already have in the tree.  If such material is missing (or so stale we should toss it out), we might need to document further maintainer-mode build dependencies in "INSTALL.REPO".)

3.  Update the procedure documented in "FOR-RELEASE" to include the effects of item 2 above.

G. Branden Robinson <gbranden>
Group administrator
Fri 03 May 2024 03:45:10 AM UTC, comment #12: 

comment #11:

> It might help if we said so in the comment.  We could
> furthermore include in that comment the presence/values of
> command-line options that affect the generated contents.


If you're talking about modifying afmtodit to include that information in its output, that seems like a good idea but well outside this ticket's scope.

Dave <barx>
Group Member
Fri 03 May 2024 01:43:58 AM UTC, comment #11: 

comment #10:

> comment #9:
> > I understood Deri as proposing to update "dingbats.map" and
> > regenerating the ZD file using afmtodit with it...
>
> Ah.  I did not grasp that the latter was generated from the former.


It might help if we said so in the comment.  We could furthermore include in that comment the presence/values of command-line options that affect the generated contents.

G. Branden Robinson <gbranden>
Group administrator
Fri 03 May 2024 01:38:50 AM UTC, comment #10: 

comment #9:

> I understood Deri as proposing to update "dingbats.map" and
> regenerating the ZD file using afmtodit with it...


Ah.  I did not grasp that the latter was generated from the former.  But that makes a lot more sense DRYly.

Dave <barx>
Group Member
Thu 02 May 2024 10:53:33 PM UTC, comment #9: 

Hi Dave,

comment #8:

> To clarify: my objection isn't the stale afmtodit version


It is nevertheless a legitimate one.  We should be dogfooding the font description files that afmtodit generates.

We also should not be advertising a file as automatically generated when it was hand-crafted.

> (I doubt refreshing the file will change the data),


If you mean re-running it as of groff 1.23.0 or recent Git, I agree: probably not.

> but that the line claims afmtodit generated it at all: once Deri's ZD is committed, precious little of its content will be from afmtodit.


I understood Deri as proposing to update "dingbats.map" and regenerating the ZD file using afmtodit with it...

comment #5:

> Probably the best way of doing this is by adding to dingbats.map, a suitable one is attached (to replace the one in font/devps/generate).  Also attached is a replacement ZD file to be placed in fonts/devps.


...hence the characterization of the "ZD" file as supplementary; I assume it was a demonstrator and/or a convenience for people who didn't want to fiddle with coming up with an afmtodit command invocation themselves.

> Doing make will propagate the changes to devpdf and when U-ZD is created it will use the new dingbats.map.


This matches my understanding.

G. Branden Robinson <gbranden>
Group administrator
Thu 02 May 2024 08:02:04 PM UTC, comment #8: 

To clarify: my objection isn't the stale afmtodit version (I doubt refreshing the file will change the data), but that the line claims afmtodit generated it at all: once Deri's ZD is committed, precious little of its content will be from afmtodit.

Dave <barx>
Group Member
Thu 02 May 2024 06:41:04 PM UTC, comment #7: 


comment #6:

> The introductory comment line should probably also be amended, since it currently says "This file has been generated with GNU afmtodit (groff) version 1.20.1" and that's no longer true for 99% of the file's content.


Our "FOR-RELEASE" file says this:


* Update font description files that we generate from external data and
  provide with our source distribution.

    Directory  Format                  Tool
    ---------  ------                  ----
    devX*      X11 core/server font    xtotroff

  The make(1) target "maintainer-font-descriptions" produces these font
  descriptions.


I remember having plans to add the grops (and consequently gropdf) font description files to this step...but I don't remember finishing everything I thought I needed to do for it.

Maybe this can be an opportunity to complete that procedure, and apply it.

G. Branden Robinson <gbranden>
Group administrator
Thu 02 May 2024 04:04:01 PM UTC, comment #6: 

Thanks, Deri!  I hadn't known about font/devps/generate/dingbats.map -- that should definitely be covered as well.

The attached "ZD" and "dingbats.map" being drop-in replacements for the existing files, I'm notating this bug as containing a patch.

Comparing your and Dorai's ZD files shows them to be substantively the same, with yours including the two lines proposed by comment #3:

$ diff <(sed '1,/^charset$/d' ZD.deri | cut -f1-5) <(sed '1,/^charset$/d' ZD.dorai)
13d12
< u261E "
22d20
< u2713 "

The nonsubstantive difference (elided by the "cut" command above) is the presence of the comment fields.  Personally I'd rather see the comment indicator ("--") omitted on lines with no comment content, but that's a style preference.  That change could be made via

sed 's/\t--$//' ZD

The introductory comment line should probably also be amended, since it currently says "This file has been generated with GNU afmtodit (groff) version 1.20.1" and that's no longer true for 99% of the file's content.

Dave <barx>
Group Member
Mon 29 Apr 2024 05:00:15 PM UTC, comment #5: 

Probably the best way of doing this is by adding to dingbats.map, a suitable one is attached (to replace the one in font/devps/generate). Also attached is a replacement ZD file to be placed in fonts/devps. Doing make will propagate the changes to devpdf and when U-ZD is created it will use the new dingbats.map.

The attached .trf file includes all the characters in the unicode 2700 code page (see U2700.pdf). When you run it you will see that some code points are missing from the font, this probably because the font was created before unicode and there have been numerous changes.

ZDR is a different kettle of fish! It does not make sense reversing many of the glyphs, and they would not have unicodes anyway. We currently only have one entry in reversed-dingbats.map, for \[lh]. For gropdf we have it defined in pdf.tmac as:-

.char \[lh] \X'pdf: xrev'\[rh]\X'pdf: xrev'


(file #55989, file #55990, file #55991, file #55992)

Deri James <deri>
Group Member
Sat 27 Apr 2024 04:19:10 AM UTC, comment #4: 

comment #3:

> On further thought, because these aliases should apply to both the ps and pdf devices, they shouldn't be in a file that only the ps device reads.
>
> Luckily, the font description file itself includes a mechanism to define aliases for the same glyph.  From the info manual:


>    A line in the 'charset' section can also have the form
>
>      NAME "
>
> identifying NAME as another name for the glyph mentioned in the preceding line.


> (On first blush, it may seem that defining this alias in font/devps/ZD still only applies to the ps device.  However, font/devpdf is populated from font/devps, so aliases in the devps font description file propagate to the devpdf one.)


I like this idea.

If there's anything in ZDR that should be similarly mapped, let's take care of that as well.

G. Branden Robinson <gbranden>
Group administrator
Sat 27 Apr 2024 03:43:54 AM UTC, comment #3: 

original submission:

> defining aliases (probably in tmac/ps.tmac) for \[OK] and \[rh] so
> that they can also be represented respectively by \[u2713] \[u261E]


On further thought, because these aliases should apply to both the ps and pdf devices, they shouldn't be in a file that only the ps device reads.

Luckily, the font description file itself includes a mechanism to define aliases for the same glyph.  From the info manual:

   A line in the 'charset' section can also have the form

     NAME "

identifying NAME as another name for the glyph mentioned in the preceding line.

(On first blush, it may seem that defining this alias in font/devps/ZD still only applies to the ps device.  However, font/devpdf is populated from font/devps, so aliases in the devps font description file propagate to the devpdf one.)

Dave <barx>
Group Member
Wed 05 Apr 2023 07:19:36 AM UTC, comment #2: 

original submission:

> \[u2713] [and] \[u261E] (the forms that, for instance, preconv will emit)


...unless bug #58796's proposal grows up to be a real preconv switch.  (But even that wouldn't remove the need for the \[uXXXX] forms, as it would be the user's discretion whether to employ that preconv switch.)

Dave <barx>
Group Member
Mon 05 Sep 2022 10:25:00 AM UTC, comment #1: 

Adding the author of the patched ZD to this ticket's cc: list in case he has further thoughts on its integration into groff.

Dave <barx>
Group Member
Mon 05 Sep 2022 10:17:12 AM UTC, original submission:  

Only two glyphs in ZD have names (\[OK] and \[rh]); the rest must be accessed with the \N escape.

But all of these glyphs have Unicode code points.  The font description file ought to recognize those names (in \[uXXXX] format) as well.

The work here has already been done, submitted on the email list a while back (http://lists.gnu.org/r/groff/2021-01/msg00061.html); it remains only to integrate this into groff.

The devps/ZD that that post points to is nearly a drop-in replacement (minus a few header lines) for font/devps/ZD in git, so I'm tempted to characterize this ticket as a [PATCH].  However, for completeness, at least one additional thing could be done: defining aliases (probably in tmac/ps.tmac) for \[OK] and \[rh] so that they can also be represented respectively by \[u2713] \[u261E] (the forms that, for instance, preconv will emit).

Dave <barx>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #56053:  grops-fonts-AFMs.tar.gz added by deri (168KiB - application/gzip)
file #56036:  umlautTimes.pdf added by deri (27KiB - application/pdf)
file #56004:  grog_TR.png added by deri (33KiB - image/png)
file #56005:  grog_U-TR.png added by deri (36KiB - image/png)
file #55990:  dingtst.trf added by deri (1KiB - application/octet-stream)
file #55991:  dingbats.map added by deri (2KiB - application/octet-stream)
file #55992:  dingtst.pdf added by deri (49KiB - application/pdf)
file #55989:  ZD added by deri (6KiB - 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 deri (Updated the item)
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by barx (author of updated ZD file)
  • -email is unavailable- added by barx (Submitted the item)
  •  

    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 14 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-05-14 deri Attached File- Added grops-fonts-AFMs.tar.gz, #56053
    2024-05-12 deri Attached File- Added umlautTimes.pdf, #56036
    2024-05-12 gbranden StatusNeed Info None
        Assigned togbranden deri
    2024-05-04 gbranden StatusNone Need Info
        Assigned toNone gbranden
    2024-05-03 deri Attached File- Added grog_TR.png, #56004
        Attached File- Added grog_U-TR.png, #56005
    2024-05-02 barx Summaryfont/devps/ZD: make glyphs accessible via their Unicode spellings [PATCH] make glyphs in ZD font accessible via their Unicode spellings
    2024-04-29 deri Attached File- Added ZD, #55989
        Attached File- Added dingtst.trf, #55990
        Attached File- Added dingbats.map, #55991
        Attached File- Added dingtst.pdf, #55992
    2022-09-05 barx Carbon-Copy- Added ds26gte

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code