[Top][All Lists]

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

Re: ASCII back end

From: Lar Kaufman
Subject: Re: ASCII back end
Date: Thu, 11 Nov 93 16:55:00 -0500

> Well, in view of all the interest, looks like an ASCII back end
> has to go on my list of things to do.  I don't think it's feasible
> though to have the ASCII version having the same page breaks as the
> PostScript version, especially if @Bullet becomes <bl> and so on.
> Actually making sure that @Bullet comes out as <bl> is quite easy,
> it just means changing the definition of @Bullet in DocumentLayout,
> which package would clearly need to be duplicated anyway.

My usage of "gtroff -a" meets a very specific, albeit
narrow, need: I can produce ASCII book files that can be
used by blind readers, which correspond page-for-page with
our published books.  This allows a blind reader to have a
book, say for a computer course, which they can use with
confidence and discuss with sighted readers, since there is
a page-for-page correspondence.  (I can provide valid ASCII
translations of the index files!) Originally, I used a page
layout for the ASCII output that also preserved the 
line-for-line formatting, but that caused real problems,
since I found I had a blind/deaf reader with a 24X80 braille
console who could not read any line longer than 80
characters.  I was delighted to discover that gtroff
allowed me (with a little messiness) to reformat the page
significantly while retaining page breaks corresponding to
the original book.

Just some reasoning behind one person's need for ASCII
output (and why I couldn't use lout for this purpose yet).
Of course, oddly enough, this same capability allows me
(with vivid imagination to augment my work) to login from
home using VT100 emulation and edit text that will be
formatted and printed in PostScript (ghostscript) without
recourse to printer or X terminal.

> ...
> Please don't get all excited and expectant about this.  At present
> I have absolutely no idea where I am going to get the time from to
> produce the (inevitable) next version.

No problem.  I'm just hinting that there is, and will
always be, need for character-based output.  I'm really
glad that you've decided to implement it.


reply via email to

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