I got several emails from the groff etc. mailing list.
The adress
bernd.war...@web.de # do not use this
is only for my private usage, not for groff.
My groff email adress is
groff-bernd.warken...@web.de
Please use this instead.
Bernd Warken
> Von: "Werner LEMBERG"
>
>
> >> So it's the package that counts.
> >
> > So you propose something like 1989-2014 or 1993-2014 for all groff
> > source files and the years should be enlarged to 2015 at the end of
> > this year?
>
> I suggest that in a range -, should be the year in
I tried to let groff create a data directory for the `refer' databases.
I changed aclocal.m4, Makefile.in, and configure.ac.
Unfortunately, the `refer' data directory is not created by `make install'.
I did such creations already several times, but I lost the knowledge how
that worked.
Bernd Wark
Hi Werner,
Werner LEMBERG wrote on Wed, Sep 03, 2014 at 12:50:35AM +0200:
> Ingo Schwarze wrote:
>> [...] Consequently, bumping the list of copyright years in such a
>> case is a misrepresentation of the legal situation - unless you
>> bumped based on some *other*, indeed copyrightable change, bu
>> Uh, oh, `autom4te.cache' stuff should definitely *not* go into the
>> repository!
>
> With autoconf, the directory autom4te.cache will be created and does
> not vanish even with .gitignmore. What is to be done?
I usually remove `autom4te.cache' after running autoconf. In any
case, it should
> Each file should have a list of copyright years. A year should be
> in that list if and only if the current version of the file contains
> a copyrightable amount of text that was origininally written in that
> year.
This is not what the FSF recommends. From
https://www.gnu.org/prep/maintain/h
> Von: "Ingo Schwarze"
> > Bernd Warken wrote on Wed, Sep 03, 2014 at 12:40:19AM +0200:
>
> >> Almost all of this commit seems wrong, please revert.
>
> > The file addition seem to be reasonable, why not use them?
>
> Not sure what you are talking about, it doesn't seem to me
> as if this commi
> Von: "Werner LEMBERG"
>
> > configure => autom4te.cache/output.0 | 1364
> > +-
> > autom4te.cache/requests | 78 ++
> > autom4te.cache/traces.0 | 951
>
> Uh, oh, `autom4te.cache' stuff should definitely *n
Hi Bernd,
Bernd Warken wrote on Wed, Sep 03, 2014 at 12:40:19AM +0200:
>> Von: "Ingo Schwarze"
>>> Bernd Warken wrote on Tue, Sep 02, 2014 at 05:03:50PM +:
>> Almost all of this commit seems wrong, please revert.
> The file addition seem to be reasonable, why not use them?
Not sure what yo
> configure => autom4te.cache/output.0 | 1364
> +-
> autom4te.cache/requests | 78 ++
> autom4te.cache/traces.0 | 951
Uh, oh, `autom4te.cache' stuff should definitely *not* go into the
repository!
Werne
> The following files are not UTF-8, bus US-ASCII encoded:
>
> BUG-REPORT
> FDL
> INSTALL
> INSTALL.REPO
> INSTALL.gen
> MANIFEST
> MORE.STUFF
> PROBLEMS
> PROJECTS
> README
> README.MinGW
Yep. An indication of the encoding makes only sense if there are
actually non-ASCII characters.
> In addi
Hi Bernd,
Bernd Warken wrote on Tue, Sep 02, 2014 at 09:10:32PM +:
> commit 70f06155a3017b7302124af1949ef078e4035e53
> Author: Bernd Warken
> Date: Tue Sep 2 23:03:14 2014 +0200
I guess there isn't much wrong with adding editor-specific annotations
to Makefiles if that editor is what the
> Von: "Ingo Schwarze"
> > Bernd Warken wrote on Tue, Sep 02, 2014 at 05:03:50PM +:
> > In groff source top directory add Emacs settings for most text files.
>
> Almost all of this commit seems wrong, please revert.
The file addition seem to be reasonable, why not use them?
> The foll
Hi Bernd,
Bernd Warken wrote on Tue, Sep 02, 2014 at 05:03:50PM +:
> commit fe9c3ec1ad398f07d89da432b9a5c8e777b517df
> Author: Bernd Warken
> Date: Tue Sep 2 19:03:15 2014 +0200
>
> In groff source top directory add Emacs settings for most text files.
> ---
> BUG-REPORT |6
> Von: "Werner LEMBERG"
>
>
> > I will right `addlib', but that will take some time. Would it be
> > possible and reasonable to use the already existing Heirloom
> > programs? Maybe some help from the Heirloom team might be very
> > helpful.
>
> For license reasons, this wouldn't be possible.
> I will right `addlib', but that will take some time. Would it be
> possible and reasonable to use the already existing Heirloom
> programs? Maybe some help from the Heirloom team might be very
> helpful.
For license reasons, this wouldn't be possible. On the other hand:
Why not simply point
> I will right `addlib', but that will take some time. Would it be
> possible and reasonable to use the already existing Heirloom programs?
> Maybe some help from the Heirloom team might be very helpful.
They could be checked for portability, made -Wall clean etc. But how about the
license? Un
I added a TODO part in the `groff' source file `PROJECTS'.
> > /usr/dict/papers/Ind Default database.
> >
> > That file does not exist. The directory for such a file should
> > be in the groff directory under /usr/local/share.
>
> Mhmm. Basically, you are right. However, given that groff's
> The following extensions of refer exist in Heirloom and the known
> refer history.
>
> 1) `refer.man' cites under `FILES':
> file.i Index files.
>
> But I couldn't find this file type and no documentation for them.
Those files are created by `indxbib'.
> 2) `refer.man' cites
The following extensions of refer exist in Heirloom and the known
refer history.
1) `refer.man' cites under `FILES':
file.i Index files.
But I couldn't find this file type and no documentation for them.
2) `refer.man' cites under `FILES':
/usr/dict/papers/Ind Default databa
> I should have said, for PostScript I think that can be a
> problem with "symbol" fonts being needed?
Traditionally, Postscript is mostly agnostic with regard to
predefined encodings. Glyphs normally have human-readable
names, and the standard "show" operator works with strings,
which are simpl
Hi again Mike,
> It helps a lot with reading UTF-8 if the output devices support the
> runes.
I should have said, for PostScript I think that can be a problem with
"symbol" fonts being needed? Others will know more, I'm sure.
Brian wrote:
> It all worked pretty well, though there were a lot of
I wanted to have a paper hardcopy of a (simple) web page to
hand out to new people here at work, but I wasn't happy with
the results from either Firefox or wkhtmltopdf. (Due to my
viewing preferences, the output from Firefox was completely
unusable [why aren't there different settings for screen
23 matches
Mail list logo