lout-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lout, is it too late?


From: Karl Ove Hufthammer
Subject: Re: Lout, is it too late?
Date: Sun, 8 Oct 2000 18:01:51 +0400 (MSD)

Message: 2
   Date: Sun, 24 Sep 2000 19:20:06 +0200
   From: "Henrik Martensson" <address@hidden>
Subject: RE: Lout, is it too late?

Here's my opinions (as a user, not a developer):

>However, being an XML nerd, there are some things I would love to
>see in Lout, that would be of benefit to... well, to me, at least:
>
>* Unicode character support would make it unnecessary to translate
>  characters like å, ä, and ö in XML text strings to Lout character
>  codes. XSLT really sucks at this sort of thing, so it would be
>  a big help if one didn't have to do it.

Yes, Lout should support Unicode character encodings. UTF-8 and UTF-16 would
suffice. IMHO, it's pretty bad for an application nowadays to not have native
Unicode support.

>* Chapters and sections would be easier to handle if they used a
>  recursive format along the lines of
>
>  @Section
>  ...
>   @Section
>   ...
>   @End @Section
>  @End @Section
>
>  This would make it easier to reuse document fragments in different
>  contexts.
>  For example, a section in a chapter could be reused as a
>  subsection, or as a  chapter in its own right, in other documents.

Yes, though if you're using XSLT to transform an XML document to Lout, this
could be done automatically (nested sections --> Lout syntax).

>* I would like the ability to specify page templates with multiple
>  text boxes, and then assign a text flow to a box in a template.
>  (If you are familiar with, for example, the FrameMaker MIF format,
>  you know what I mean. I would like a simpler syntax than MIF uses
>  though.)

Sounds like a good idea to me.

>* A set of XSLT style sheets that transform XSL into Lout. This
>  would
>  turn Lout into a real contender in the XML arena. Suddenly, Lout
>  would become usable as a back end to all XSL based formatting
>  systems. (This is the same thing PassiveTeX does with LaTeX, the
>  difference being that the conversion from XSL to LaTeX is done
>  with LaTeX macros.)

I agree, but 1) this needn't be part of the *Lout* package (it could be separate
project), and 2) you don't *need* to use XSLT style sheets (it sounds a bit
difficult to use a XSLT style sheet to transform and XML document to Lout using
XSL formatting objects). A *program* would probably work better (i.e. faster).
Of course the would need to be cross-platform.

>* An XHTML back end for Lout. XHTML is the XML compliant next
>  generation
>  HTML. It works in most current HTML browsers. In combination with
>  the XSLT style sheets mentioned above, this would mean it would be
>  possible to use Lout to convert from XSL to Postscript, PDF and
>  XHTML, which would cover most peoples formatting needs. (At least
>  my needs!!!)

I'm not sure if I understand. Do you mean converting Lout to XHTML or XHTML to
Lout?

The former would not be easy, nor good (as Lout is really presentation based
(yes, it is structure based too, but you're mixing content and presentation),
while XHTML is content/structure/semantics based).

The latter would probably be very easy. Just write a XSLT style sheet to
transform the XHTML document to Lout.

>To sum it up, the changes I would like to see in Lout, i.e. Unicode
>support, recursive sections, high level commands for building page
>templates with multiple text flows and XHTML output, are changes
>that I think would benefit anyone that is interested in using
>complex layouts and/or publish formatted documents online,
>regardless of whether they use XML or not.

Yup. I agree.

I'm pretty new to Lout (and this list), but here's another feature I would like
to see:

TrueType font support. It's very difficult to use TrueType fonts in LaTeX, and
native Lout support would be a huge advantage. This should be as easy as adding
the font directory to the Lout configuration file (and perhaps running Lout with
a command line option to refresh the font database). You should then be able to
specify @InitialFont { "Gill Sans" Italic 11p }, and have it work. This would be
*so* nice ... :)

(One reason I would like TrueType support, is that most (new) TT fonts include
Unicode characters.)

-- 
Karl Ove Hufthammer


reply via email to

[Prev in Thread] Current Thread [Next in Thread]