On Wed, Aug 27, 2014 at 08:28:53AM +0200, Werner LEMBERG wrote:
> Colin Watson wrote:
> > 2) Add an option or environment variable or something to suppress
> > the inclusion of timestamps.
>
> This is the way to go, I guess.
>
> > For bonus points, set this when building groff's own
> >
Hi Pierre-Jean,
> This was, in fact, our first opinion. But we finally thought it would
> be annoying for the groff community to receive mails about technical
> issues which does not concern groff.
That might happen if the volume gets high, but we're a polite bunch and
can point that out if it ha
Hi Colin,
> 2) Add an option or environment variable or something to suppress the
> inclusion of timestamps.
Werner's said he's in favour of this approach. I'd just wonder if the
option of providing a timestamp in the environment variable would also
be useful. Then user's are free to take it
Hi Blake,
> .nr Hb 0
> .nr Hs 0
> .nr Hi 0
> .H 1 A
> .P
> Now is the time for all good men to come to the aid of their party.
> .H 2 B
> .P
> Now is the time for all good men to come to the aid of their party.
>
> Groff produces output in which the section headers are ove
On Wed, Aug 27, 2014 at 09:33:46AM +0100, Ralph Corderoy wrote:
> Werner's said he's in favour of this approach. I'd just wonder if the
> option of providing a timestamp in the environment variable would also
> be useful.
I guess I would have to wonder why having the timestamp there is very
usefu
Ralph Corderoy wrote:
> I'd still say give it a try. Perhaps where it is, say, Plan 9-troff
> specific, mention that in the subject. We've lost the benefits of
> Usenet readers like trn, but some of us might have mailer's with `kill'
> files. :-)
Well, I agree with that: let's try, and take an
Hello alls,
I'm forwarding this discussion to the list. Comments are
welcome :)
Carsten Kunze wrote:
> on generating the documents under doc/just, doc/troff etc.
> a lot of errors regarding missing fonts are reported. I
> had always ignored these messages. I think that Gunnar
> had a lot more
> I'd say older is better. :-) Can you be any more specific about the
> versions? That would help narrow down changes that might have caused
> the problem.
I can confirm the bug. But it's not mm.tmac that has changed,
so it must be something in troff itself (somewhere between
versions 1.21 an
>> I rather suggest to provide this as a configuration option so that
>> builds that need this functionality can access it.
>
> OK. If it's an environment variable then this comes for free by
> just setting that variable. How about the attached patch?
Basically, it looks good. However, I'm no
> Werner's said he's in favour of this approach. I'd just wonder if
> the option of providing a timestamp in the environment variable
> would also be useful. [...]
Providing a time stamp manually is a good idea, but IMHO this even
more points to command line option instead of an environment var
groff --version returns 1.22.2
Having said that, however, it is probably a git version I built at some
point. I suggest that non-release versions of groff should display the GIT
revision number in addition to the version number in order to remove all
ambiguities. I've suggested this to several o
On Wed, Aug 27, 2014 at 03:56:24PM +0200, Werner LEMBERG wrote:
> ... However, I'm not convinced that I want to
> *always* suppress timestamps (and a setting in a user's environment is
> more or less permanent). Instead, I prefer good old command line
> options to control this behaviour.
If time
Hi Tadziu,
> I can confirm the bug. But it's not mm.tmac that has changed,
> so it must be something in troff itself (somewhere between
> versions 1.21 and 1.22.2).
Well, if I've done it right, `git bisect' is saying it went wrong with
http://git.savannah.gnu.org/cgit/groff.git/commit?id=d32e328
> I suggest that non-release versions of groff should display the GIT
> revision number in addition to the version number in order to remove
> all ambiguities. I've suggested this to several other packages who
> have agreed making debugging a lot easier.
We essentially get this for free as soon
> I can confirm the bug. But it's not mm.tmac that has changed,
Well, this is embarrassing. Of course mm.tmac has not changed,
it simply refers to m.tmac, which has indeed changed.
It's the (new) block starting "wrapper to cancel the side effect"
which causes the problem.
So troff is actually
Using private, non-standard, or not-included fonts to document the package
with the fonts makes utterly no sense. The documents should be changed to
use included or standard fonts only. This will avoid every new user from
questioning their build or the package itself. If included or standard
fon
> Using private, non-standard, or not-included fonts to document the package
> with the fonts makes utterly no sense. The documents should be changed to
> use included or standard fonts only. This will avoid every new user from
> questioning their build or the package itself. If included or stan
Blake McBride wrote:
> The documents should be changed to use included or
> standard fonts only.
For the troff documentation I agree, we should use the
default font.
> If included or standard fonts are not good enough - take
> that up with X11 et al.
That's the case of the other documents, whic
On Wed, Aug 27, 2014 at 2:25 PM, Pierre-Jean wrote:
> Blake McBride wrote:
>
> > The documents should be changed to use included or
> > standard fonts only.
>
> For the troff documentation I agree, we should use the
> default font.
>
> > If included or standard fonts are not good enough - take
>
> > Using private, non-standard, or not-included fonts to
> > document the package with the fonts makes utterly no sense.
> I agree and I can't understand Gunnar here.
I think it's perfectly understandable. It's an advertising
document, intended to show off the capabilities of the program.
*Of
> > > Using private, non-standard, or not-included fonts to
> > > document the package with the fonts makes utterly no sense.
>
> > I agree and I can't understand Gunnar here.
>
> I think it's perfectly understandable. It's an advertising
> document, intended to show off the capabilities of the
`gpinyin' can now be used. But `grog' has still to be enhanced and more
examples should be added.
Bernd Warken
> For the troff doc (from J. Osanna and BWK) I would suggest
> the traditional standard fonts. For the other documents
> Pierre-Jean has an idea for a replacement. Don't you agree
> with his proposal?
My point was that for someone simply downloading the sources
to install the program it is not
Groff is open source. A conscientious author will strive
to make source--the whole source including documentation--as
easily portable as possible. Documentation created in the back
room and distributed only in PDF is the antithesis of open.
I hope "Linux Libertine" is a joke that I don't happen
> Groff is open source. A conscientious author will strive
> to make source--the whole source including documentation--as
> easily portable as possible. Documentation created in the back
> room and distributed only in PDF is the antithesis of open.
I fully agree!
(Although this discussion not tou
On Wed, 27 Aug 2014 18:04:27 -0400
Doug McIlroy wrote:
> Groff is open source. A conscientious author will strive
> to make source--the whole source including documentation--as
> easily portable as possible. Documentation created in the back
> room and distributed only in PDF is the antithesis of
> Possibly someone forgot to look up "libertine" in the
> dictionary?
Wikipedia defines libertine as "one devoid of most moral
restraints, which are seen as unnecessary or undesirable".
Isn't that the epitome of "open"?
On Wed, Aug 27, 2014, Pierre-Jean wrote:
> Ralph Corderoy wrote:
>
> > I'd still say give it a try. Perhaps where it is, say, Plan 9-troff
> > specific, mention that in the subject. We've lost the benefits of
> > Usenet readers like trn, but some of us might have mailer's with `kill'
> > files.
Hi Werner,
Werner LEMBERG wrote on Wed, Aug 27, 2014 at 03:56:24PM +0200:
>>> I rather suggest to provide this as a configuration option so
>>> that builds that need this functionality can access it.
>> OK. If it's an environment variable then this comes for free by
>> just setting that variabl
I tried reversing out the changes in that git revision and it fixed the
problem. I do not know how to change it so that the fix that patch was
intended for and the correct functionality still works correctly. Can
someone help with this?
Thanks!
Blake
On Wed, Aug 27, 2014 at 9:57 AM, Ralph Cor
Greetings,
If I process the following MM document:
Hello
with: troff -mm file.mm |dpost >file.ps
file.ps has (in addition to what you would expect) two dashes in the upper
left of the page, and two dashes in the top right of the page.
groff -mm file.mm >file.ps
works correctly (without 4 ext
>> I hope "Linux Libertine" is a joke that I don't happen to
>> understand.
>
> Linux Libertine is the name of a free/open typeface. Whether the
> name was a deliberate joke or not I do not know. Possibly someone
> forgot to look up "libertine" in the dictionary?
Mhmm. According to my diction
>> Basically, it looks good. However, I'm not convinced that I want
>> to *always* suppress timestamps (and a setting in a user's
>> environment is more or less permanent). Instead, I prefer good old
>> command line options to control this behaviour.
>
> I'd prefer if groff would never write "C
> Given MM input text:
>
> .nr Hb 0
> .nr Hs 0
> .nr Hi 0
> .H 1 A
> .P
> Now is the time for all good men to come to the aid of their party.
> .H 2 B
> .P
> Now is the time for all good men to come to the aid of their party.
>
>
> Groff produces output in which the section
34 matches
Mail list logo
