Some reader of this blog should go and do a more extensive photoshoot and writeup of the museum, nu?

Judy Pinnolis forwarded this link to me months ago, for an Israeli site with information on early Hebrew newspapers. It's a wonderful browse! עיתונות עברית היסטורית Early Hebrew Newspapers. Note that instead of utf-8, the hebrew is encoded with windows-1252, so if you aren't using a windows machine, the hebrew may not be readable.

My name is Harold Jacubowitz and as a ceramic artist I'm looking for Hebrew metal types that I could use to impress into clay.

Could you help me find some ?

I'm not going to put his e-mail address online for the spambots to glom onto, but if you know of sources for Harold, post them here (that would be fantastic, because then everyone with the same question would get an answer), or e-mail me and I'll pass it on.

First, I borrowed a set of huge wooden type letters from the National Yiddish Book Center. Big, major fun.

The big fun was the newsletter. In format, it tried to be a sort of Junior High School paper—lots of loud type and graphics, lots of articles written by KlezKanada participants, and especially, a chance to present English, Russian, French, Spanish, and Yiddish with ease. I especially wanted people to see lots and lots of Hebrew that wasn't Frank Rühl or those horrible late 19th century van Dijk-influenced fonts that we grew up with. That was the special part.

What made it all work was the combination of Word and InDesign ME. People would type their material on their own computers using whatever (most often Word, but I saw everything from AppleWorks to unknown). So long as Word could recognize the encoding—and in this instance, it always did—it could convert everyone's files to its native Unicode format. Once saved, I could easily place the files in InDesign ME. Layout was a breeze. If you pay attention to the KlezmerShack over the next days you'll see the newsletters go online and you'll find everything from song lyrics in three columns (Yiddish - transliteration - English, per my preferred style) to MadLibs and wild stuff. InDesign didn't care. I have never had to pay less attention to the tool while doing layout. Every day I had from after breakfast (about 9am) until about 11:30 to get all of the material copied, edited, the photos edited, and the whole thing laid out. As the week went on and we went from four pages to six to eight, that schedule got bent, but I never failed to finish the newsletter in time for printing and delivery that afternoon, at worst. (I did realize early on that the laptop computer on which all of this work was done could not handle InDesign and Word and Photoshop using the dread Windows XP with a mere 256MB of RAM. Don't even think of doing this to yourself at home. That machine will shortly contain over 1GB RAM and will finally be "functional").

The biggest deal didn't actually involve Yiddish. KlezKanada brought over a dozen scholarship students from the former Soviet Union. They wrote several pages of thank yous "what I got out of KlezKanada" in Russian and English. To my shock, I was able to copy the file from the Russian computer, read it into Word, and everything was perfect. Tell me Unicode isn't the coolest thing since the square Hebrew letters became popular!

When I think of all the years I spent typing Hebrew and Yiddish backwards and kerning characters into place—not to mention the need to create the special Yiddish rafe characters, or the tzvey-yud pasakh, I could jump for joy. It's all so easy now. In fact, since no one had a Yiddish-enabled computer at camp, I typed the Yiddish directly into InDesign (far less buggy for that purpose than Word).

The American distributor of InDesign ME (Middle East—the localized version of ID that does the RtoL Yiddish and Hebrew with ease), I should mention, is this weblog sponsor, FontWorld. Give them some props. And if you click the small excerpted graphic, above, you can see a whole page of the newsletter in all of its cacophonous, joyous, multilingual beauty. This is a great time to be working with lots of fonts.

I haven't had time to breathe for months. There is a lot of neat stuff that should be noted here and isn't here yet. But I thought I'd mention an especially neat item that killed this afternoon.

Max and Minka have an amazing Yiddish decoder ring on their website (go to www.maxminka.com and click on "yiddish"). This is great for people who have the simplest possible computers and just want to get some decent Yiddish onboard. Unfortunately, to avoid encoding issues, Max made up a backwards, non-standard encoding. Great for one-time use; awkward for turning into a manuscript using commercial fonts.

I started each file with an HTML header and noted UTF-8 encoding. Then I wrote all of the characters to the file as HTML entities (in brief, take the Unicode hex, convert to decimal, and put into entity format. So, character 05D0, {HEBREW LETTER ALEF} becomes &s#1488;. By going the HTML route, I also had to make line-breaks explicit—HTML ignores the usual ASCII carriage return-line feed. That meant that I wrote a "<br>" after each line of (in this case) poetry.

Ugly, but it works. Here's the simple truth: Writing Unicode files may be complicated, but writing Unicode entities to an HTML file is entirely trivial.

There are some lessons worth taking from this. First, if you are composing something using the Hebrew alphabet (Hebrew, Aramaic, Ladino, Yiddish....) it is very important, if only for your own sanity, to make sure that you are using a modern (released in this century) word processor that understands unicode, and that you have fonts to match. If you are using something like MS Word, there are loads of appropriate fonts that come with. I believe that both the Mac and Windows enviornments provide reasonable fonts when the Hebrew resources are loaded (which come with the operating system, but are not loaded by default).

Second, of course, there are nifty tools like Max and Minka's Yiddish transmogrifier page or Raphael Finkel's Yidishe Shraybmashinke (Yiddish Typewriter). Both are fun to use and great solutions for many one-time or rare uses.

And, I guess another lesson is that I still need to learn how to write a file that will be opened by a Unicode-literate application and understood as Unicode. But, it is very much worth remembering that there is a shortcut: write to HTML, which is rendered in basic ASCII, and let your Word Processor put it all together.

Finally, as I think about putting more Hebrew-alphabet material on the web, it occurs to me that there are some tools for making language explicit that need to be considered. In the recent past, one might indicate hebrew with:

<meta http-equiv="content-type" content="text/html;charset=iso-8859-8">

When I first started thinking about coding webpages so that appropriate spiders would crawl the pages and indicate the correct language, I first looked at the ISO codepages. The presumption would be that if you are using the Hebrew character set, then the language of the page must be Hebrew. Of course, as we all know, Hebrew is one of several languages written with the Hebrew alphabet. This becomes somewhat moot when one starts encoding all pages with the charset "utf-8", because then you are telling a browser that any Unicode character, from Armenian to Korean might be present. So, one must take care to also include a meta language tag. As it happens, such tags exist for several relevant languages. The form is:

<meta http-equiv="content-language" content="en-us">

And here are some relevant codes:

(For a complete set, see the W3C's ISO-639 page)

For some browsers, I found it necessary to also indicate text direction if I want words on the web in Hebrew-alphabet-languages to display in the proper visual order. Although this can be expressed as a meta tag, I found it worked much better as shown in this example, from the W3C's Language information and text direction page.

<q lang="he" dir="rtl">...a Hebrew quotation...</q>

I'll have to do some experimenting—I would guess that most of this should be more properly noted in a style sheet so that when you have a paragraph of Hebrew, you would define something like:

<p class="heb"> ... </p<>

Where you have a style sheet for "heb" that includes:

heb lang="yid" {direction: rtl}

where, if I understand CSS correctly, language is an attribute of the style and direction is a property.

And, as you'll see, I managed to get into big layout trouble, despite InDesign generally making this sort of work easier than any other tool I've ever used. (Yes, in part this means that tools for doing multi-lingual typography has generally sucked big-time.)

The other reason to save the tables, of course, is that if you are a reasonable designer, you have turned off all of the stupid rules (in most cases—somewhere, there is always an exception) which are turned on by default. (Jan Tschichold used to note that the use of rules on a table was a sign that something was designed poorly.) and properly set the default stylesheet and paragraph direction for each column. You don't want to have to proofread that more than once per project.

The first tricky part in doing this is to note that InDesign doesn't know how to break a table between pages. If you are working with song lyrics, that means that best practice means that you simply make all of your tables one row deep—each verse is its own table. That lets you insert page breaks as is convenient, and isn't toooooo bad when you adjust the space between verses to enable a particularly tight situation to work. If you are working on a prayer book or something where a paragraph can be longer, be prepared to have some tables contain half of a paragraph, and to manually move text back and forth when edits cause change. Not so fun. But I don't think that any common editors, from Nisus or Word, understand the desirability of being able to allow a table row (if only InDesign were only that limited) between pages. It's just not something that comes up unless you are setting this type of multilingual text, I suspect.

People looking at the sample page that I have put online here will note that I ignored some best practice and used multi-verse columns for parts of this project—knowing better doesn't mean that I can be deterred from quick and dirty, at least some times.

There were a few stretches of English-only - the musician bios and the like. For various reasons, I first set those in my usual (for CD work) two columns. Remember that you don't want to set CD liner notes in one column because at the usual CD text sizes, you end up with lines that are too long to follow: the human eye does about three stretches of 20 characters in text size before you begin to lose track of what line you are reading. That situation will almost always arise if you set one-column CD liner notes.

What wasn't so smart was that I decided to set those English-only two-column bits in regular columns, not tables. This is a natural thought, since that allows text to flow between columns and makes justification and column make-up much simpler than having to manually adjust columns as you would in a table. As you might guess, the combination of changing page columns and awkward tables meant that when the design changed, I had to simply open a new file and page from scratch. In the event, I moved the English to three columns, as well, for design consistency, but used tables 2nd time out. Slightly painful for layout; significantly saner when it comes time (as it may well come) to move the song order and booklet pagination, yet again.

Anyway, the big lessons are (a) use tables for multi-lingual text, don't use columns—this is especially true since in most cases your columns won't be of equal width: Hebrew takes less width than Yiddish; both take less width than transliteration and translation is often in-between the two, yielding percentages of something like "33% for the translation; 27% for the Hebrew; 40% for the transliteration"—adjust as needed to fit the specifics of your text, your language, and (b) don't mix tables and columns in the same document. Bad things will happen and you'll end up starting the layout over from scratch.

But, of course, no one wants to do that any more. And no one should have to: we have lots of tools for editing Hebrew, and Unicode fonts. So, this year, a bit late, as usual, I have redone that minimal Haggadah Toolkit and input the Hebrew using Unicode so that it =should= be possible to cut and paste into whatever tool works for you. Of course, by now, everyone has finished the Haggadah and just needs to print them up for the seder Saturday night, but just in case, the new version is now available. And better, it will still be there next year, maybe with a bit more Hebrew, as I have time.

Passover Haggadah Toolkit, v 0.2

But I didn't come here to complain about ArtScroll typography. That's an ongoing theme of my typographic life and doesn't need to be in each and every post. Instead, I want to kvell about a new Reconstructionist siddur, this one from Congregation Dorshei Emet, the Reconstructionist Synagogue of Montreal. It uses fonts that work together very well (primarily Zapf's Palatino for the English paired with Henri Friedlander's Hadassah for the Hebrew, with some Myriad or similar humanist sans serif for instructions and some translations).

The design is very simple. It's also effective. Grace is provided by the papercuts that begin each section. I like the look of it, obviously. I'll have to daven with it before I know whether or not I can relate to the service, although I have generally felt at home with Reconstructionist services. (When it comes to type, I can be a dogmatic traditionalist in some ways; when it comes to prayer, suddenly I become a Reconstructionist, paraphrasing Mordechai Kaplan: "the past should have a voice, but not a veto"

While I was doing my pre-Passover Haggadah browsing, I found a copy of the Ma'ayan Haggadah put out by the Jewish Women's Project of the Manhattan JCC. (The JCC is also the co-sponsor for some very, very hip evenings with DJ So-Called at the Slipper Room, but that's a subject for the Klezmershack.) If you click on the detail, below, you'll see a nice page that gives a partial sense of the gracious use of space and graphic. I really like the effective use of type and color—note how they manage to present "hebrew | transliteration translation" in the running head, for instance. It is clear and graceful. As I close off this quick entry, I think of it as the opposite of the cacophony of, say, the ArtScroll approach which I presented at the top of this item.

Let's first consider some issues around multilingual typography. First, putting more than one language on a page is distracting. You don't do it without a reason. I have had many wonderful discussions with Maxim Zhukov, now retired, but for many years in charge of printing at the United Nations. He recalls that bilingual texts are not uncommon, but that the usual way of accomodating both languages (except when they need to be together for pedagogic reasons) is to have each language start from a different cover. With Hebrew or Arabic, coupled with a Latin-based language, this is simple. We start each language from the cover that is natural to it, and if there are shared photos or illustrations, they get put in the middle. If the two languages share the same reading direction, one is upside down to the other, generating the same effect. The languages are kept apart, confusion is minimal, and design is simple. It is also common, when mixing more than one similar language, to typeset them in bands, clearly differentiated, but with, say, the top of the page in French, the middle in German, and the bottom in English.

Sometimes, the languages have to appear together in a form makes them appear equal, or that facilitates translation. This is the case in the Polyglot bibles, like the Porro shown here. A few others are in my Polyglots Gallery. For UN purposes, this could come about because the UN has two official languages (French and English), or because of the need to present multilingual documents such that all appear to be equal.

But, in the case of the familiar Hebrew-English siddur that most of us know today, I am going to contend that the layout is an accident, somewhat related to my earlier comments on how one most easily presents two languages: by keeping each out of the other's face. I can easily visualize rabbis or pedagogues realizing that not all congregants would be facile in Hebrew, and trying to find ways to accomodate those who needed help in following along.

I visualize a need to placate those who wanted to keep the English out of the way, so as not to interfere with those who are comfortable without it. You can hear the discussions with traditionalists who ask that, if English must be included, it be put somewhere—on a facing page, for instance—such that it won't get in the way of speed-davenners who, after all, are the backbone of true faith :-). The Hebrew is placed on the recto (right hand) page, of course, because that is the first page when reading from the Hebrew side of the siddur. English goes on the verso (left-hand page).

Most pages are justified, that is, space between words is adjusted so that the right and left margins are straight. It seems to be a general human aesthetic that such margins look "better" to us. This longing for straight, neat margins also expresses itself when both Hebrew and English appear on the same page. We reinforce the idea that Hebrew belongs on the right-hand side of the page, at the greatest distance from the English (on the left-hand side of the page) because that, too, gives us straight margins. If our pages were graphics, and if we ignore the hole in the middle of the page (which most of us do), then this is an excellent solution.

"Dueling alphabets" is also an excellent solution if we are comfortable with the idea that people will look at either the Hebrew, or the English. And there are numerous examples where this is true: the program for an art exhibit, for instance, or a copy of a treaty where each side will read the treaty in a familiar language. Sometimes, this is also true when we combine Hebrew and English translation (as opposed, say, to transliteration, which absolutely must match, even line for line, to be most useful). If the translation isn't "word for word" (and usually it isn't), we may deliberately not want to facilitate the attempt at matching words back and forth because we know that it won't be helpful.

Mostly, though, dueling pages of Hebrew and English is an artifcat that doesn't work for the people for whom the bi-lingual edition was usually prepared: those who are not facile in Hebrew, who want the help of translation or transliteration to aid them in davenning. The result of this "traditional" (traditional only if we consider the last century, not the recorded history of multilingual bibles and siddurim) resembles the ballot in certain Florida counties during the 2000 election: once you know the logic, you can see how you ended up there, but there is no shortage of solutions to the problem that could be/have been offered by experienced typographers that address the issue without causing the awkward side effects (in the case of Hebrew/English, having the languages situated so they least help those for whom both were printed; in Florida, the election reached a different result that might have been counted had the majority vote been correctly recorded).

That's the situation as I currently understand it, based on about 20 years of multilingual typography. If there is irony, it lies in the fact that better layouts are relatively uncommon, and look funny to people. But we're making headway. I'm going to write about two new books next entry.

Comments?