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

[Dave]

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

[comment #44 comment #44:]
> I suspect you're not using _echo_(1) the way you think you are.

I admit I didn't consider its portability, but on my system it output what I
intended.

> Because the default style is 'R', and the font 'ZDR' exists (on
> the  "ps" default output device), this actually works.

Yes, I misinterpreted my results earlier.  In fact groff does fail on a bogus
family.

$ groff -fBOGUS
troff: fatal error: invalid default font family 'BOGUS'

So there's nothing more to be done here.  Sorry for the red herring.


___

Reply to this item at:

  

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

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

[G. Branden Robinson]

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

[comment #43 comment #43:]
> A vast improvement!
> 
> But maybe a little _too_ quiet: groff disregards the -fZD flag without
telling the user it's doing so.
> 
> echo "\N'110'" | groff -ww -fZD
> 
> This fails to load the ZD family (because there is no such thing) or the ZD
font (because that's not what -f does), so outputs an "n" rather than a solid
square.  The invalid -f ought to at least provoke a warning, at least when all
warnings are activate.

I can't reproduce this.  I suspect you're not using _echo_(1) the way you
think you are.  Backslash escape sequences are not a portable application of
it.  POSIX specifies them, but (a) you need to double the backslash in this
case and (b) some environments _still_ won't support them, claiming that the
only feature echo should support is an `-n` flag.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html

I changed glyphs to a snowflake to make things work more obviously.


$ groff --version | tail -n 1
GNU troff (groff) version 1.23.0.1258-f66cd
$ printf "\\N'100'\n" | groff -ww -fZD >| dave.ps
$ tail dave.ps 
def/PL 792 def/LS false def
%%EndSetup
%%Page: 1 1
%%BeginPageSetup
BP
%%EndPageSetup
/F0 10/ZapfDingbats-Reverse SF(d)72 12 Q 0 Cg EP
%%Trailer
end
%%EOF


Because the default style is 'R', and the font 'ZDR' exists (on the  "ps"
default output device), this actually works.

If I change to a device that doesn't have 'ZDR', I get an error.


$ printf "\\N'100'\n" | groff -Tdvi -ww -fZD >| dave.ps
troff: fatal error: invalid default font family 'ZD'




___

Reply to this item at:

  

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

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

[Dave]

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

[comment #41 comment #41:]
> Now:
> 
> $ echo | ./build/test-groff -fZD -a
> 

A vast improvement!

But maybe a little _too_ quiet: groff disregards the -fZD flag without telling
the user it's doing so.

echo "\N'110'" | groff -ww -fZD

This fails to load the ZD family (because there is no such thing) or the ZD
font (because that's not what -f does), so outputs an "n" rather than a solid
square.  The invalid -f ought to at least provoke a warning, at least when all
warnings are activate.

This could reasonably be considered a separate bug, so I'm happy to open a new
report if warranted.


___

Reply to this item at:

  

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

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

[G. Branden Robinson]

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

So here's what got lost last week.

I did in fact implement a string comparison conditional operator in GNU
_troff_ in my working copy.

And it worked.


$ git stash show -p 1
diff --git a/src/roff/troff/input.cpp b/src/roff/troff/input.cpp
index 8d828a01e..7288f31c5 100644
--- a/src/roff/troff/input.cpp
+++ b/src/roff/troff/input.cpp
@@ -6002,6 +6002,25 @@ static bool do_if_request()
 }
 result = is_abstract_style(nm);
   }
+  else if (c == '~') {
+tok.next();
+symbol nm1 = get_name(true /* required */);
+symbol nm2 = get_name(true /* required */);
+if ((nm1.is_null() || nm2.is_null())) {
+  skip_branch();
+  return false;
+}
+macro *rm1 = static_cast(request_dictionary.lookup(nm1));
+macro *rm2 = static_cast(request_dictionary.lookup(nm2));
+macro *m1 = rm1->to_macro();
+macro *m2 = rm2->to_macro();
+if ((0 /* nullptr */ == m1) || (0 /* nullptr */ == m2)) {
+  error("cannot perform equality comparison on a request");
+  skip_branch();
+  return false;
+}
+result = (*m1 == *m2);
+  }
   else if (tok.is_space())
 result = false;
   else if (tok.is_usable_as_delimiter()) {


But I immediately thought better of it.

1.  We already have 


.if '\?foo\?'\?bar\?' .tm strings are equal


2.  The `\?` escape sequence is already a GNU _troff_ extension.

3.  I didn't feel good about adding syntactic sugar for this form of
expression.

4.  String comparisons are rare outside of macro files.

5.  Macro files desiring to do string comparisons should decide whether they'd
rather let them be formatted (a popular choice, even in _groff_'s own macro
files) or not.  In most cases there is no harm in performing formatting on the
comparands.  (Where there is, you _must_ use `\?`.)

...

This is growing long.  I will return to it later.


___

Reply to this item at:

  

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

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

[G. Branden Robinson]

Update of bug #64155 (group groff):

  Status: In Progress => Fixed  
 Open/Closed:Open => Closed 

___

Follow-up Comment #41:

I'll follow up with a brief (I hope) recapitulation of my lost comment.

The following bug-closing context will help reduce the length of that.


commit 609d962fc02e517744ee4f68160648a78df3a020
Author: G. Branden Robinson 
Date:   Sat May 11 09:54:35 2024 -0500

[tmac]: Perform actual string comparisons.

* tmac/fallbacks.tmac:
* tmac/troffrc-end: Bracket comparands to formatted output comparison
  operator with `\?` escape sequences to perform a more elementary
  string comparison on them (cf. a comparison of _formatted text_).
  This way they continue to perform their function even if the default
  font family has no coverage of Basic Latin (not a bizarre choice when
  considering potential rendering of documents using Devanagari or East
  Asian languages).  Unfortunately this means of comparing strings,
  while long documented in the GNU troff Manual, is neither idiomatic
  for *roff macro programmers nor portable to AT troff.  (The *roff
  language historically _lacks_ a string comparison operator.)  Each
  macro package will have to decide for itself whether it wants to have
  portability at the expense of requiring Basic Latin coverage (possibly
  switching fonts before and after a formatted output comparison for the
  sole purpose of obtaining it).  These two files are unconditionally
  loaded by the stock `troffrc`, and therefore must be dealt with in any
  case.

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

Previously:

$ echo | groff -fZD -a
troff:/.../groff/1.23.0/tmac/fallbacks.tmac:14: warning: character 'p' not
defined
troff:/.../groff/1.23.0/tmac/fallbacks.tmac:14: warning: character 's' not
defined
troff:/.../groff/1.23.0/tmac/fallbacks.tmac:14: warning: character 'a' not
defined
troff:/.../groff/1.23.0/tmac/fallbacks.tmac:14: warning: character 'c' not
defined
troff:/.../groff/1.23.0/tmac/fallbacks.tmac:14: warning: character 'i' not
defined
troff:/.../groff/1.23.0/tmac/fallbacks.tmac:16: warning: character 'l' not
defined
troff:/.../groff/1.23.0/tmac/fallbacks.tmac:16: warning: character 't' not
defined
troff:/.../groff/1.23.0/tmac/fallbacks.tmac:16: warning: character 'n' not
defined
troff:/.../groff/1.23.0/tmac/fallbacks.tmac:17: warning: character 'u' not
defined
troff:/.../groff/1.23.0/tmac/fallbacks.tmac:17: warning: character 'f' not
defined
troff:/.../groff/1.23.0/tmac/troffrc-end:7: warning: character 'h' not
defined
troff:/.../groff/1.23.0/tmac/troffrc-end:7: warning: character 'm' not
defined


Now:

$ echo | ./build/test-groff -fZD -a





___

Reply to this item at:

  

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

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

[G. Branden Robinson]

Update of bug #64155 (group groff):

  Status:   Confirmed => In Progress

___

Follow-up Comment #40:

I have a fix for this involving something old and in plain sight.


___

Reply to this item at:

  

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

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

[Dave]

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

Self-followup:

[comment #37 comment #37:]
> in a way back compatible to almost any older troff.

Obviously, this specific example is not AT due to the long names,
but the logic can be written portably.


___

Reply to this item at:

  

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

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

[G. Branden Robinson]

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

[https://savannah.nongnu.org/support/?111059 Frustration submitted.]


___

Reply to this item at:

  

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

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

[Dave]

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

[comment #34 comment #34:]
> Maybe it is time for a proper string equality operator in our
> conditional expressions.

While that would be a useful addition to the language, equivalent
functionality can be achieved in user space, in a way back compatible to
almost any older troff.

.de string_compare
.  ft TR
.  ie '\\$1'\\$2' .nr strings_equal 1
.  el .nr strings_equal 0
.  ft P
..
.
.ft ZD
.
.if 'foo'foo' .tm foo = foo, via output comparison operator
.if 'foo'bar' .tm foo = bar, via output comparison operator
.
.string_compare foo foo
.if \n[strings_equal] .tm foo = foo, via string_compare macro
.string_compare foo bar
.if \n[strings_equal] .tm foo = bar, via string_compare macro




___

Reply to this item at:

  

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

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

[G. Branden Robinson]

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

Sigh.  Wrote a long comment.  Form was stale.  Document Expired.  Text lost.


___

Reply to this item at:

  

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

[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 #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 

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

[G. Branden Robinson]

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

[comment #32 comment #32:]
> [comment #28 comment #28:]
> > [comment #27 comment #27:]
> > Specifically, am I correct to claim either of the following?
> > 
> > A.  "[G]iven that mom has her own system of managing fonts, and part of
her contract with the user [...] is that [the] user will not go behind her
back and start invoking *roff requests." is a false statement.  (Possibly an
exaggeration.)
> 
> Oversimplification, possibly my fault.  You got the idea from this bit of
the documentation:
> 
> "In some cases, mom’s typesetting macros merely imitate groff primitives.
In others, they approach typesetting concerns in conceptually new ways (for
groff, at least). This should present no problem for newcomers to groff who
are learning mom. Old groff hands should be careful. Just because it looks
like a duck and walks like a duck does not, in this instance, mean that it is
a duck. When using mom, stay away from groff primitives if mom provides a
macro that accomplishes the same thing."

Yes.  I haven't read anything like all of _mom_'s documentation, but the
foregoing sounds a fairly large bell in my head.  I likely did overinterpret
it.

> That's not a contract, it's a recommendation.  I don't want users imagining.
for example, that they can use either .ps or .PT_SIZE interchangeably (or
.ft/.FT) and expect the same results.  E.g. if AUTOLEAD is enabled, .PT_SIZE
changes the pointsize and updates the leading.  Plain .ps only changes the
size, hence the recommendation to stay away from groff primitives *if mom
provides a macro that accomplishes the same thing.*  There a number of macros
where the documentation explicitly states that using a primitive instead of a
macro is fine.

Acknowledged.
 
> I'm not comfortable with the statement "mom has her own system of managing
fonts."  Other than that .FAM and .FT perform checks and set registers needed
by other macros, and the inclusion of pre-defined supplementary styles (none
loaded in positions 1-4), there is nothing unique about mom's font
management.

No indeed; given your clarification above, item A is greatly overstated.

> > B.  The statement "By issuing appropriate formatter instructions, you can
override these defaults before your document writes its first glyph." in our
manual should be dropped, or revised to stipulate that some macro packages
(namely _mom_), will assume that that before a document requests a glyph to be
formatted, mounting position 1 will be assigned to a style named 'R'.
> 
> I'm confused.  The docs currently say, "The default mounting position, and
therefore style, is always '1' ('R')"  Why would this suddenly only apply to
"some" macro packages?  I don't think the B. statement should be dropped, but
I would change "these defaults" because the only formatter flag pertinent to
that section of the documentation is -f .

I think I can probably leave this item as-is.  I certainly should not add any
special caveat about _mom_, but I think the "these defaults" sentence can stay
once the larger context, an introduction to _groff_'s font concept, is
considered.

Here is that context.


5.19 Using Fonts


In digital typography, a "font" is a collection of characters in a
specific typeface that a device can render as glyphs at a desired
size.(1)  (*note Using Fonts-Footnote-1::) A 'roff' formatter can change
typefaces at any point in the text.  The basic faces are a set of
"styles" combining upright and slanted shapes with normal and heavy
stroke weights: 'R', 'I', 'B', and 'BI'--these stand for roman, italic,
bold, and bold-italic.  For linguistic text, GNU 'troff' groups
typefaces into "families" containing each of these styles.(2)  (*note
Using Fonts-Footnote-2::) A "text font" is thus often a family combined
with a style, but it need not be: consider the 'ps' and 'pdf' devices'
'ZCMI' (Zapf Chancery Medium italic)--often, no other style of Zapf
Chancery Medium is provided.  On typesetters, at least one "special
font" is available, comprising "unstyled" glyphs for mathematical
operators and other purposes.

   Like the AT 'troff' formatter, GNU 'troff' does not itself load or
manipulate a digital font file;(3) (*note Using Fonts-Footnote-3::)
instead it works with a "font description file" that characterizes it,
including its glyph repertoire and the "metrics" (dimensions) of each
glyph.(4)  (*note Using Fonts-Footnote-4::) This information permits the
formatter to accurately place glyphs with respect to each other.  Before
using a font description, the formatter associates it with a "mounting
position", a place in an ordered list of available typefaces.  So that a
document need not be strongly coupled to a specific font family, in GNU
'troff' an output device can associate a style in the abstract sense
with a mounting position.  Thus the default family can be combined with
a style dynamically, producing a "resolved font name".  A user-specified
font name that combines family 

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

[G. Branden Robinson]

Update of bug #64155 (group groff):

Category:   Font - others/general => Core   
  Status:   Need Info => Confirmed  
 Summary: specifying -fZD on command line generates warnings
=> [troff] specifying -fZD on command line generates warnings


___

Reply to this item at:

  

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