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

[Dave]

Follow-up Comment #37, bug #63018 (group groff):

[comment #36 comment #36:]
> > Branden, do I need to open a separate ticket for this?
> 
> Yes, for _different_ maintainer-mode targets

Everybody, welcome bug #66033 to the world.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature

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

[G. Branden Robinson]

Follow-up Comment #36, bug #63018 (group groff):

[comment #34 comment #34:]
> [comment #33 comment #33:]
> > This started off as a simple request to give access to Dingbats
> > glyphs via their \[u] names... and then wandered!
>
> I agree, the solution you outline will resolve this bug's complaint.  So
taking this out of Need Info.
> 
> It appears that the files you attached all the way back in comment #5 cover
all this.

Quoting this just so to help it reach the top of mind in this epic ticket.

> > The main wandering was the desire to make the grops fonts to
> > be generated during a groff build, and I have given up on that
> > little beauty, although it is 99% doable.

I agree.  I got some ways toward it prior to _groff_ 1.23.0, but got hung up
on the "artifact management" problem.  A bit of work on "maintainer mode" is
required.  My attempt at that is why [this 
https://git.savannah.gnu.org/cgit/groff.git/tree/FOR-RELEASE?h=1.23.0#n12
exists].  It turned out that the X11 fonts were the easiest to deal with.  Too
bad they're by far the least used (well, maybe they beat out _grolbp_).

> That still seems a worthy long-term goal, though, and I'd hate to toss out
the 99%-of-the-way work you've already put in.  But this should definitely be
a separate ticket: It's not necessary in order to resolve the original
problem, as you note.

[comment #35 comment #35:]

> It might even be bug #65698 (which was spawned from Branden's list of tasks
in comment #13).  Or maybe #65698 is merely a prerequisite for generating the
grops fonts?  I don't have much of a handle on what #65698 is asking for.  (I
did open it, but merely parroting Branden's words.)

Rereading my own words, I'm a little fuzzy myself, even after going back down
to comment #13 for context.

I think the idea is that if the font-description-generating tools are
parameterized somehow as constructed in the Git repository, then we need a
process for building them, and that's what #65698 is about: maintainer-mode
targets for updating _afmtodit_, _hpftodit_, and _tfmtodit_ to contain
whatever refreshable information we want to include in them.

That's a separate task, but likely a prerequiste for...
 
> Branden, do I need to open a separate ticket for this?

Yes, for _different_ maintainer-mode targets that produce font descriptions we
check into the repository and ship in distribution archives describing the
"stock" fonts we expect to support for PostScript, LJ4, and DVI output
devices.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature

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

[Dave]

Follow-up Comment #35, bug #63018 (group groff):

Self-follow-up:

[comment #34 comment #34:]
> > The main wandering was the desire to make the grops fonts to
> > be generated during a groff build,
> 
> But this should definitely be a separate ticket:

It might even be bug #65698 (which was spawned from Branden's list of tasks in
comment #13).  Or maybe #65698 is merely a prerequisite for generating the
grops fonts?  I don't have much of a handle on what #65698 is asking for.  (I
did open it, but merely parroting Branden's words.)

Branden, do I need to open a separate ticket for this?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature

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

[Dave]

Update of bug #63018 (group groff):

  Status:   Need Info => Confirmed  

___

Follow-up Comment #34:

[comment #33 comment #33:]
> This started off as a simple request to give access to Dingbats
> glyphs via their \[u] names... and then wandered!

Yes, it's gone on quite the sightseeing expedition!

> This means the solution to this bug is simple:

I agree, the solution you outline will resolve this bug's complaint.  So
taking this out of Need Info.

It appears that the files you attached all the way back in comment #5 cover
all this.

> The main wandering was the desire to make the grops fonts to
> be generated during a groff build, and I have given up on that
> little beauty, although it is 99% doable.

That still seems a worthy long-term goal, though, and I'd hate to toss out the
99%-of-the-way work you've already put in.  But this should definitely be a
separate ticket: It's not necessary in order to resolve the original problem,
as you note.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature

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

[Deri James]

Follow-up Comment #33, bug #63018 (group groff):

Hi Dave,

This started off as a simple request to give access to Dingbats glyphs via
their \[u] names... and then wandered!

The main wandering was the desire to make the grops fonts to be generated
during a groff build, and I have given up on that little beauty, although it
is 99% doable. So we are stuck with grops fonts in aspic, we just deliver the
file as part of groff.

This means the solution to this bug is simple: install the new dingbats.map
file and run the current afmtodit (with appropriate parameters), using the
current dingbats.afm file, and replace the current ZD and ZDR files with the
results.

There is no manual editing of the font files required.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature

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

[Dave]

Update of bug #63018 (group groff):

  Status:None => Need Info  
 Assigned to:deri => None   

___

Follow-up Comment #32:

Setting Status to reflect comment #31.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature

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

[Deri James]

Follow-up Comment #31, bug #63018 (group groff):

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)

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

[Dave]

Follow-up Comment #30, bug #63018 (group groff):

[comment #29 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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Deri James]

Follow-up Comment #29, bug #63018 (group groff):

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)

___

Additional Item Attachment:

File name: umlautTimes.pdfSize: 27KiB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-0329bc976c56c39d462c6cc5223a9b3c843a6486.tar.gz


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Dave]

Follow-up Comment #28, bug #63018 (group groff):

[comment #27 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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[G. Branden Robinson]

Update of bug #63018 (group groff):

  Status:   Need Info => None   
 Assigned to:gbranden => deri   

___

Follow-up Comment #27:

[comment #26 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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Deri James]

Follow-up Comment #26, bug #63018 (group groff):

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 10ITCBookman-LightItalic.afm:ItalicAngle -10
CBI:slant 11Courier-BoldOblique.afm:ItalicAngle -11
CI:slant 11 Courier-Oblique.afm:ItalicAngle -11
HBI:slant 12Helvetica-BoldOblique.afm:ItalicAngle -12
HI:slant 12 Helvetica-Oblique.afm:ItalicAngle -12
HNBI:slant 12   Helvetica-NarrowBoldOblique.afm:ItalicAngle -12
HNI:slant 12Helvetica-NarrowOblique.afm:ItalicAngle -12
NBI:slant 16NewCenturySchlbk-BoldItalic.afm:ItalicAngle -16
NI:slant 16 NewCenturySchlbk-Italic.afm:ItalicAngle -16
PBI:slant 10Palatino-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 15Times-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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[G. Branden Robinson]

Follow-up Comment #25, bug #63018 (group groff):

[comment #24 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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[G. Branden Robinson]

Follow-up Comment #24, bug #63018 (group groff):

Hi Deri & Dave,

[comment #22 comment #22:]
> Speaking about afmtodit only.
> 
> If vintage afm files are not forthcoming, then (2 - makefile target) is
moot.

[comment #23 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 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 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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Dave]

Follow-up Comment #23, bug #63018 (group groff):

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


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Deri James]

Follow-up Comment #22, bug #63018 (group groff):

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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Dave]

Follow-up Comment #21, bug #63018 (group groff):

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


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Deri James]

Follow-up Comment #20, bug #63018 (group groff):

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


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Dave]

Follow-up Comment #19, bug #63018 (group groff):

[comment #13 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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[G. Branden Robinson]

Update of bug #63018 (group groff):

  Status:None => Need Info  
 Assigned to:None => gbranden   

___

Follow-up Comment #18:


[comment #15 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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Deri James]

Follow-up Comment #17, bug #63018 (group groff):

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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Dave]

Follow-up Comment #16, bug #63018 (group groff):

[comment #14 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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[G. Branden Robinson]

Follow-up Comment #15, bug #63018 (group groff):

[comment #14 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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Deri James]

Follow-up Comment #14, bug #63018 (group groff):

[comment #9 comment #9:]
> Hi Dave,
> 
> [comment #8 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 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.

(file #56004, file #56005)

___

Additional Item Attachment:

File name: grog_TR.pngSize: 33KiB


File name: grog_U-TR.png  Size: 36KiB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at

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

[G. Branden Robinson]

Follow-up Comment #13, bug #63018 (group groff):

[comment #12 comment #12:]
> [comment #11 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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Dave]

Follow-up Comment #12, bug #63018 (group groff):

[comment #11 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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[G. Branden Robinson]

Follow-up Comment #11, bug #63018 (group groff):

[comment #10 comment #10:]
> [comment #9 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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Dave]

Follow-up Comment #10, bug #63018 (group groff):

[comment #9 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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[G. Branden Robinson]

Follow-up Comment #9, bug #63018 (group groff):

Hi Dave,

[comment #8 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 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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Dave]

Follow-up Comment #8, bug #63018 (group groff):

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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[G. Branden Robinson]

Follow-up Comment #7, bug #63018 (group groff):


[comment #6 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 fontxtotroff

  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. 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Dave]

Update of bug #63018 (group groff):

 Summary: font/devps/ZD: make glyphs accessible via their
Unicode spellings => [PATCH] make glyphs in ZD font accessible via their
Unicode spellings

___

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


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/