Re: Hebrew in LaTeX

On Fri, 16 Dec 2005, Nadav Har'El wrote:

> > The only problem I see with making Culmus the default under babel 
> > is one of distribution -- babel should ship with the actual fonts 
> > themselves, as it does, for instance, with Greek (and Hebrew, for 
> > that matter).
> 
> Are you sure that Babel indeed comes with such extra fonts? I don't
> see them on my system.

You don't have $TEXMF/fonts/source/public/cbgreek/ ?

> I believe that the best solution is not to include type1 fonts 
> with Babel, because these fonts have other uses on a system as 
> well (X Windows, OpenOffice, etc.). Rather, I think that babel 
> (or however it's packaged) should include ".tfm"s (and the other 
> results of the complex Makefile you described), and assume that 
> the fonts themselves come from some other part of the 
> distribution. On a Linux distribution, if you install both 
> "tetex" (which includes babel) and "fonts-hebrew" (culmus), the 
> pieces would just fit together, and you'd have the fonts usable 
> by Babel as well.

I'm sorry, but I disagree. Using fonts -- any fonts -- is a pain 
with TeX. For the Culmus support, for instance, you need to not 
only create .tfm files, but also .vf files that map the 8-bit TeX 
encoding to the unicode positions in the fonts themselves, map 
files that tell printer drivers where to find these fonts, and 
probably some other stuff that I'm forgetting at the moment. All of 
this must be done through TeX-specific tools rather than standard 
system tools. If you update your fonts, it has to be done again. 
Given that Culmus is still under active development, there normally 
would be a lag between updating Culmus and updating the TeX 
resources. You don't want to hold up your entire system waiting for 
TeX to catch up.

Also, TeX makes very picky assumptions about the location of fonts, 
and again doesn't interface nicely with standard system tools. It's 
enough of a pain to get the fonts right in a texmf tree; sharing 
them with an operating system would be a nightmare (not to mention 
portability issues). Sharing resources is a nice idea. However, 
disk space is cheap these days, and duplicating the fonts for TeX 
seems a lot more practical to me.

> > In order to support all the characters from Culmus, the Hebrew TeX 
> > community has to agree on a standard 8-bit font encoding (which of 
> > course would be idiosyncratic to TeX, but there's no way around 
> > this). I tried to push such a proposal two years ago but I don't 
> > think it was widely accepted.
> 
> What's wrong with starting with ISO-8859-8 (which is basically 
> the characters that most people would need anyway), and 
> continuing with the Windows or Israeli Institute of Standards 
> encoding (to allow also niqqud)?

This is indeed the basis for the font encoding, but you also need 
to include unicode characters that are not available in any 
standard 8-bit encoding (e.g. cantillation marks).

> In any case, if people use a standard editor (say, vim) to edit 
> the files, there is not much point in adding characters which 
> won't be visible in vim. Instead of adding some character for 
> "doublevav" which will look like a "a with umlaut" (or whatever) 
> on vim, it's better to just have a \doublevav command to generate 
> this character. Then users won't care which encoding we chose for 
> this character.

I wasn't talking about standardizing an input encoding -- LaTeX 
already deals well with the various 8-bit Hebrew encodings as well 
as with UTF-8. What needs to be made standard (for the TeX world) 
is a *font* encoding, a mapping of all the characters you need into 
an 8-bit table that TeX can use for its output. A user may be 
content with typing \pashta or \newshekel, but TeX needs to output 
a particular 8-bit character.

> If there's something you can send me, I'd like that. I'm not sure 
> yet how I'll deal with the dozen different versions that appear 
> to be out there, though :)

Give me a week or so to sort things out on my laptop -- I haven't 
checked the inventory in quite a while :-)

-Ron.
----
Ivrix-discuss list. See http://ivrix.org.il.
To unsubscribe, please send mail to [email protected] with
only the following line in the message body (NOT SUBJECT!): unsubscribe