[texhax] Fwd: kerTeX: TeX and al. under BSD license

[tlaronde at polynum.com]

After some delay, time for me to give e-TeX a look, I can clarify some
things:

On Tue, Dec 20, 2011 at 12:20:24AM +0100, Reinhard Kotucha wrote:
> 
> 
> [e-TeX] is a change-file.  Shouldn't be difficult to apply.

Indeed. I thought at first to take it as an example as an "add-on" to
the kerTeX kernel. I finally decided to add it to kerTeX. See below.

And I may even tackle the task sooner than expected.

>  
> [...] 
> It's not clear to me what your final goal is.  First you said that you
> want something which DEK can use.  On the other hand, the programs in
> TeX Live are the same, except that they include kpathsea.
> 
> Then you said that you want to support UTF-8 too.  This certainly
> requires significant changes to both, TeX and dvips and even to the
> DVI format.  It contradicts somehow your aim to be closer to Knuth's
> stuff.
> 

My aims are:

1) To have the smallest, cleanest kernel system with the tools to do the
translation from WEB to C, offering what is described in D.E.K.'s books,
with the smallest set of required tools to make it useful: all the
utities written by Donald E. Knuth (this includes debugging tools); AMS
supplementary fonts and font tools; bibTeX (from users' demand); 
MetaPost (essential); and the means to render DVI: dvips(1). [One thing
will be lacking for 1.0: a dviraw(1) driver rendering a raster image. It
will be added later.]

2) This system has to be available easily, for the maximum of host
systems. This means C89 and that's all. This means cross-compilation
possible. All this is here.

3) Since the kernel system is available on the widest range of hosts
systems; since it is organized and explained; since it is small hence
"holds in one hand" (maintainable from the french "maintenable"), it 
should be easy to use it to _add_ supplementary packages or programs as
the user sees fit. Not the obligation to download half of Google cache
in order to search for the needle in the haystack.

4) KerTeX, from lessons given by Unix and Plan9, has a clear _name_
orientation. This solves the problem of searching for files. This will
solve the problem of unicode fonts and direction of writing.

What is the name that could be used to identify myself?

/universe/solar_system/earth/france/haute-savoie/annecy/laronde/thierry?

NO! This string has a casual prefix and what keeps me being me when
being elsewhere. The identifier is: laronde/thierry. The prefix is
casual.

Hence, in kerTeX, what is casual is where the TeX system is installed.
And when you input a file, for a macro set say "mistex", you use:

\input mistex/blunder.tex

A portion of the pathname: subdirectories, is part of the name.

For example, in kerTeX, "Times-Roman" is (for TeX) a TFM with finally
PostScript compatible encoding, while tex-latin1/Times-Roman is the same
underlying core PostScript font but with a tex-latin1 encoding.

With this principle, searching is simple and efficient. And furthermore
the system is organized.

5) Does support of Unicode and not left-to-right direction of writing
needs heavy TeX' guts surgery? No: TeX can stay 8 bits. Why? Because of
utf-8 from Ken Thompson and al. for Plan9. You can have Unicode while
still being 8 bits and compatible with the expectation of old code.

In his mouth, TeX will receive utf-8 that is 8bits characters
strings---the same as now---. And internally, he will always deal with a
256 TFM. But a subfont. What is 16 bits? 256 x 256. When a fontname is
given, if the unicode is in the 8bits range, the fontname/0.tfm is
tried. If it is not found, fontname.tfm is tried. And a fontname can
have only partial subfonts, not the ./0 to ./255. Since TeX will be
dealing only with 256 characters at one time, nothing is changed.

But the unicode not only tell what character is expected, but in what
context of direction of writing. When popping one level, perhaps leaving
one direction of writing for another one, the only manipulation needed
is perhaps swapping height and width, and right and left coordinates of
insertion point.

In this sense, and to take Barbara's given example, if an arabic writer
wants to write mathematical formulas right-to-left, he will have to use
a codepoint in the arabic ranges. If he uses the latin range,
mathematics will be rendered left-to-right.

TeX processes a string; a linear sequence of characters. The rendering
may be left-to-right; but this is casual.

There is nothing to change in the DVI format, since there is already
provision for additionnal commands. And e-TeX has not changed the DVI
format it seems?

Allowing utf-8 as input in a system change---so it is allowed.

By design utf-8 kept compatibility. The same here, with "extended"
compatibility because it works as is for latin-1 that is even in Unicode
the first byte range.

For the remaining, whether it would be considered a system change (the
manipulation of the metrics and coordinates of the boxes), we will see.

Whether it will finally work or not will be answered when done...

During the tries, this will be another TeX by-product with another name.

6) As an exception, I think I will put e-TeX in the kernel system.

First, because the principles are closed to mines.

Because it is small and seems clean, and depend on nothing since it is a
change file.

It already allows the use in a right-to-left context, so render the
system more usable for a wider audience.


I hope this clears some things.

Cheers,
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C