[cl-typesetting-devel] Hyphenation config

[Klaus Weidner]

On Sat, Apr 24, 2004 at 10:43:03PM +0200, Marc Battyani wrote:
> OK though I prefer this:
> (defmethod stroke :after ((box char-box) x y)
>   (when (functionp *post-decoration*)
>     (funcall *post-decoration*
> 
>  Rather than:
>  (defmethod stroke :before ((box box) x y)
>    (if (and (functionp *pre-decoration*)
>     (typep box 'char-box))

I agree, I had overlooked that way of doing it. Have you made that change
already? If not I'll add it to my next patch (whenever that is).

> > Another challenge is that the code uses around 300 MB working memory for
> > a simple 60-page document; this will need some tuning to be able to
> > handle more complex or longer ones on affordable hardware. But that fits
> > the Lisp philosophy, first get it working and then worry about
> > efficiency...
> 
> Yes, this is the normal way of doing stuff in Lisp. For instance there are
> lots of floating point computations and no declaration yet.

Surprisingly CLISP seems to be *faster* than the native compilers -
probably because the simpler non-optimizing byte code compiler can eval
the huge typesetting term more easily. 

One area that I think is a source of inefficiency is the style handling -
each style change is handled by a large number of individual assignments
and conditionals based on the style object for the various property
variables. I think it would be faster to have a single object (class or
structure) represent the entire current style, and support reuse of style
objects rather than creating new ones all the time.

For example, the higher-level code could create one style object each for
every style combination it needs, and then each style change would be one
unconditional assignment. The lookup of styles would be a bit slower,
i.e. a (style-font-size style) indirect lookup instead of directly using
*font-size*, but I think on balance it would be a lot faster.

This would be most efficient for completely specified style objects (with
no NULL fields). Handling incompletely filled style objects could still
be supported via a stack of graphics contents.

It may be faster to implement the low-level style objects as structures
rather than classes for efficiency, once the format is fixed. Something
for benchmarking...

-Klaus