lout-users
[Top][All Lists]
Advanced

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

LaTeX discussion [was Re: General discussion]


From: Chris Herborth
Subject: LaTeX discussion [was Re: General discussion]
Date: Wed, 21 Jan 1998 13:16:28 -0500

Previously, Jerzy Karczmarczuk (address@hidden) writes:
[... lots of valid criticism and discussion from a TeX veteran ...]

> There are *not* too many naive and simple questions on this list. If somebody
> asks for a comparison between TeX and Lout, it remains unanswered. This is
> bad, as "spreading the gospel" means to compare the darker outside with the
> internal light. 

This is one thing that I've wanted; a good Lout vs TeX, Lout vs LaTeX
discussion... not an advocacy contest, a real discussion about their
strengths and weaknesses.

My personal goal in investigating Lout is to replace a rickety LaTeX
document processing system that we've cobbled together here (QNX
Software Systems).  LaTeX is downright _evil_ when you need to define
your own document format... which, obviously, we need to do since we
want our documents to look like _our_ documents.

> There are sometimes some touchy points in the discussion. Somebody wants to
> do something quickly, and confesses that he has no time to learn Lout
> thoroughly. Valeriy Ushakov responds with reproaches, saying that if the
> other wishes to use some system competently, he must master it first.
> You might say: true, isn't it? Of course. 

But, this is a big problem, at least for me.  I've had "learn enough
about Lout to evaluate it" on my TODO list for over a year now, and I
still haven't even had time to play with it a little.  Lout _looks_ like
it's got great potential for solving my problems (although memory might
be a big problem; QNX doesn't do paging to disk), but I don't know
anything about its limitations.

And so, here are a few things that we need to do with our documents; the
complexity of the Lout/LaTeX/whatever needed to generate these effects
isn't a big deal... we're coming from SGML, and generating whatever we
need to get to PostScript.

- Custom, complex document style; our books have a fairly complex
  layout... we print 7"x9" pages on normal letter paper, centered and
  with cropmarks.  The QNX book layout also features a ~2" "scholar's
  margin" along the left-hand side, with the rest for text.  Headers and
  margin notes, as well as some small graphics (for notes, cautions,
  warnings, etc.) appear in this margin, and have to align nicely with
  paragraphs and whatnot in the main text column.

  This is painful in LaTeX, and things never quite line up 100%
  properly.  Sometimes things shift around strangely, and you get note
  graphics aligned with the top edge of the note box instead of the
  first line of text in the note, or headers migrate down along the
  paragraph instead of being at the top.

  We probably would've been better off starting with plain TeX instead
  of trying to adapt the "book" document class to our own layout.

- We use an SGML table model similar to HTML's; you specify rows and
  inside the rows you specify cells.  Sometimes our tables are large,
  and have to span page boundaries.  The column widths also have to be
  dynamic based on the table contents, since I don't expect the writers
  to be trying to guess at sizes and hard-code the widths.  All this is
  extremely difficult in LaTeX... you can have one of a) spanning page
  boundaries or b) dynamicly sized columns, but to get both we had to do
  some _extensive_, painful, and buggy LaTeX hacking.

- We automatically scale images so they fit in the text column, but
  retain their aspect ratio; this is one of the few complex things we
  did with relatively little pain in LaTeX.

- Redefining the styles for similar documents (for example, filling an
  entire letter-sized page instead of the usual 7"x9" page) is brutal in
  LaTeX.  So many sizes and measurements are hard-coded, you end up
  re-writing the stylesheet completely.

- Real soon now I've got to support Unicode (hopefully UTF-8 encoding)
  so we can print Japanese documents.  There's a Japanese TeX, but as
  far as I know, you can't mix European scripts with Japanese scripts;
  there's a Unicode TeX in development, but that probably won't be in a
  usable state until about 2010...

Any thoughts on how Lout would behave in this environment?  I realise
I'll have to become an expert to implement a lot of this, but there's no
point in starting down that path if some of these things just aren't
possible.  We chose LaTeX because a proof-of-concept was finished in an
afternoon using the canned stylesheets... things got exponentially
more complex as we tried to implement our own layouts.

-- 
----------================================================----------  _
Chris Herborth, R&D Technical Writer   (address@hidden)              | \  _
QNX Software Systems, Ltd.             Arcane Dragon -==(UDIC)==-    | < /_\
http://www.qnx.com/~chrish/            DNRC Holder of Past Knowledge |_/ \_


reply via email to

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