Re: Big Bag o' Questions

[Valeriy E. Ushakov]

On Thu, Aug 12, 1999 at 08:37:27AM +0100, Mark Summerfield wrote:

> > (3) I want to propose that a collection of good quality freeware &
> >     shareware PostScript fonts be added to Lout, perhaps as a
> >     supplemental download package.
> 
> I'd love to see these - as a separate package, especially if a better fixed 
> width font e.g. Lucida could be included. What I'm not clear on though is 
> can you tell lout to include the fonts in the postscript so that it doesn't 
> matter if the company printing your stuff hasn't got the fonts you've used?

Lout emits %%IncludeResource DSC comments for fonts that are used in
the document.  The only word of caution is that for fonts that are not
used on the first page the comment is produced in page setup, thus you
can end up with lots of requests for font inclusion.  This conserves
memory at the expense of the file size.  Unfortunately, since Lout
emits its output in one pass, this comments could not be reordered and
stuffed into the document setup, but an unsophisticated shell or perl
script will do it just fine.


> > (7) Here's another feature request, if this isn't already possible...
> >     It would be nice to have a text "wrap-around" feature for small
> >     figures and tables, perhaps as a new value for the @Location
> >     parameter.  The figure (or table) would then be set alongside the
> >     current paragraph -- hugging either the left or right margin
> >     according to the user's choice -- with the text wrapping around
> >     it.  I'm referring to something like the DropCap feature, only
> >     much more flexible.
> 
> Couldn't this be achieved, with a table?

As I wrote, this could be done in a limited way using horizontal
galleys.  I'll post a separate detailed message about this as time
permits.


> Personally I'd love to see HTML and XML as supported back-ends...

HTML and XML are *not* page description languages (PDL).

<digression>
It would be nice to restructure Lout internals to used
unified and well defined backend interface instead of the present mesh
of switches.  I looked briefly through the relevant code and the
changes seems to be necessary only for z24.c (the printer) that will
basicly change

Calls to fun(), where

   fun() {
      switch (backend) {
         case text:
         case ps:
         case pdf:
      }
   }

with

   struct backend *backend;
   backend->fun();


Originally Lout only supported PS, but plain text and later PDF were
retrofitted into existing code base without much rewriting.  But the
switch to the explicit backend interface should be rather painless.

It would be nice to test the new backend interface by developing a new
backend, but we already almost run out of popular PDL ;-).  But the
other day It occured to me that Java2D could be a cute choice for this
test.  A page description will be written as a Java source code for
the class that images the page.  Document setup will simply collects
the pages together and prologue will be a set of auxilary classes that
provide the necessary infrastructure.

It's not terribly useful, but using @Diag to compile contrain based
Lout description of an illustration into Java code that draws it
(instead of writing imperative code manually) would be a "real-world"
application.  Though this poses a question of trnaslating the left
paramter to @Graphics into target's code (Java2D in this case; ther
other backend that needs this is PDF).

After looking around, there's a small PostScript interpreted called
TPS, that has the execution engine but no graphics engine.  It seems
like a much smalled code base than GhostScript.  It could be possible
to plug TPS into Lout to perform the flattening/distillation necessary
for PDF (in fact even for PS flattening may be desired as anyone who
printed complex @Diag's on PS printers might have already learned).

TPS has ability to save/restore state of the interpreter which is a
really important feature, becuase after prolog and setup are
interpreted the state could be saved and then restored at the
beginning of every page, thus enforcing the page independence.
</digression>

SY, Uwe
-- 
address@hidden                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen