Yemenite Traditions

As I was reading about various b’nai mitzvah practices and customs (there are lots of links out there), I took an interesting detour and learned a bit about Yemenite Torah reading traditions. I thought I would share some of what I learned this week.

At the Mechon Mamre web site, I read that “Yemenite Jews always allowed even children of five or six to take an aliyah.” And the Wikipedia article  on Yemenite Jews adds that “Children under the age of Bar Mitzvah are often given the sixth aliyah. Each verse of the Torah read in Hebrew is followed by the Aramaic translation, usually chanted by a child. Both the sixth aliyah and the Targum have a simplified melody, distinct from the general Torah melody used for the other aliyot.” So Torah reading (leining) was taught from a very young age. The article also notes that “In the Yemenite tradition each person called to the Torah scroll for an aliyah reads for himself.”

I also came across an article by Ephraim Stulberg on the division of aliyot in the weekly parashiyot. He references some research that indicates that the aliyah divisions did not become standardized until some time in the eighteenth century, and that the Yemenite community has its own division that differs in places from the division we see in most books today. I have looked for a table or listing of the Yemenite aliyah divisions, but so far have not yet found that information. Relating this to the Tikkun app that we are developing, this does bring up the need to support the user in selecting any range of verses as a reading to practice; this flexibility will allow the app to serve any user’s tradition.

{ Comments are closed }

Google Drive Integration

As I wrote a few weeks ago, we were working on integrating Google Drive into our Tikkun app. We had all of the key capabilities working for the Android version of the app, and were next diving into doing the same for iOS. Since we are relatively new to iOS and Swift programming, we are always on a learning curve as we start the next part of the project there. And, of course, the way that Android/Java accesses Google Drive differs significantly from the way that iOS/Swift does.

In particular, although calls to Google Drive occur asynchronously, they are handled in Android/Java in a way that basically results in things happening in order, without having to do any special programming. In iOS/Swift, the asynchronous nature of the interactions must be accounted for by the programmer. This led to learning how to use PromiseKit, a third-party Swift library for simplifying asynchronous code.

We are almost done now with bringing the iOS app’s functionality up to the same level as the we already had in the Android app. Next up: designing how user files should be represented in the app, and then how to arrange the user interface to simplify the sharing of files.

{ Comments are closed }

B’nai Mitzvah Tutors & Students

B’nai Mitzvah tutors have a lot of material to cover with their students. They usually work with students for at least six months and often up to a year, typically meeting once per week. The student is expected to practice the weekly lesson diligently, but a week is a long time for a student, and it can be difficult to practice consistently. So we feel that making it easier for students to stay current with the required level of practice should be a key goal of the app we are designing.

How can this be achieved? We have several ideas. First, we would like to make it easy for the student and tutor to check in with each other during the week between lessons, without this becoming burdensome. Tutors often create recordings for students to practice from, and we would like for them to be able to do this directly in the app; tutors would share recordings with their students through the students’ own instances of the app on their phones or tablets. The students would then be able to listen to these recordings wherever they might be, record their own practices of the required material using the app, and then share those practice recordings back with the tutor. The tutor could check for new recordings from their students each day, and contact a student or a student’s family with a friendly reminder to practice if needed.

Second, as the tutor listens to the shared practice recordings from students, the tutor will be able to hear whether the student is on track, or whether the student needs some additional pointers, without waiting until the next meeting. The tutor could, as needed, make another recording for or just send a message to the student to reinforce the lesson. Again, these interactions would happen through the app in a simple way, allowing the tutor and the student to interact between tutoring sessions. Another possibility would be to add a notifications feature to the app that would alert a student if they had not practiced on a day where they should have done so.

As we move forward in the design of the app, we will be looking at which features will best assist students in being regular about their practice between lessons, as well as features that will enhance communication between students and tutors.

{ Comments are closed }

Leining (Torah reading)

We are building a Tikkun app to help Torah readers. To make it worth using, it needs to support the ways that Torah readers (leiners) like to study. I found a good discussion about how leiners practice at the website. In case you are not familiar with it, this website (also called “mi yodeya”) is a very interesting discussion group for all Judaism-related topics.

Here are some of the recommendations from that discussion:

Chunking: Break the reading up into chunks, and master one chunk at a time. The size of the chunks depends on the reader’s skill level, the section being read, and perhaps other factors.

Understand Hebrew grammar and vocabulary: The more that the reader knows, the easier it will be to get the vowels correct.

Understand the trop system: Knowing the trop patterns and how they are typically used simplifies memorization.

Record/listen: Recording yourself (after you have practiced for a while), and then listening to yourself, can help identify tricky problems.

Schedule: Set up a practice schedule and stick to it.

As we look at what features to build into the app, we will be thinking about how to support as many of these approaches as we can, in addition to the file sharing features that we have been working on to support tutors and their students.

