Re: ASCII back end

[Basile STARYNKEVITCH]

>#   From: Jeff Kingston <address@hidden>, address@hidden
>#   Subject: ASCII back end
>#   To: address@hidden
>#   Old-Return-Path: <address@hidden>
>#   X-Mailing-List: <address@hidden> archive/latest/77
>#   X-Loop: address@hidden
>#   X-Lines: 24
>#   
>#   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.
>#   
  <<skipped>>

>#   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.
>#   
>#   Jeff Kingston
>#   

Maybe i would add a related wish for Lout : support for non PostScript printers.

More specifically, i believe that Lout output generation is modular; so
I would want at least a small documentation about Lout internal
implementation (ie the z01.c to z36.c files --- why so meaningless
names?).

Lout PostScript output seems to contains mostly stuff like

at coordinates x,y in font f show string s

(actually this seems to be done in several PostScript commands, one for
setting the font, another for moving, a third for showing strings).

I believe that most today's laser printers can accept such commands. So
i hope that lout should be easily portable to any printer having
scalable fonts (eg HPPCL-5 of cheap HP-Laser4L printers, CAPSL 5 of
cheap Canon printers, or an X11 or even dumb-Ansi-terminal based
previewer). Of course, it is possible today to print PostScript on such
printers with ghostscript, but it is much heavier than generating
specific commands for them.


If lout internal structure was documented, and if lout is modularily
written, i expect that it would be easy to add into lout specific
output drivers (i really would want drivers to be subprogram or
modules, not a separate Unix process such as dvi2ps; i really like lout
to be only one process, generating directly printable output) for non
PostScript output. Of course the @Graphic primitive won't work as
easily. Perhaps this primitive could be redesigned around or completed
by lower level graphic primitives (such as line stroke, polygon stroke,
polygon fill)? Several usages of  @Graphic (eg in dl or eq packages)
are just for line stroking, so it might be interesting to add
@LineStroke, @PolygonStroke, @PolygonFill as Lout primitives.


I also understand quite well that Jeff Kingston have a lot of more
important things to do, so probably this wish will remain just a wish.
I did look inside Lout implementation a little bit but did not fully
understand it. I'm not yet a Lout expert (ie i can't rewrite a
DocumentLayout package from scratch), just a satisfied Lout user.

Basile STARYNKEVITCH   ----  Commissariat a l Energie Atomique
DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France
fax: (33) 1- 69.08.23.81;    phone: (33) 1- 69.08.40.66
email: address@hidden;  homephone: (33) 1- 46.65.45.53


N.B. Any opinions expressed here are solely mine, and not of my organization.
N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA.