[bug #65619] [afmtodit] want a default value for space width if unspecified

[G. Branden Robinson]

Update of bug #65619 (group groff):

 Assigned to:gbranden => deri   

___

Follow-up Comment #5:

[comment #3 comment #3:]
> A useful change to afmtodit would be to look for other space glyphs in the
font (u0020 and u00A0) if space is not found, then if none are found, use the
value given on the command line, and if that is missing, it is not a special
font, warn user the font will be unusable in groff and suggest they rerun
afmtodit with a suitable -w flag.

This proposal sounds good to me.  *Normally*, I think the Unix command-line
model treats options as overrides rather than fallbacks.  But sometimes you
need the latter.  Sometimes you need both (witness _preconv_).

So, check for "space", "uni0020", and "uni00A0" in that order?

Hmm, that may be too simple.

There are over 100 matches for "space" in the Adobe Glyph List.

Leaving aside "monospace" names for A-Z, a-z, 0-9, and some other stuff.  I
_was_ going to guess the 94 graphical code points, but I see fun stuff like
this too.

sterlingmonospace;FFE1

That ain't ASCII.  That ain't ASCII a 'tall.

But with respect to (non-zero-width) spaces, I see:

ideographicspace;3000
nbspace;00A0

There may be others, not sure I got 'em all.

Here's a fun one:

spacehackarabic;0020

NFI if we should deal with that one.

Advice desired.


___

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/

[grog] Certain preprocessors not recognized

[Morten Bo Johansen]

Hi

Unless I misunderstand something, shouldn't grog detect e.g. a
.cstart macro in a document and then come up with a suggestion
that includes the "-j" argument for the chem(1) preprocessor?

  ~/ % echo .cstart | ./grog.pl
  groff -

These do not work either:

  'lilypond', 'glilypond',
  'Perl', 'gperl',
  'pinyin',   'gpinyin',
  
This is both with the git version of groff and with 1.23.0

Thanks,
Morten

[bug #64155] [troff] specifying -fZD on command line generates warnings

[Deri James]

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

[comment #34 comment #34:]
> > > Well, when you're prepared to discuss it, it would be good to know
if/how Dave's original report in comment #0 was invalid
> > 
> > I think I can answer this - it is certainly not invalid, it just has
nothing to do with ZD not being a "proper" family (in your eyes).
> 
> This isn't a matter of my subjective opinion; the "family" and "style"
features of _groff_ date back to 1990.
> 
>
https://git.savannah.gnu.org/cgit/groff.git/tree/ChangeLog.115?h=1.23.0#n5535
> 
> There is a long AT _troff_ hangover of assuming that `R`, `I`, and `B`
fonts will exist (or, in _groff_, that abstract styles that work analogously
to fonts of those names will).  This assumption can extend to `S` as well. 

I don't dispute R, I, B, and BI is a family, it's not the only possible
family, previously a font family of just R and B would be happily accepted and
\fBword\fP worked as expected. It was your code which insisted on a far more
inflexible rule.

[...]

> > If you do -fZD, which has no alphabetic glyphs, any start up macros which
contain conditional statements of the form:-
> > 
> > .if '\*[.T]'html' \" etc..
> > 
> > Will produce character not found errors, since, as we know, both sides are
formatted in separate environments and compared.
> 
> Yes.  I find this troublesome.
> 
> It seems to be an idiom to use the output comparison operator (a term I had
to coin, for it had no name) for string comparisons even when there is no
intention of formatting either of the comparands as text.
> 
> But that idiom would seem to port poorly to document environments where the
basic Latin alphabet doesn't need to be formatted at all.
> 
> > The give away in Dave's initial report is that the "character undefined"
errors spell out the words "ps/pdf/html" at least can be seen.
> 
> You paid better attention than I did.  I managed to overlook it, staring
more closely at the 1.23.0 output, seeing only the character sequence
"psaciltnufhm", and deducing nothing much in particular from that.
> 
> Good sleuthing!
> 
> But also there's no way in hell we should be spewing diagnostics on, or
failing to correctly perform comparisons within, control structures that are
initializing the state of the formatter.  These macro files are profoundly
uninterested in formatting any output, and they'd be buggy if they did so,
since an empty input document should produce no output no matter what (stock)
macro packages or startup macro files you load.
> 
> Maybe it is time for a proper string equality operator in our conditional
expressions.

Ooh, yes please.

> > I'm sure this "feature" has come up before. Even with Branden's code which
stopped -fZD from working did not address the real problem because if you have
four fonts with R, I, B, and BI extension but don't contain alphabetic
characters, -f works for the "family" but you will see exactly the same errors
as Dave reported.
> 
> Fair point.
>  
> > One way for a proper fix, is to create a copy of TR as TRSKEL, add the
"special" parameter, and change the name parameter to TRSKEL, remove all
kernpairs, delete all glyph definitions above 127, and finally alter the DESC
file by incrementing the number and adding TRSKEL on the end. This will solve
the error occurring if you use -f on fonts which don't contain ascii glyphs,
such as some CJK fonts. This can all be done in the devpdf directory (I have
done it for testing), but a very similar change can be made to devps as well.
> 
> Here, I must disagree.  The foregoing strikes me as a workaround rather than
a proper fix.

I agree, it's a workaround, but it is also a proper fix in the sense that it
prevented Dave's errors appearing for non-latin fonts, which you agreed your
code did not (so was not a proper fix).

[...]

> A string equality test.  Not a comparison of node lists, which are laden
with all sorts of other data.[1]  Just a string equality test.
> 
> Well, let's give the people what they are asking for.  Especially since a
lot of the time, "the people" is us.

+1 here, that would be a proper fix too. What semantics are you considering
for this new conditional?

> [1] Now that I've started resurrecting and expanding the formatter's
facilities for node dumping, I'm getting a better notion of what all that
extra data is.  I begin to revise upward my expectations of the performance
improvement I can expect from a straight-up simple string equality operator,
particularly since the operation can be handed off to the C++ standard library
and from there, likely to platform-specific, optimized assembly code.  It
hasn't escaped me that this might also help, say, string comparisons of PDF
bookmark tags, since they too are not output to be formatted.

I liked .pline.



___

Reply to this item at:

  

___
Message sent via Savannah

[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 #64155] [troff] specifying -fZD on command line generates warnings

[G. Branden Robinson]

Follow-up Comment #34, bug #64155 (group groff):


commit 604361951c9ddad621b3e0786ca7a2946e212842
Author: G. Branden Robinson 
Date:   Fri May 3 00:00:59 2024 -0500

Revert "[troff]: Validate a font family before using it."

This reverts commit 39ffa368dc6a1de4c11cf3f4f5b8594d3c974173.

There were a few problems with this approach; possibly the biggest is
that styles can be dynamically constructed, for which this validation
process was no help, and could be a misleading hindrance.

Thanks to Dave Kemper, Deri James, and Peter Schaffter for the
discussion.

 is already reopened.


[comment #29 comment #29:]
> > Well, when you're prepared to discuss it, it would be good to know if/how
Dave's original report in comment #0 was invalid
> 
> I think I can answer this - it is certainly not invalid, it just has nothing
to do with ZD not being a "proper" family (in your eyes).

This isn't a matter of my subjective opinion; the "family" and "style"
features of _groff_ date back to 1990.

https://git.savannah.gnu.org/cgit/groff.git/tree/ChangeLog.115?h=1.23.0#n5535

There is a long AT _troff_ hangover of assuming that `R`, `I`, and `B` fonts
will exist (or, in _groff_, that abstract styles that work analogously to
fonts of those names will).  This assumption can extend to `S` as well. 


$ git blame font/devhtml/DESC.proto
fe93746e79 (Werner LEMBERG 2001-01-17 14:53:37 +  1) res 240
fe93746e79 (Werner LEMBERG 2001-01-17 14:53:37 +  2) hor 24
fe93746e79 (Werner LEMBERG 2001-01-17 14:53:37 +  3) vert 40
fe93746e79 (Werner LEMBERG 2001-01-17 14:53:37 +  4) unitwidth 10
6d5bbb4fbb (Werner LEMBERG 2003-03-31 14:31:21 +  5) sizes 1-1000 0
2738e8ceb6 (Werner LEMBERG 2002-08-07 15:01:32 +  6) fonts 9 R I B BI CR
CI CB CBI S
fe93746e79 (Werner LEMBERG 2001-01-17 14:53:37 +  7) tcommand
8fe7c747b7 (Werner LEMBERG 2004-10-08 07:08:08 +  8) unscaled_charwidths
fe93746e79 (Werner LEMBERG 2001-01-17 14:53:37 +  9) postpro post-grohtml
fe93746e79 (Werner LEMBERG 2001-01-17 14:53:37 + 10) prepro  pre-grohtml
fe93746e79 (Werner LEMBERG 2001-01-17 14:53:37 + 11)
use_charnames_in_special
fe93746e79 (Werner LEMBERG 2001-01-17 14:53:37 + 12) pass_filenames
4d917850b2 (Werner LEMBERG 2006-02-26 22:21:38 + 13) unicode


Eventually,
[https://git.savannah.gnu.org/cgit/groff.git/commit/src/devices/grohtml/grohtml.1.man?h=1.23.0=b128913074d43c11d0f0eec035fcdb316ad7e397
I documented the foregoing.]

Your critique implies that we should not further entrench assumptions
regarding the availability of font or style names.  Fair enough.

> If you do -fZD, which has no alphabetic glyphs, any start up macros which
contain conditional statements of the form:-
> 
> .if '\*[.T]'html' \" etc..
> 
> Will produce character not found errors, since, as we know, both sides are
formatted in separate environments and compared.

Yes.  I find this troublesome.

It seems to be an idiom to use the output comparison operator (a term I had to
coin, for it had no name) for string comparisons even when there is no
intention of formatting either of the comparands as text.

But that idiom would seem to port poorly to document environments where the
basic Latin alphabet doesn't need to be formatted at all.

> The give away in Dave's initial report is that the "character undefined"
errors spell out the words "ps/pdf/html" at least can be seen.

You paid better attention than I did.  I managed to overlook it, staring more
closely at the 1.23.0 output, seeing only the character sequence
"psaciltnufhm", and deducing nothing much in particular from that.

Good sleuthing!

But also there's no way in hell we should be spewing diagnostics on, or
failing to correctly perform comparisons within, control structures that are
initializing the state of the formatter.  These macro files are profoundly
uninterested in formatting any output, and they'd be buggy if they did so,
since an empty input document should produce no output no matter what (stock)
macro packages or startup macro files you load.

Maybe it is time for a proper string equality operator in our conditional
expressions.

> I'm sure this "feature" has come up before. Even with Branden's code which
stopped -fZD from working did not address the real problem because if you have
four fonts with R, I, B, and BI extension but don't contain alphabetic
characters, -f works for the "family" but you will see exactly the same errors
as Dave reported.

Fair point.
 
> One way for a proper fix, is to create a copy of TR as TRSKEL, add the
"special" parameter, and change the name parameter to TRSKEL, remove all
kernpairs, delete all glyph definitions above 127, and finally alter the DESC
file by incrementing the number and adding TRSKEL on the end. This will solve
the error occurring if you use -f on fonts which don't contain ascii glyphs,
such as some CJK fonts. This can all be done in the devpdf