{ Comments are closed }

Deeper into Google Drive

This week I want to update you on our efforts in integrating Google Drive into our Tikkun app. As I wrote last month, we decided that Google Drive provided the best solution at present for giving iOS and Android users a way to share content with each other directly through our app. It will also give users a way to sync their own content and app preferences across multiple devices. In order to make sharing and syncing “just work” for our app, we needed to get a deep understanding of how Google Drive operates, and then how to program the desired functionality. So we have been doing a lot of reading and experimenting, learning how to securely log in and out of Google Drive, create, find or delete a particular folder or file, how to use our own custom file types, and so on. (For those with a technical background, we are using the Google Drive REST API.) We have been able to log in and out of Google Drive on both the iOS and Android versions of our app. We have so far only tested out the various file and folder operations on Android. We will soon move on to doing the same operations of iOS.

Another critical aspect of integrating Google Drive into our app is handling any error conditions that might occur. In particular, the app will need to respond reasonably if a file or folder that is requested is not available. This could be because the item was deleted, or because there is no network connection. Further, if a network connection is metered (i.e., it uses data on a data plan), the app should not make that connection without the explicit permission from the user.

Once we have the level of control that we need in both iOS and Android, we will start looking at how to present information about the user’s content on various sizes of screens. We also need to refine exactly what data we need to store for the user, and how best to organize it. User data management is at the core of what will make the app really useful, and it will, undoubtedly, take some time to get it right.

{ Comments are closed }

Unusual Letter Forms in Tanach

As I wrote about in my previous blog post, one of the reasons that we are developing our own STaM fonts is to better handle the various unusual letter forms in Tanach. Examples include the enlarged bet that begins the Torah, the enlarged ayin in the word שמע, the small alef in the word ויקרא, and the inverted nuns in Numbers 35. It would, of course, be a lot of work for me to research all of these unusual letter forms, were it not for a number of very thorough papers that have been published on the subject. So if you are interested in the subject, here are the links to resources that I have been using:

Typographic details in the Hebrew Bible (Andries E. Brouwer): This paper collects examples from many different sources, and provides extensive, categorized lists of unusual letter forms.

Typesetting the Holy Bible in Hebrew, with TEX (Yannis Haralambous): This paper is concerned with typesetting Biblical text, and provides lists of typographical oddities and how to typeset them using the TEX system.

Also, this chart list all of the unusual letter forms just in Torah: טבלת השינויים בספר תורה (הראל לוי)‏‏

{ Comments are closed }

STaM fonts for our apps

Font development has always been a key part of our work. The accurate display of Biblical Hebrew on mobile devices has been one of the distinguishing features of the apps we have built. For many years, we used a proprietary technology for rendering fully-pointed Hebrew. The fonts were bitmaps and the layout engine was developed by us based on the ideas presented by Yannis Haralambous in his paper, “Typesetting the Holy Bible in Hebrew.” This technology worked well, but could not take advantage of improvements in font handling on mobile platforms. With those improvements — in particular, support for OpenType fonts — we developed our own OpenType font for Biblical Hebrew, tailored to the specifics of Android behavior. This font was modeled on our bitmap font and layout engine. Then, as we moved on to cross-platform development — adding iOS to our work — one of the first steps we took was to tweak our Hebrew OpenType font to also handle the specifics of iOS behavior.

Next, with the idea for an app that would show a two-column Tikkun-style layout of the Torah text, with the fully-pointed Hebrew on the right and the unpointed Hebrew on the left, we needed to have a font for the unpointed text that would be in the style appropriate for sifrei Torah, tefillin and mezuzot. This style is know as STaM (סת״ם). As I began working on creating a new font in this style, I learned that there are a number of different traditions for how to form the letters. The three most common traditions are the two Ashkenzai styles — Beis Yosef and Arizal — and the Sephardic tradition. This YouTube video was helpful to me in learning about the distinguishing features of each style. Once I knew about these distinctions, I realized that I should create three fonts, not one.

Of course, you may wonder why we did not just use any of the existing STaM fonts. As I mentioned earlier, we already had an OpenType font for Biblical Hebrew that provided excellent readability on Android and iOS. Now we wanted STaM fonts whose metrics would match. If both the Biblical Hebrew font and the STaM font have the same font metrics, then in a two-column presentation, at any font size, the words on each line take up the same amount of space, with the same line height. Having everything match ensures that the two columns of text look equally well-aligned and well-spaced.  Additionally, we wanted to be able to show the various special letter forms that are in a Torah. These include the large and small letters, the broken vav and the closed qof. By creating our own fonts, we can add any special forms that we want. So doing our own fonts was an easy choice to make, given the appearance standards we wanted to achieve. I am currently working on adding all of the special letter forms to our three StaM fonts.

Write to me directly at

