[Top][All Lists]
[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