groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Typesetting Software


From: Joerg van den Hoff
Subject: Re: [Groff] Typesetting Software
Date: Thu, 4 Jun 2009 11:07:09 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Jun 03 2009 (Wed, 20:57), Tadziu Hoffmann wrote:
> 
> One thing that hasn't been mentioned yet: creating
> nontrivial tables with tbl+roff is *much* easier than
> with LaTeX (in part thanks to tbl's "n" (numeric) format
> specifier).
> 
> 
> > groff is a single pass formatter, LaTeX is multi-pass.
> 
> Not sure what you mean by this, but groff and TeX are
> pretty much the same in this regard.  Both are single-pass
> formatters, in the sense that the programs do only one pass
> over the document when executed, and both require multiple
> invocations to enable forward references at all.  However,
> macro packages differ in strategy and ease of use regarding
> the resolution of references.

I meant: the functionality is in place. you call latex a few times
on the same document and than you get the correctly formatted document.
(the necessary information seemingly stored in aux files or whatever --
I really don't know latex well). with groff this sure does not work this
way. if there is a smart way I don't know it. I usually start to use
several small shell scripts to get the job done. even a trivial thing
seems not _that_ straightforward: getting the table of content to the
front. I actually cut+paste the .dit file via a 'awk' script at the end
of my processing pipeline. I don't feel that all this is as easy with
groff as with latex.

> 
> 
> > things like forward page references ("cf. section 5,
> > page 10") are easy in LaTeX whereas in groff you have to
> > intervene (forcing multiple passes and using some tricks)
> 
> LaTeX also uses multiple passes (you just call the program
> twice; however, while you're editing/compiling/viewing,
> you normally have the references from a previous run already
> available, so unless you make major changes during one cycle,
> one pass is usually sufficient).  Furthermore, there is no
> reason not to implement the same strategy that LaTeX uses
> in your groff macro package, giving you the same ease of use
> that LaTeX users enjoy.

might well be. if so it would be _very_ nice to have the functionality
integrated in the distribution. my point was: you can do all this in
latex out of the box, while in groff you can't.

> 
> 
> > Formatting directives in LaTeX are much more verbose. If
> > you really have to type all that stuff (instead of using
> > editor shortcuts or what else) it gets in the way a bit.
> 
> I don't think this is really an issue.  I find that when
> working on a document, only 10% of the time is actually taken
> up by text entry, 90% consists of editing already-entered text
> (and shifting stuff around etc.), and most of this editing
> regards the text proper, not the formatting.  Thus I would
> say that learning to use your text editor efficiently will
> benefit you much more than saving a couple of keystrokes
> on a markup tag.

agreed: not really an issue (one way or another) 

> 
> 
> > I believe a standard LaTeX install amounts to a few
> > hundred MB, groff comes in at maybe 10-20 MB (?) or
> > something like that.
> 
> This also isn't an issue.  Those hundred megabytes also give
> you lots more functionality, and you don't have to do a full
> install if you don't need it.  Also, it's irrelevant when

it's not the disk space. for me it's an indication (not proof) of 
unreasonable complexity for the task at hand. it's not important but 
I simply wanted to mention it. and there _are_ old machines with small
disks around, still.

> you consider that a modern operating system installation uses
> several gigabytes.  (Windows, anyone?  Or should we say,
> "DOS is much better than Windows because it fits onto a
> single floppy disk.")

one could contemplate the latter a while :-)

> 
> 
> > using 'pdflatex' on the other hand allows  to keep
> > everything as pdf. that's nicer.
> 
> PDF sucks.  It's not programmable, and mostly impossible to

I don't know enough about PDF to really judge this assessment.
but certainly I've never wanted to 'programm in postscript'. I prefer a bit 
more 
high level languages...

> write and edit by hand.

which I personally don't want to do anyway. 

> 
> 
> > there is a third candidate: 'lout' (there is a wikipedia
> > entry), which has quite some nice ideas, but it seems
> > to have at least some sub-optimal settings regarding
> > hyphenation thresholds which frequently squeezes too
> > much text in a line according to my taste.
> 
> I'm glad you mention lout.  I've always wanted to try it
> out, but I haven't yet been able to force myself to actually
> do it.  I think it's rather unfortunate that we don't have
> more experimental text-formatters which implement new ideas
> (provided new ideas exist at all).  Sure, you'll be mostly
> reinventing the wheel, but what's wrong with that?  People
> waste lots of time implementing much less useful programs.

the (single) author of 'lout' seems to be already on another formatter
project... 

but from what you said concerning PDF I presume you'll like at least the
decision for a sole postscript output device in 'lout' so quite some
postscript functionality seems accessible from within lout. to me it's
a very "tidy" system, well structured and user friendly. when I played
around a bit with it my only real issue was the at times much to tight
inter-word spacing in the formatted output which seemingly results from
certain decisions in the hyphenation algorithm (which is lifted from
TeX, actually). otherwise everything is there: tables, equations,
graphics/diagramms, cross references, indexing, etc.


> 
> Perhaps after writing a groff macro package, maybe I should
> write my own text formatter...

let the list know :-) 

> 
> 
> > last  not  least: groff can produce reasonably formatting
> > of ASCII documents.
> 
> Yes, this is a feature where *roff probably is without rival.
> 
> (Unfortunately, it seems to have gone out of fashion to
> produce quality documentation in "man" format (the main
> use of this feature), so it currently isn't even used to
> its full potential.)
> 
> 
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]