{ Comments are closed }

File sharing & Google Drive

As I wrote last week, we are working on how to support users in sharing their study materials with one another, regardless of whether they have iOS or Android devices. I want to present some additional background about our goals and our approach. First, we want to enable the sharing of study materials entirely through the apps we are building, and in as simple a manner as possible. We do not want users to have to use their desktop or laptop computers as intermediary devices, or have to switch to email, another app, or a web page to share something. This means that the file sharing protocols must all be accessible programmatically from within our apps. We also want users to fully own and manage their study materials, without us keeping any copies of them or other related data on some server that we manage. Each user’s data should be entirely under their own control, so they can be comfortable that their data is not being used in any unknown ways or for any purposes other than what they want. Additionally, sharing can be useful to users by themselves. Users who own more than one mobile device — for example, an iPad and an Android phone — may want to use our apps on each device, and have all of their study materials synced between those different devices. And whenever users upgrade to new mobile devices, they need a straightforward way to transfer all of their study materials from the old device to the new one.

With these goals in mind, we settled on Google Drive as the most promising technology to use. Google Drive also stood out because of the continuing surge in the use of Chromebooks and related Google services by students in elementary and secondary schools, especially in the United States. This is important since we are looking to have our apps used by b’nai mitzvah students and their tutors. If students are already familiar with Google services like Google Drive, it will make using our apps that much more straightforward for them. A recent article in the New York Times noted that, “In 2016, Chromebooks accounted for 58 percent of mobile devices shipped to primary and secondary schools in the United States,” and that “more than half the nation’s primary- and secondary-school students — more than 30 million children — use Google education apps like Gmail and Docs.” Also, Google Drive is free for anyone to use, with generous data limits.

So we are now deep into the technical details of accessing the Google Drive functionality within our Android and iOS apps. This is actually more complicated in Android than in iOS, because in iOS, there is only one way to do things. In Android, there are multiple supporting technologies, and it requires some extra effort to determine which approach will give us the right services for our needs. And, of course, newer versions of Android work differently than older versions, so that also has to be taken into account. Further, on Android, a user is basically already signed in to Google, so we want to take advantage of that and streamline the process for the user. That means doing more behind the scenes programming to make everything “just happen.” And that’s where we are this week.

We are always happy to hear from you. Write to me directly at

{ Comments are closed }

Subscription option

Thanks to several readers who let us know that they would like to be notified by email about updates to our blog! Just sign up using the form in the right margin, and you will always know when we publish a new post.

I am still on a learning curve in terms of using WordPress, so if something doesn’t look right or function as expected, please let me know about it. You can always contact me directly at

{ Comments are closed }

Welcome to our blog

Thank you to everyone who has subscribed to our Hebrew in Hand Newsletter for so many years! I look forward to staying in touch with you about our work through this blog, which will be updated regularly. I plan to tweet whenever there is an update — find us @hebrewinhand. Visit us here anytime to find out what we are up to. As always, we want to hear from you. Please share your thoughts and questions directly with me at:

In case you have just found us, here is a quick summary of who we are and what we are doing. ZigZag, Inc. is a small software development company, and for many years we have been creating mobile apps of Judaic and Hebrew interest. As part of our work, we have created Android apps, web apps and fonts for accurately displaying Biblical Hebrew on mobile devices. We have recently added iOS apps to our development repertoire. Our most well-known apps are Tanach Bible and My Tanach, both for Android. They were done in partnership with Davka Corporation, and are sold through them.

Late last year, we began exploring the idea of creating a cross-platform Tikkun app — for both iOS and Android — for leiners (Torah readers) and b’nai mitzvah tutors and students. Our first task was to determine whether to use a cross-platform development environment, or to code each app natively. After studying the most promising cross-platform options, we decided to try using Nativescript to code the core of the app — the two-column display of Torah text, pointed text on the right and unpointed text on the left, with fully-justified lines,  predetermined line-breaks, and extra space at specific points within a line of text. This is a very demanding layout to handle. And we found that the cross-platform environment was just too limited for it to work. We then moved on to creating two separate apps, each coded natively. Both apps can display the two-column Tikkun text, plus handle a few user preferences. Here is the two-column text displayed on an iPad:

The next major technical area that we needed to work through was how to share study materials between users, no matter which platform each might be using. It clearly would not be enough for iOS users to only share with iOS users and Android users to only share with Android users. Again, we studied the various technologies for sharing data between users on different platforms, and settled on Google Drive as being the best candidate for our needs. We implemented a very limited proof-of-concept sharing feature in both the iOS and Android environments, and are now expanding that work to include the standard user interface features that users will expect. We now have the ability to securely sign in and out of Google drive accounts. We are next working on the internal mechanisms for sharing a specific file with a specific user directly through the app.

And that is where we are today.

{ Comments are closed }