lout-users
[Top][All Lists]
Advanced

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

Re: Many questions :)


From: Jeff Kingston
Subject: Re: Many questions :)
Date: Thu, 15 Apr 2004 09:29:10 +1000

On Tue, 13 Apr 2004 18:08:27 +0200 (MEST), "David K|hling" wrote:
  > 
  > Hi everybody,
  > 
  > I'm currently involved with typesetting a japanese dictionary for
  > print, created by a group, mostly of students, using unicode XML.  The
  > XML sources are translated to euc-jp .tex, using jLaTeX for
  > typesetting.  Although the whole thing seems to work, maintaining and
  > extending the TeX style-definitions gets harder and harder the more
  > professional it gets.  Simple tasks can take hours to implement in TeX
  > with all kinds of strange side effects occuring later on.
  > 
  > This is the point where I decided to look for alternatives, even
  > thinking about creating a custom PostScript typesetting system.  Well,
  > lout seems to be capable of all the things that I need.  It's
  > remarkable what kind of features can be expressed in terms of the
  > simple concepts that lout uses.  Looking at /usr/share/lout reveals,
  > that there even exists a direct interface to PostScript, @Yield, which
  > would allow me to add japanese language support.

Actually @Graphic.

  > 
  > Still I have a lot of questions in mind, which I would like to ask,
  > before spending much time on implementing dictionary-output to Lout:
  > 
  >  * What is the current status of lout development?  The web pages I
  >    saw hadn't been updated for quite some time.  Is it actively
  >    maintained?

Yes, by me.  But it is a mature product now so there is not much
maintaining going on.


  > 
  >  * Although Google didn't reveal anything: were there any attempts in
  >    the past to support languages with multibyte characters
  >    (chinese/korean/japanese)?
  > 

Only vapourware.

  >  * What would be the best way to "decode" japanese multibyte
  >    characters in lout?  I can currently imagine two possibilities:
  > 
  >    - Using one `def' for every two-byte japanese character code, which
  >      should consist of two characters >127.  The file containing those
  >      characters could simply be auto-generated and would depend on the
  >      coding-system used (euc-jp/utf8) and the coding of the japanese
  >      font I'd use.
  > 
  >    - Using @Filter and some utility program that would decode japanese
  >      characters into a sequence of calls to a function @JChar with the
  >      character's font-codepoint passed as argument.

I certainly couldn't recommend starting an operating system process
on every character, which is what @Filter does.  I'm pretty sure that
the only *realistic* way to do this is via built-in support for 16-bit
fonts, which Lout does not have.  I suppose there is some chance of
handling it by making every character into a Lout @Graphic, but it
feels pretty horrible to me.  Might be just bearable computer-generated.
 
  > 
  >  * japanese line-breaking rules are somewhat special: all characters
  >    (should) have the same width, so all lines are automatically
  >    block-formatted.  But, full stop and comma (and some other chars)
  >    are allowed to extend the current line, so they won't occur at the
  >    start of the new line.  Can such a rule be implemented in Lout?
  >    Requires use of @Filter?



You could define a version of full stop that appeared to Lout
to have zero width even though in reality it stuck out a bit.  With
a bit of care I think you could get this stuff done.

  > 
  >  * Although I don't need it: is there any chance that top-down
  >    left-to-right text-flow can be implemented in Lout?  It seems that
  >    at least with @Filter that should be possible.  But there seem to
  >    be some subtile limitations to Lout, at least I read about problems
  >    with balanced two-column text.

I won't be doing this and I don't know of anyone else who has the
expertise.

  > 
  >  * I didn't yet find any information in the Lout documentation about
  >    doing simple calculations in Lout.  Eg calculate positions for
  >    blobs in the margins, depending on first Letter of the dictionary
  >    entries on a page.  Again, I suppose this could be done using
  >    @Filter.  Using math with TeXs registers, you could do fancy
  >    things...

Yes, Lout has no mathematics built in.  However, take a look at
the @Place symbol (is it?), @LeftNote, @RightNote etc.  They do
this kind of thing by utilizing PostScript's mathematical features.

Note that calls to @Filter are given no access to the internal state
of the Lout interpreter at the point of the call.  All they get is
the sequence of characters enclosed in {} following the symbol.

Jeff Kingston


reply via email to

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