[cl-typesetting-devel] HTML rendering

[Marc Battyani]

"Klaus Weidner" <klaus at atsec.com> wrote:

> > Good. I will add this to cl-typesetting.
>
> I'm still planning to clean this up and add some docstrings, but I guess
> updating this later should not be a problem.

OK

> BTW, I'm currently handling the forward references by completely
> re-running the layout engine if unresolved dependencies were detected,
> similar to the way LaTeX does it. Any remaining unresolved ones get
> reported (well, printed to stdout) after the second pass. There may be
> more direct ways to handle this, but the current approach works
> well enough and has the advantage of being very simple.

It's OK for me. Anyway there could be degenerate cases where there is no
convergence.

> There may be rare cases where replacing the "999" currently used in the
> first pass for forward references would cause a change in pagination (and
> therefore wrong references) when replaced by a different number of digits
> on the second run. Currently the code just ignores this, but it would be
> possible to add checks to see if the marks moved.

OK

> > > The XHTML transformer is still too unfinished for distribution, but
...
> > Of course I'm interested! Please send it as soon as you feel it's clean
> > enough.

> That depends on when I can find time to do more hacking on it - I'd like
> to have it support the "everything.html" file completely. But if it turns
> out that I can't find the time, I'll post what I have and let others
> worry about it.

The fact that time comes in so limited amounts is one of the best reasons to
write in Lisp ;-)

> > >   Also, I'm not sure what a "trie" is (used by hyphenation). And I
think
> > >   that keyword arguments should not use a "-p" suffix.
> >
> > A trie is a kind of search tree (prefix).
>
> Thanks, I guess I should have asked Google right away...
>
> > What keyword arg are you talking about ?
>
> I've found the following initargs and function keyword args:
>
> :adjustable-p
> :splitable-p
> :trimable-p

I see, I thought you were speaking of the trie code.
I generally use the same initarg as the accessor in CLOS slots.

> In the CL libraries, the -p suffix is used just for predicate functions
> and not for boolean keyword arguments. I think that (... :adjustable t)
> is more readable.

At least it's more consistent with the standard functions.
Anybody against this change ?

> > > - I don't know how leaders (the dots joining table-of-content entries
to
> > >   the page numbers) should be implemented. Note that the dots should
line
> > >   up even if the TOC entries have different lengths, so it's not a
simple
> > >   matter of sticking periods in boxes.
> >
> > IMO it's only a matter of sticking the correct number of dots with a
hfill
> > between the last word and the dots. The only trouble is to compute the
> > correct number of dots ;-)
>
> I don't think it's that simple - once you have a box containing the right
> number of dots, you still need to position it exactly by inserting glue
> in the front to handle the width variations of the preceding text - it
> looks extremely ugly if they don't line up vertically on different lines.
>
> Also, this may just be a lack of understanding on my part, but what would
> the best way be to handle the case where the title is too long to fit in
> a single line? Something like this:
>
>    Chapter one . . . . . . . 3
>
>    Chapter two with a really
>    long title  . . . . . . . 5
>
> Note that the first line should not run into the numbers column, and the
> last line needs to have the dot fill. Hmmm, seems to be a candidate for a
> paragraph that has a different right margin for the last line, kind of a
> reflection of the way the first-line-indent works.

I was rather thinking about a fill-with-dots-and-put-a-number-box special
box that would act like a hfill (and prevent the right margin space to be
inserted)

> Also, there should be a way to completely control the additional glue
> added during line breaking - I think at the moment there's no way to
> prevent the last line from getting an additional hfill added which would
> break the layout.

Same process here.

> > > - PDF hyperlinks aren't handled yet by the typesetting code - how
about a
> > >   link-box class which acts as a clickable area for the bounding box
of
> > >   the content?
> >
> > I wanted to do this but it's not so simple. I have a few ideas on how to
do
> > it. I will try to find some time to implement them.
>
> A problematic area is matching up the references the typesetting layer
> knows about with the PDF cross-references. Note that my referencing code
> currently saves the page number and the x/y position for the mark, does
> that help?

Yes, there is stuff for this (references) in cl-pdf.

> > BTW what about the CMUCL problems ?
>
> The only way I can get the code loaded on CMUCL is by moving the
> def-function into a separate file (i.e. zlib.lisp), which is loaded after
> the load-foreign-library was run. No changes within init.lisp worked,
> since it doesn't even load if there's an unresolved reference to
> "compress".

It's strange how something so simple can be the major source of problems.

Marc