--- Begin Message ---
|
Subject: |
Lout backend to Jade: ideas and issues. |
|
Date: |
Fri, 10 Oct 1997 19:27:09 +0400 |
As I have found a full time job that is really *full* time, I will
probably be in а deep hack mode for the next couple of months and so I
will be unable to devote any seizable amount of time to lout backend
for jade. So in this message I will try to dump everything related
to the backend, my ideas, gotchas etc... I have been engaged in email
exchange with Jeff off the jadelout list and I will quote some of his
comments here.
* Implementing flow objects
Jeff> Lout reads in everything between { ... } in one hit before
Jeff> formatting it and printing it.
Jeff> Actually, that's not quite true. If the thing enclosed is the
Jeff> right parameter of a galley, then it will read it one paragraph
Jeff> at a time, even if it's a body parameter, provided it has a
Jeff> target for it all lined up. For example, @Chapter, @Section
Jeff> etc. are read one paragraph at a time, because Lout has a target
Jeff> for those from the start. But @FootNote is read in its entirety
Jeff> because Lout can't find the footnote target until later on.
This implies that lout code that backend is to emit *must* use galleys
heavily. For example:
@Sequence
# Some parameters here
//
@SequenceContent
@Begin
# Sequence content here, ie.
@Paragraph
# Parameters ...
//
@ParagraphContent
@Begin
# paragraph content here ...
@End @ParagraphContent
# more sequence content here ...
@End @SequenceContent
* Inherited characteristics
Unfortunately we cannot leave the job of managing IC's up to Lout. To
introduce new scope to import from we have to use @Open and, as Jeff
explains in the quote above, the right parameter of @Open will be read
all at once. The following sample was a nice idea but I *rejected* it.
# The sole purpose of this definition is to introduce IC defaults
# for @Inherited. We don't even need to ever actually @Use this
# symbol. Nested definitions are preferred to named parameters as
# defaults are fixed in the standard, and this lout code
# emphasizes this fact.
export @FontSize @FontName @FirstFrontLeftHeader
def @InheritedDefaults
@Begin
def @FontSize { 10p }
def @FontName { Times Base }
def @FirstFrontLeftHeader right @PageNumber {}
# ...
# more IC defaults here
# ...
@End @InheritedDefaults
# This will introduce new IC values into newly @Open'ed scope.
import @InheritedDefaults
export @FontSize @FontName @FirstFrontLeftHeader
def @Inherited
named @FontSize { @FontSize }
named @FontName { @FontName }
named @FirstFrontLeftHeader right @PageNumber
{ @FirstFrontLeftHeader @PageNumber }
# ...
# more IC here
# ...
{}
# All symbols that implements FO than import from @Inherited
#
# import @Inherited def @Sequence ...
# import @Inherited def @SequenceContent ...
# import @Inherited def @Paragraph ...
# import @Inherited def @ParagraphContent ...
# ...
# ... in the document
# This FAILS miserably because the right parameter for @Open will
# be slurped all at once...
{ @Inherited @FontSize { 10p } } @Open {
@Sequence
# Parameters ...
//
@SequenceContent
@Begin
# Sequence content here, ie.
{ @Inherited @FontSize { 24p } } @Open {
@Paragraph
# Parameters ...
//
@ParagraphContent
@Begin
# paragraph content here ...
@End @ParagraphContent
}
# more sequence content here ...
@End @SequenceContent
}
It would be nice if @Use semantic can be extended to "to the end of
scope". The scope for top level invocation of @Use ends at the end of
input so this extension will not brake existing code. Then we would
be able to put IC values to inherit inside the right parameter to
*Content symbols:
# This code is HYPOTHETIC. @Use can be used only at top-level.
{ @Inherited @FontSize { 10p } } @Open {
@Sequence
# Parameters ...
} # <- @Open closed here. @Sequence will obey IC when formatting
# it's content (delivered by @SequenceContent)
# Can't use @Open here
//
@SequenceContent
@Begin
# Duplicate @Inherited settings here for descendants to inherit.
@Use { @Inherited @FontSize { 10p } }
# Sequence content here, ie.
{ @Inherited @FontSize { 24p } } @Open { # IC for @Paragraph to obey
@Paragraph
# Parameters ...
}
//
@ParagraphContent
@Begin
# Duplicate @Inherited settings here for descendants to inherit.
@Use { @Inherited @FontSize { 24p } }
# paragraph content here ...
@End @ParagraphContent
}
# more sequence content here ...
@End @SequenceContent
}
The following few paragraphs state obvious things which still, I
think, are important to emphasize
Inherited characteristic is just a dynamically scoped variable like
defvar'ed variables in Common Lisp. DSSSL, which is lexically scoped
Scheme otherwise, avoids explicit generic dynamic scoping by making
IC's into a separate kind of objects with special syntax for them.
New IC value can only be introduced via named arguments to
make-expression, that serves as a special case fluid-let.
Dynamic scoping is resolving free variables using the scope in effect
at the point of appearence and for Lout and for DSSSL this means
style. For a programmable formatting system the only thing for which
dynamic scoping makes sense, and indeed is required, is style
information. So Lout already has inherited characteristics, though a
very small set compared to the DSSSL. This discrepancy between Lout
and DSSSL requires missing characteristics to be emulated via
parameters to symbols and those are lexically scoped.
As style is initimately tied to formatter internals, style information
at one point travells from high level world into formatting engine and
can be queried only indirectly. In Lout one can access current
language via @CurrLang symbol and several metrics via units like
f,s,v,y,z. In DSSSL for every IC there's a procedure named
inherited-c where `c' is the name of the IC.
To sum it up: the backend is to manage IC's itself.
* Spacing model.
Spacing model adopted by DSSSL (see display-space and inline-space) is
incompatible with spacing model used in Lout. This is hard to work
around, especially emulating display space priorities seems very
problematic.
I haven't investigated if we can compute spacing in the backend, but
my guess is "no, we can't". When objects has several ports, FO can
attach to ports at random times and we can't know in advance if two
objects will be juxtaposed in the output and precompute the display
space between them. This issue needs further investigation though.
PS: Comments are appreciated but don't expect quick replies. Sorry.
SY, Uwe
--
address@hidden | Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen
=========================================================================
You are subscribed to the jadelout mailing list.
For help using the majordomo mailing list, send a message to:
address@hidden
containing the line:
help
To unsubscribe from this list, send a message containing the line:
unsubscribe jadelout
--- End Message ---