dotted hfill (was: [cl-typesetting-devel] HTML rendering)

[Klaus Weidner]

On Wed, Apr 21, 2004 at 10:59:44AM +0200, Marc Battyani wrote:
> "Klaus Weidner" <kw at w-m-p.com> wrote:
> > Also, I've hacked the enumerate function to be a bit smarter, so that it
> > lines up the margins properly. To support that, I added a
> > put-filled-string function which aligns a string within a predefined
> > horizontal area. That also took some hacking - I may have missed some
> > obvious solution. Putting real boxes inline messed up the formatting...
> 
> You should use a hbox with hfills IMO. I will also have a look at this.

I tried that, and it did not work at all the way I expected it to.
Hboxes intermixed with text were placed on their own lines, not inline.
Stacking them inside vboxes kept them in-line, but with completely
screwed-up baselines, and the :align flag just changed which way it
was screwed up.

> The best solution would be to add tab stops ;-)

I think that way lies madness... Making a specialized box that expands to
a fixed x position wouldn't be hard, but my gut feeling is that this will
get the layout model too close to the Word ruler-based one, which is
broken.

> Computing table column widths is not an easy problem. An intermediate
> improvement over fixed column sizes would be to use the box model for this.

I'd just need to find some type of ad-hoc solution, since HTML files
don't always supply widths, or not for all columns.  In fact one of the
reasons I want this is because there's currently no reasonable way to
print complex HTML tables in browsers.

The only tool I know that does a good job is html2ps, but unfortunately
that's an unholy combination of obfuscated Perl with obfuscated
PostScript.  I'll try to figure out how its table model works (the layout
calculations are done in PostScript), maybe that will provide some
pointers.

Or is anyone willing to concede defeat and admit that PostScript can do
something Lisp can't? ;-)

> > I've attached the current output of the XHTML converter, which is
> > starting to look promising. Still missing are strikethrough and
> > underline, which I'm too tired to figure out how to implement.
> 
> Very good. When do you think it will be publishable ?

It's getting close. It's already starting to be useful, and the highest
priority changes are a proper table of contents (currently it just
contains the <h1> level), clickable hyperlinks, and a few more missing
markup items.

What I personally need most urgently is change marking including change
bars, and I already have a plan for that - just insert (changebar-start)
and (changebar-end) special boxes, and add a special-fn to the output
routine to draw lines in the margin at the corresponding y coordinates.

Is there an easy way to handle strikethrough and underline? Also, being
able to set the background color for character boxes would be a nice way
to mark the changes. Should be doable with a special type of box, but it
needs to be a style inherited automatically by whatever layout commands
it affects - just a put-bg-colored-string isn't useful for automation.

-Klaus