> The natural solution for this is to split the footnote, [...]
> Does mom (or other macro packages) handle this automatically and
> correctly?
I haven't checked this with me, ms, and mm, but given that
the situation does occur more frequently than one would like,
I suspect that anyone writing a
(Ted Harding) wrote:
> Whichever way you try to output footnotes in the correct page, there
> is one situation which will cause problems.
>
> Namely, the in-text reference to the footnote is in what would (say)
> be printed as the last line but three on the page (i.e. 4th line from
> the bottom).
On Sat, Mar 08, 2014, Ted Harding wrote:
> Whichever way you try to output footnotes in the correct page, there
> is one situation which will cause problems.
>
> Namely, the in-text reference to the footnote is in what would (say)
> be printed as the last line but three on the page (i.e. 4th line
[see at end]
On 08-Mar-2014 19:23:18 Peter Schaffter wrote:
> On Sat, Mar 08, 2014, Pierre-Jean wrote:
>> Peter Schaffter wrote:
>>
>> [ about heirloom troff paragraph at once adjustment ]
>>
>> > > I believe that Groff will face this kind of problems.
>> >
>> > FWIW, the mom macros solved this
On Sat, Mar 08, 2014, Pierre-Jean wrote:
> Peter Schaffter wrote:
>
> [ about heirloom troff paragraph at once adjustment ]
>
> > > I believe that Groff will face this kind of problems.
> >
> > FWIW, the mom macros solved this thorny some time ago. I won't
> > say it was easy--I still recall th
Peter Schaffter wrote:
[ about heirloom troff paragraph at once adjustment ]
> > I believe that Groff will face this kind of problems.
>
> FWIW, the mom macros solved this thorny some time ago. I won't
> say it was easy--I still recall the hair-pulling six weeks I spent
> getting it right. And
On Tue, Feb 25, 2014, Pierre-Jean wrote:
> But, to effectively use the paragraph at once adjustment, one
> need to patch the macro sets (or create some new ones).
> Because of the architecture of troff, things are done this
> way:
> - when troff format the paragraph at once, it also
> deal with d
Hi Ingo,
> There is also an updated version by Gunnar Ritter, 15 years younger,
> i.e. from 2007: http://heirloom.sourceforge.net/doctools/troff.pdf
Interesting.
> The Plan 9 troff(1) manual cites:
>
> B. W. Kernighan, ``A TROFF Tutorial'', Unix Research System
> Programmer's Manual, Te
Tadziu Hoffmann wrote (Wed, 26 Feb 2014
23:06:17 +0100):
>
> > Three browsers, three layouts (surf uses webkit).
>
> Hmmm, well, I suspect if you used groff with -Tlatin1, -Tlj4,
> -Tdvi, and -Tps you might also get four different layouts...
> Simply consider different browsers like different d
Hi Federico,
Ralph Corderoy wrote on Sat, Mar 01, 2014 at 11:29:08AM +:
> Federico wrote:
>> While we are (slightly) digressing, may I ask the broader group, what
>> are the best current tutorials for Groff?
>>
>> Most of the material I know of is... rather dated. Not necessarily
>> bad, but
On Sat 01 Mar 2014 11:29:08 Ralph Corderoy wrote:
> Then there's Dale Dougherty and Tim O'Reilly's _Unix Text Processing_.
> http://home.windstream.net/kollar/utp/ Given they were using troff to
> produce their books, and continued to use groff for a long time to do
> the production even when they
Hi Federico,
> While we are (slightly) digressing, may I ask the broader group, what
> are the best current tutorials for Groff?
>
> Most of the material I know of is... rather dated. Not necessarily
> bad, but not very recent either - and not very concise, either. What
> do you point to get new
On Tue 25 Feb 2014 13:24:15 Eric S. Raymond wrote:
> No, no, *no*. PDF on the Web is evil and must die.
>
> Here's why. It breaks the flatness of URL-space. HTML documents can
point
> at PDFs, but not *into* PDFs.
I get slightly different results.
If I use the url:-
http://chuzzlewit.co.uk/
This is the primary use case for us as well [ typesetting backend ] though
I do write other reports by hand using groff as well. For my needs the
macros are easy to type, remember and produce pretty great looking reports.
On Thu, Feb 27, 2014 at 4:28 PM, Tethys wrote:
>
> Deri James writes:
>
On 02/27/2014 05:28 PM, Tethys wrote:
Deri James writes:
I firmly believe that groff doesn't necessarily need to change to stay
relevant (arguably, it hasn't been relevant to the majority for some time
anyway). Yes, separation of presentation from content is important. But
does it need to be
Deri James writes:
>I have, so far, kept silent on future direction for groff, since my
>own use for groff is probably very rare, so my opinion should not
>carry much weight. I use groff as a typesetting engine called from a
>front end which produces a troff file which is then passed to groff to
> 1. In the sixties and seventies, computing was largely
> experimental. There were no penalties for trying
> something different.
It's the natural evolution of everything. In the beginning trying
different approaches is sane and has sense.
But to make a graphical version of what is al
> My first reaction was to wonder why not simply have a
> commandline driving graphical output in another window.
> But I see your point about having a history connecting
> commands to the output. I'm just not sure how often I
> would actually need that.
Have you ever used Mathematica? The Math
Charlie Kester :
> Disagree with your assertion that ncurses-based apps are dead or dying.
> For example, there are a lot of people using mutt for email and the
> non-GUI version of vim for general text editing, and these (and many
> other ncurses apps) are actively maintained.
I concur with this
On Wed 26 Feb 2014 at 19:55:31 PST James K. Lowden wrote:
Luckily, the terminal is also the solution. Or, rather, a different
terminal would be. I call it VT-roff:
http://www.schemamania.org/troff/vt-roff.pdf
Interesting article. Thanks for sharing it.
My first reaction was to won
> I submit to you that if our command-line environment weren't
> still using 1980s technology to emulate 1970s hardware, we
> would have more graphical and unified documentation.
I think two factors are responsible for that:
1. In the sixties and seventies, computing was largely
experimenta
On Wed, Feb 26, 2014 at 10:55:31PM -0500, James K. Lowden wrote:
> On Wed, 26 Feb 2014 11:46:32 +
> Ralph Corderoy wrote:
>
man pages don't really need expressive typography.
>>>
>>> Man pages are constrained by xterm. A better display system would
>>> invite tables, graphs, equations, a
On Wed, 26 Feb 2014 11:46:32 +
Ralph Corderoy wrote:
> > > man pages don't really need expressive typography.
> >
> > Man pages are constrained by xterm. A better display system would
> > invite tables, graphs, equations, and links.
>
> I don't think they are. Or they didn't used to b
While we are (slightly) digressing, may I ask the broader group, what are the
best current tutorials for Groff?
Most of the material I know of is… rather dated. Not necessarily bad, but not
very recent either - and not very concise, either. What do you point to get
new users started? What’s th
> Three browsers, three layouts (surf uses webkit).
Hmmm, well, I suspect if you used groff with -Tlatin1, -Tlj4,
-Tdvi, and -Tps you might also get four different layouts...
Simply consider different browsers like different devices.
> Firefox's is perfect!
It's better than the others, but I w
On Feb 26, 2014, at 8:19 AM, Ralph Corderoy wrote:
> Hi Walter,
>
>> Man pages are not tutorials or complete manuals
>
> Yes they are, or should be. They used to be. I learnt Perl 4 from
> perl(1). Back then it was a single long man page, well-written by an
> experienced Unix hand, Larry Wa
No, despite the Typos. Three browsers, three layouts (surf uses
webkit). Firefox's is perfect!
Holger
"Eric S. Raymond" wrote (Wed, 26 Feb 2014 10:42:52
-0500):
> hoh...@arcor.de :
> > > Some years ago I enhanced geqn so it can emit MathML.
> >
> > What did I wrong?
>
> To emit MathXML get
On Wed, Feb 26, 2014 at 01:19:14PM +, Ralph Corderoy wrote:
> Hi Walter,
>
>> Man pages are not tutorials or complete manuals
>
> Yes they are, or should be. They used to be. I learnt Perl 4 from
> perl(1). Back then it was a single long man page, well-written by an
> experienced Unix hand,
On Wed, Feb 26, 2014 at 04:08:45PM +, Deri James wrote:
>>On Wed 26 Feb 2014 10:19:07 Mike Bianchi wrote:
>>> I cannot find  man.config  or any reference to it in Debian 7.4
>>(wheezy).
>It looks like on debian the answer is to create a shell script called
>"mandb_tfmt"
On Wed 26 Feb 2014 10:19:07 Mike Bianchi wrote:
> I cannot find man.config or any reference to it in Debian 7.4 (wheezy).
> 2.6.2 2012-06-18 MAN(1)
> Only manpath.config .
>
> What am I missing?
>
> --
> Mike Bianchi
> Foveal Systems
>
> 973 822-2085
It looks like on debian t
hoh...@arcor.de :
> > Some years ago I enhanced geqn so it can emit MathML.
>
> What did I wrong?
To emit MathXML getqn needs an option that is not suppliued by the normal
groff pipeline.
--
http://www.catb.org/~esr/";>Eric S. Raymond
Hi Mike,
> > It may be necessary to alter the man.config command I gave for other
> > pdf readers.
>
> I cannot find man.config or any reference to it in Debian 7.4
> (wheezy).
> 2.6.2 2012-06-18 MAN(1)
> Only manpath.config .
>
> What am I missing?
Perhaps Deri's using BSD.
http:/
On 02/25/2014 11:59 PM, Volker Wolfram wrote:
Hi all groffers,
in fact I'm a newbie on groff tools and macros. But these tools are the BEST
I've used EVER. I enjoy groff so much, I've developed my
own three side perspective CAD macro to made my needs. And a macro for
electrical and pipe sche
On Wed, Feb 26, 2014 at 02:42:45PM +, Deri James wrote:
> :
> It may be necessary to alter the man.config command I gave for
> other pdf readers.
I cannot find man.config or any reference to it in Debian 7.4 (wheezy).
2.6.2 2012-06-18 MAN(1)
Only manpath.config .
What am
On 02/26/2014 06:33 AM, Tadziu Hoffmann wrote:
Man pages are not tutorials or complete manuals
Yes they are, or should be. They used to be.
Fairly complete manuals, yes; tutorials, I don't think they
ever were. The manual page for the fortran compiler says what
the compiler options are
"Eric S. Raymond" wrote (Wed, 26 Feb 2014 08:29:00
-0500):
> hoh...@arcor.de :
> > I don't got to what extend the support of web/ html features shall
> > be supported -- catchword: use case. For instance, will eqn code be
> > traversed to MathJax?
>
> Some years ago I enhanced geqn so it can e
On Wed 26 Feb 2014 13:46:22 Walter Alejandro Iglesias wrote:
> What do you want in a man page? Videos? 3D holograms?
Only if they would help give an answer to the question you are trying to
answer!
> XTerm does not constrain nothing. It does what is expected from a
terminal.
> Do you think y
Hi Tadziu,
> > > Man pages are not tutorials or complete manuals
> >
> > Yes they are, or should be. They used to be.
>
> Fairly complete manuals, yes; tutorials, I don't think they ever
> were.
Yes, I was referring only to the "complete manuals" bit. Thanks for
pointing out my ambiguity. I
> > Man pages are not tutorials or complete manuals
>
> Yes they are, or should be. They used to be.
Fairly complete manuals, yes; tutorials, I don't think they
ever were. The manual page for the fortran compiler says what
the compiler options are -- it does not teach you programming
in fortr
Volker Wolfram wrote:
|Hi all groffers,
|
|in fact I'm a newbie on groff tools and macros. But these \
|tools are the BEST I've used EVER. I enjoy groff so much, I've developed my
I fully agree -- after almost going stony because of loosing
system content _and_ the backups (forgotten PGP pass
hoh...@arcor.de :
> I don't got to what extend the support of web/ html features shall be
> supported -- catchword: use case. For instance, will eqn code be
> traversed to MathJax?
Some years ago I enhanced geqn so it can emit MathML.
--
http://www.catb.org/~esr/";>Eric S. Raymond
Hi Walter,
> Man pages are not tutorials or complete manuals
Yes they are, or should be. They used to be. I learnt Perl 4 from
perl(1). Back then it was a single long man page, well-written by an
experienced Unix hand, Larry Wall. I learnt ed and sed the same way
many years before that. And
On Wed, Feb 26, 2014 at 12:00:53PM +, Deri James wrote:
> On Wed 26 Feb 2014 11:46:32 Ralph Corderoy wrote:
>> Hi jkl,
>>
man pages don't really need expressive typography.
>>>
>>> Man pages are constrained by xterm. A better display system would
>>> invite tables, graphs, equations, and
On Wed 26 Feb 2014 11:46:32 Ralph Corderoy wrote:
> Hi jkl,
>
> > > man pages don't really need expressive typography.
> >
> > Man pages are constrained by xterm. A better display system would
> > invite tables, graphs, equations, and links.
>
> I don't think they are. Or they didn't used to b
Hi jkl,
> > man pages don't really need expressive typography.
>
> Man pages are constrained by xterm. A better display system would
> invite tables, graphs, equations, and links.
I don't think they are. Or they didn't used to be. It was common to
see man pages with `.if n' and `.if t', w
Hi Eric,
> Peter wrote:
> > I think what happened is that, over time, near-exclusive use of the
> > PostScript driver caused many of us to confuse groff output with
> > grops output--if not intellectually, at least at the conceptual
> > level. We began to think of groff as a PostScript typesettin
Volker Wolfram wrote (Wed, 26 Feb 2014
07:59:35 +0100):
> And as a newbie I don't know about the code and design of groff. But
> I've changed from LaTeX to groff because it is simple and easy to
> understand.
+1
Using Groff features a learning curve with raising success.
> And that is very cool
I don't got to what extend the support of web/ html features shall be
supported -- catchword: use case. For instance, will eqn code be
traversed to MathJax?
Holger
Hi all groffers,
in fact I'm a newbie on groff tools and macros. But these tools are the BEST
I've used EVER. I enjoy groff so much, I've developed my
own three side perspective CAD macro to made my needs. And a macro for
electrical and pipe scheme. And there so much ideas in mind to
make more w
James K. Lowden :
> > man pages don't really need expressive typography.
>
> Man pages are constrained by xterm. A better display system would
> invite tables, graphs, equations, and links.
Yes, but we don't have that. If and when we do, it seems certain at
this point to be founded on some
On Tue, 25 Feb 2014 11:06:09 -0500
"Eric S. Raymond" wrote:
> More precisely, it is not the presence of presentation-level requests
> from the year zero that makes groff-as-it-is unfit to play in the
> semantic-markup world, it is the fact that macro packages presently
> *cannot disable access to
I have, so far, kept silent on future direction for groff, since my own use for
groff is probably very rare, so my opinion should not carry much weight. I
use groff as a typesetting engine called from a front end which produces a
troff file which is then passed to groff to produce output. The tr
Hello Peter,
Hello groffers,
Peter Schaffter wrote:
> For example, groff's line-at-a-time approach to
> formatting, if unchanged, will remain an impediment to high quality
> typesetting and ensure groff's demise for anything other than
> writing manpages.
It already is an impediment to high qu
On Tue, Feb 25, 2014 at 01:24:15PM -0500, Eric S. Raymond wrote:
> Walter Alejandro Iglesias :
>> Assuming you have not enough time to do it yourself, what I would do
>> in your place is to pay someone to write the html of your site and
>> replace DocBook with PHP scripting.
>
> There are about fou
Walter Alejandro Iglesias :
> Assuming you have not enough time to do it yourself, what I would do
> in your place is to pay someone to write the html of your site and
> replace DocBook with PHP scripting.
There are about fourteen million reasons that would be a terrible idea.
I'm not going to arg
On Tue, Feb 25, 2014 at 11:06:09AM -0500, Eric S. Raymond wrote:
> Now let us imaging adding two primitives to groff:
>
> 1. Declare hygienic. Takes a request or macro name, sets a 'hygienic'
> bit on it.
>
> 2. Enable hygienic node. After this point, all explicit requests without
> their hygieni
Ingo Schwarze :
> You see, mom(7) is not the only example of a roff macro set supporting
> the transformation you describe. There is also mdoc(7). The
> metadata part is short (just Dd Dt Os Sh NAME Nm Nd), stylesheet
> information is not usually included but kept in a separate file
> because you
Peter Schaffter :
> I'm afraid this will be a long post. Sorry, but I don't see any way
> around it.
I found this a very worthwhile read. You raised deep issues that required
thought and development. In this reply I will offer some responses that
I hope are as substantive.
Some weeks ago expla
Hi Peter,
Peter Schaffter wrote on Mon, Feb 24, 2014 at 09:59:43PM -0500:
[... snipped many interesting thoughts, in particular regarding
the question where the problems do *not* lie ...]
> As for xml output, I'm convinced that's a source file, macro level
> issue. The mom macros point the
I have more to say.
I'm an immigrant. After burying my family and my country I came alone to
Europe 13 years ago with my skin and money enough to survive two weeks. After
twenty years like a professional cellist I leave the music. Do you still think
that I could be afraid of changes?
Groff alr
> The thing I fear is when .glurp arg1 arg2 changes to .glurp arg2
> arg1 , etc. (I cringe when I watch other languages, Ruby comes to
> mind, make this mistake. Code, written to the spec, that used to
> work now doesn't?!)
In case someone steps forward and implements an improved syntax
(whatev
On Mon, Feb 24, 2014 at 09:59:43PM -0500, Peter Schaffter wrote:
> Mike Bianchi summed up the backward compatibility concern best:
> :
> "So no, do not break groff by 'modernizing' it."
Just to be clear, my opinion is that the _vast_ majority of changes from legacy
*roff to groff have been
Hi Peter,
> I'm afraid this will be a long post. Sorry, but I don't see any way
> around it.
Thanks for the interesting and well-considered read. Much food for
thought.
Cheers, Ralph.
On Mon, Feb 24, 2014 at 09:59:43PM -0500, Peter Schaffter wrote:
> I'm afraid this will be a long post. Sorry, but I don't see any way
> around it.
>
> It's ironic and instructive that the thread, "Future direction of
> groff", which became a semantic-vs-presentational debate eerily
> similar to a
I'm afraid this will be a long post. Sorry, but I don't see any way
around it.
It's ironic and instructive that the thread, "Future direction of
groff", which became a semantic-vs-presentational debate eerily
similar to a previous discussion on the same subject, originated
in the "space-width" th
65 matches
Mail list logo
