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
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
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
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
Update of bug #63018 (group groff):
Status: Need Info => None
Assigned to:gbranden => deri
___
Follow-up Comment #27:
[comment #26 comment
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
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
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
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
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
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
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
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"
Update of bug #63018 (group groff):
Status:None => Need Info
Assigned to:None => gbranden
___
Follow-up Comment #18:
[comment #15 comment
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.
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
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,
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_
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
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
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
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
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
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.
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
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,
26 matches
Mail list logo
