Yes, in principle. But that would be an overstatement yet.
You will wonder - it should be English!
I apologize any sin against a good English.
Please mail me on any error or on bad style,
especially if it results in reducing the comprehensibility.
There is free software only on this site now.
That shall be retained, as far as possible.
(In case, I'm allowed to include third party software, which is not free,
I will mark it.)
To be more explicit:
You are allowed to use, copy, modify, and distribute
this software and its documentation for any purpose.
Neither a written or verbal agreement, nor a fee is required to do that.
I'm interested in any notice on errors or bad spots.
But I'm unable to guarantee anything, including to remove errors.
To be more explicit:
I'm not liable for direct, or indirect damages
arising out of the use of any software on this site.
I disclaim any warranties for the software on this site.
It is provided on a "as is" basis.
I'm not obliged for maintenance, support, and enhancements.
Some parts of one thing only - version 0.5 of a fonts family for the Indus script:
If I get permission, I will provide the readings of I. Mahadevan too
(and some other - mostly documentation - material).
In any case, a script to produce
a concordance from given text readings will come soon.
Later on, fonts to implement the K. Koskenniemi / A. Parpola fonts will be provided.
The wishful dream is a font family, allowing:
Only one sign list can be used yet.
The fonts can be used in a TeX environment only.
The flexibility of text handling is very low
- you need to write a TeX input text to use the fonts.
The first restriction will be removed soon,
but the prospect on the others is not known yet.
Yes.
Any restriction from the preceding answer should be removed
(or lowered at least).
The given order seems to be the order of urgency.
Some work to advance the typographic level of the fonts would be nice too,
but there is little chance, that there will be much done in this respect.
At first, fonts for the said sign lists will be produced.
After that, I will seek for a way, to transfer the fonts into a format,
usable in a non-TeX environment.
(May be, MetaPost, Metafog, or TeXTrace will help.)
I could not find such a font in the Web. But it's difficult, to work on a script without a font.
When I started, the list, given by I. Mahadevan in his beautiful "The Indus script" was the most actual, I was aware of, for which readings of the known Indus script texts were public available.
The K. Koskenniemi / A. Parpola sign list from 1979/1982 is necessary,
to be able to work with their readings too.
The sign list from A. Parpola "Deciphering the Indus script"
should be provided too, because it seems to be the
best sign list existing nowadays (autumn 2001).
As a programmer, I need a programming language to be happy with.
(And its a pleasure, to work with Metafont! [Yes, mostly.])
There are objective reasons too:
Metafont allows to produce a family of fonts,
varying in a lot of parameters.
(I made only restricted use of that yet.)
I don't know a way, to avoid that. May be, I missed the point for TeX yet.
Only one example text - with one line for every sign, containing a full found 'text',
as 'read' 1977 by I. Mahadevan, has been prepared.
And that has been done for one font variant only: a 15pt variable width font,
with signs of two heights and uncentered glyphs.
(But the representation is biased, because the texts are not given as continuous sign sequences,
but all in a great invisible table - every sign fills one cell of the table.
That has been done, to get both vertical alignment and minimal line width.)
You can inspect it in
The dvi format is TeX's output format -
you need TeX or another special tool (as dviwin) to inspect it.
The pdf format file resulted from the dvi-file by conversion with dvipdfm.
For that you need to get that font variant first (see below for some possibilities). The scripts in one of the scripts-xxx directories of example building scripts can be used then (directly or adapted) to see the text example, as it looks with the font variant wanted.
If you are gone the way from
get a font by generate it,
you already have loaded and unzipped the scripts needed here (and the TeX example source too).
The steps to do here are analogous to the steps described there.
After you got a font, you can use the macro testfont.tex,
which is part of any TeX implementation,
to get sign tables (and make other tests) for the three partial fonts, constituting the font.
(Why three, not one?
see below.)
So by executing
The way to generate a font, described below, includes to load the zipped Metafont sources (and some scripts).
But to inspect them immediately:
The 3 Metafont sources are
(Metafont will be called with a temporary source file, build by a 'generate' script.)
Only one example text - with one line for every sign, containing a full found 'text', as 'read' 1977 by I. Mahadevan, has been prepared: signline.tex.
From font building scripts, resp. example building scripts you can navigate to the scripts.
(Not every browser allows this navigation. In case of problems, you need to load and unzip sources and scripts to see the scripts. But they are of little interest anyway.)
There is no need then to load or generate fonts: Look at
signs and texts -
this pdf-file lists one text
(in the reading of I.Mahadevan, "The Indus script", 1977)
for every sign. It uses a 15 pt font.
(The
dvi file,
as produced by TeX,
has been converted into a pdf-file with the program dvipdfm.
A dramatic loss in quality, I observed earlier in this process,
seems to have vanished in using Adobe Acrobat Reader 4.0 to show the pdf-file.)
I don't recommend that
(because you need TeX anyway yet,
and a TeX implementation encompasses one of Metafont),
but it's possible:
Load either the full set of (zipped) prepared fonts:
| all fonts prepared (~2 Mb) |
| f02l8i15 | variable width (not centered), two heights | ||
| f41l8i10 | f41l8i12 | f41l8i14 | variable width, one height |
| f42l8i10 | f42l8i12 | f42l8i14 | variable width, two heights |
| f51l8i10 | f51l8i12 | f51l8i14 | fixed width, one height |
| f52l8i10 | f52l8i12 | f52l8i14 | fixed width, two heights |
| f11l8i10 | f11l8i12 | f11l8i14 | fixed width (not centered), one height |
| f12l8i10 | f12l8i12 | f12l8i14 | fixed width (not centered), two heights |
The last number in the font names (10, 12, 14) is the font size.
For more information on the (provisional!) font naming read
font name structure.
On the meaning of the font parameters,
see below.
After loading you need to unzip the tfm- resp. pk-files into one of the tfm- resp. pk-directories of your TeX implementation - see below.
For Microsoft windows and for unix environments
some scripts have been prepared to support font generation.
!! Sorry, I could not really check the unix variant !!
The following steps will generate a new font (a working TeX implementation is assumed):
(But if you only want some (or one) font variants to experiment with, to execute file generate-all[.bat] (or generate-example[.bat]) after steps 1 and 3 would be enough.)
Try to get it by modifying the source files (or scripts)
from the preceding question (1st point).
There is some hope, that you can do that successfully in some limited range,
without to study Metafont.
Contact me, if you fail, or if your problem seems to be a general interest one.
Only the variable width fonts are useable for continuous text.
Fixed width fonts seem to be (and, maybe, they are) badly designed
for a script with glyphs of very different width as the Indus script.
Nevertheless they are provided here:
they could help to show texts in a form,
which enables the eye to detect vertical structures,
similarities between texts, some lines apart.
(In a fixed width font every sign gets the same width.
[It is not hard, to set it by source text modification:
Modify the sign_width setting ('if odd'-line) in file indusfont-parameter.mf.]
In a variable width font the sign widths are different -
they are determined by the 'natural' width of the glyphs,
may be restricted to a maximal width.
[To change this, modify the dx_list settings in file indusfont-param-ext.mf.])
Some of the Indus signs are build from others by adding a kind of 'roof' above it,
formally similar to the relation 'A' - 'Â' in European languages.
So the most natural font would have two heights, one for roofed and one for unroofed signs.
But sometimes it's better, to avoid excessive heights, -
so fonts, which shrink roofed signs to the normal height have their use too.
Every normal font has 'centered' signs,
i.e. the glyphs are horizontally centered in their space
(may be not mathematically centered, but optically).
For the same reason, given above for fixed width fonts,
we can build 'uncentered' fonts here: not the whole glyph,
but that glyph part only, which seems to be the main part, is centered.
For example, in using such an uncentered font,
if two lines follow another, one containing a sign, showing a man,
the other a sign, showing a man with a weapon in one hand,
where both signs are holding the same position in their lines,
then man and man part are aligned vertically.
These three parameters and the font size are represented in the font name scheme, we use here.
The implemented sign list has 419 signs.
But Metafont can only produce fonts with no more than 256 signs.
(There is a possibility for more signs,
but the characteristics of the Indus script make it unusable.)
So we need to split the font into two partial fonts at least.
But then, to split into three instead of two doesn't complicate the work anymore -
and it allows, to produce 'preliminary signs' and/or ASCII signs too.
It would be nice, to hide this splitting from the user by reuniting the partial fonts.
I tried to use the tools in TeX systems, intended to perform this task, -
virtual fonts and Omega - but I failed to find a full and working tool set.
Anyway the complication, springing out from this font splitting, isn't high.
The need for the short macro set, starting with "\def \i#1#2#3{" in the
example text,
seems to be the full load, burden on to the user.
(Nevertheless, I hope for better solutions in the future.)
For now and some time only one sign list has been implemented. What about working with texts,
represented by another sign list?
We can handle them in a restricted way,
if we use signs from the implemented sign list,
which are similar to the signs in the other list,
and fill the gaps with 'preliminary signs', which give the sign names essentially.
The sign with number 123 from A.Parpola's list could be represented
for example by the string "a123", put inside of a rectangle.
Even when all sign lists proposed have been implemented,
there may be a purpose for 'preliminary signs',
for example as placeholder of new signs.
The text, such a sign is composed from, can use any ASCII sign, not letters and digits only.
An implementation of TeX, including Metafont, is needed. To find such implementations look at the main tex site www.tug.org or on regional versions - some of them are listed in TeX.
I'm not aware of a general answer - it's dependent from your TeX implementation and installation.
At first you need to find out the (or: a good) home for fonts in your TeX environment.
May be, you take it from the value, assigned to VARTEXFONTS in file texmf.cnf,
anywhere in your system's TeX part.
Or you search for directories, named ljfour, and take the initial part of the path found,
up to 'fonts', as the fonts home wanted.
(If you get more than one such path, take one of them, which seems to be free for extensions.)
With - say - xxx/fonts as fonts home, I recommend to choose
"ljfour" is the 'mode', it should be replaced by the real 'mode', if it's not ljfour.
('mode' is a Metafont notion here, representing the output device. Don't change "ljfour",
if you don't know this notion. [Or choose "modeless" instead, if you are in doubt.])
"public" stands for the supplier of the font.
"indus1" is my tentative recommendation for the 'typeface'. (May be, other fonts are coming ...)
Another way: find it out by experiment: Generating a font, the TeX/Metafont implementation will normally place the generated tfm- and pk-files into subdirectories of your TeX environment. Take them.
Last possibility: search your system for .tfm-files (and 888pk-files, with 888 representing any number). Take these directories or - better - analogous directories.
(Fortunately, in any TeX system, not outdated totally, to choose an arbitrary directory below of xxx/fonts/tfm resp. xxx/fonts/pk should work. Nevertheless a good choose helps to maintain your system.)
((Sorry, the source text and script structure, I'm using here, doesn't fit well into the TeX systems, as structured nowadays. May be, a better solution will be found.))
No, sorry. For some (may be bad) reasons, especially that there are no ready-made source texts, but temporarily produced ones only, you need to produce a font manually before use - see above.
You need to write a TeX text.
Eventually file
signline.tex
could be used as an example.
In this text \i123 denotes the sign 123 (I. Mahadevan's numbering),
\I123 denotes the same sign, in case it's a questionable reading.
TeX produces a dvi-file from the tex-file. There will be a tool to display such a file in the TeX environment too, for example dviwin.
If you need to display the text in an environment, not containing TeX, you need to convert the dvi-file into another format. I used dvipdfm to do that, resulting in a pdf-file, which could be displayed with Adobe Acrobat Reader.
You are right. It's of low typographical quality. But the task has been (and will be for some time) to get a font, we can work with. So beautiful fonts need to wait. Sorry.
No, I like comments. But I don't like commenting.
Yes, the programming style could be better in some respects
- commenting seems to be the most important.
The extensive use of Metafont's macro facility to define own 'keywords'
could be rightly criticized too.
The use of this facility to replace very a lot of functions
by expanded versions however is an act of self-defence against
the second hardest lack of Metafont:
the non-existence of a free transformable build-in notion
for 'figures' from more than one path.
(The hardest lack is the enforcement to export pixel oriented pictures.)
Great progress in deciphering the Indus script could be made by an ingenious idea,
by chance (as a new found bilingue) - or by systematic work, starting from the work,
done already by a lot of scholars. To do that, existing readings have to be collected.
For good reason, these readings use different sign lists,
so some of them should be implemented.
May be, in search for a deciphering or the 'ultimate' sign list,
a simple way to experiment with different sign lists can be helpful too.
All these sign lists share a lot of signs, others are similar.
So it seems to be good, to produce them all from one source text only.
Many signs occur in sign variants, differing in aspects, which could be essential. So in the long term it's not enough to display a sign by one glyph only, there is some need to display variants too. To write the source text in a way, allowing to implement sign variants too, I choosed to implement (as a test) some variants for five of the signs.
Yes. Take them as first private thoughts of a newcomer, unknown to the matter.
Digits and small letters were intended to be used as constituents of preliminary signs: So sign 123 of, say, A.Parpola's sign list could be represented as 'a123' as long as this sign lacks its pictorial representation. But then I could not stop me, to implement all ASCII signs.
Right. The functions are written to do some special work, not as general tools. Nevertheless I hope most (nearly all?) functions will meet greater requirements too.
I found it very useful, to avoid the subtraction notation
| b - a |
| a -+ b |
Probably never. I'm not working on this theme.
If you have questions, recommendations, etc., please
mail me.
(To answer immediately, I'm unable to promise. Sorry.)
e-mail
http://www.barataria.de
last change: 20. Sep. 2002