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
> I just published the new groff preprocessor `gperl'. It allows to
> add Perl code to groff files.
Nice! And thanks for the contribution.
Werner
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 just published the new groff preprocessor `gperl'. It allows to add
Perl code to groff files.
That makes available easy mathematical calculations, the famous Perl
regular expressions, and much more.
The result can be stored in a roff string or register variable. This
result is obtained from t
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
Being away from home with a mere netbook, I can't really
read Eric's and Peter's insightful remarks in detail. I
need to get back to a printer before doing them justice.
Presentation--at least page size and ease of flipping
pages--matters very much. "Semantics only" is pie in the
sky.
Consider pr
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
19 matches
Mail list logo
