Customer left behind

I bought a tablet a year ago with the primary goal of using it with Logos. I study Greek and Hebrew extensively. I discovered that the Hebrew font did not display correctly. I got on forums and there was much discussion. Over time, news came out that apparently the problem is due to Android not Logos. Confirmation was then provided when the release of Jelly Bean 4.2 "fixed" it. So now it's all good right?

Well not at all. I spent countless hours trying to find out whether I could upgrade my tablet. I now know that it is not currently possible and most likely will never be.

Meanwhile, one question has never really been answered: how come there are other software that are able to display Hebrew correctly? The answer I found out was that they developed a custom solution that enabled them not to be bound to Android's restrictions. Since this point has been brought up in the discussions but the answer has continued to be that we should upgrade Android, it would seem that the underlying message is "we are not willing to work on a custom made solution of our own".

The net result? People like me are essentially being told: too bad, either buy yourself more hardware or else renounce reading Hebrew in Logos on your tablet.

I would like to think that hopefully having people buy new hardware will not the solution when there are bugs. And I would like to make a plea to reconsider this "solution" and be mindful of those who cannot upgrade if at all possible.

Find more posts tagged with

Mobile App

Comments

Kenneth Neighoff

I guess it is easy to say it is Android that has the problem with Hebrew not displaying correctly, but I wonder why on the Kindle Fire, 1st generation, I use Olive Tree and the Hebrew displays correctly, but in Logos it does not. So if it is Android, Olive Tree should have the same problem.

So I wonder what Olive Tree does differently that Logos is not able to do.

Gabe Martin

We brought up our concern with Hebrew text rendering in Android with Google via Android Developer hours here: http://youtu.be/Lz8GIc6bPk8?t=1m7s

As you can see they did acknowledge it as a platform bug and one that would be fixed in an upcoming Android release.

We then followed up with another question asking if we should implement a custom solution so that older versions of Android would be able to support hebrew rendering and were told that it would not be a good idea to do so. http://youtu.be/Lz8GIc6bPk8?t=30m52s

Francis

https://community.logos.com/discussion/comment/464387#Comment_464387

Well, I know this has been the official answer but I just don't understand how smaller companies like Olive Tree can do it and Logos apparently can't. Even though this question has been raised a number of times, there is yet to be any answer to it.

Vincent Setterholm

https://community.logos.com/discussion/comment/465373#Comment_465373

So I wonder what Olive Tree does differently that Logos is not able to do.

I don't know anything about their platform, so I can't say which it is, but I'm pretty sure it'd be one or more of three things:

1) A custom font that doesn't use Open Type tables for complex script layout.

2) Using a different text rendering engine than what comes with the Android OS.

3) Using an old ASCII font for display.

In reverse order:

A number of Bible Software companies that have been around a long time have code for working with left-to-right ASCII fonts and faking right-to-left behavior, and several still use that in their applications, even if they can export Unicode into a word processor or accept Unicode input for searching. That was the best way to go on many non-Windows platforms up until very recently. Since we started out as a Windows-only shop, we had the luxury of moving to Unicode very early. Unicode has a lot of significant advantages, like being able to type a language in logical order rather than type it 'backwards', programs can handle word-wrapping automatically and properly without writing special hacks or hard-coding all your line breaks, searching can work out of the box because you don't have to code a lot of custom smarts in for the graphic approach of using an ASCII font (things like needing to use a different code for the same vowel depending which consonant it is under or whether it has an adjacent accent and using the same code point for a shin dot as for a holem on the right side of an aleph or other hacks that have more to do with making the script look proper than being easy to search and index - though if all your searching is based on touching words rather than typing them, you can get away with not solving problems related to how users input text - you just search on exactly what they touched and don't have to worry about the unintuitive nature of the ASCII data entry) and being able to switch fonts at will because Unicode is a published standard while all the ASCII fonts are custom hacks. ASCII may still have an edge up on Unicode for certain technical typesetting tasks - though I'm not sure about that, having never myself used professional typesetting tools with modern Hebrew fonts.

There are alternate text rendering engines out there, some of which are cross-platform and open source. I know this is something we've looked into in order to make sure our texts render the same on all devices, so eventually we may have a cross-platform solution, rather than having to negotiate text rendering bug fixes with each platform separately. There are some limitations to this approach on some devices. For example we did use a different rendering engine in our Mac software (not sure what we're doing now that Macs do a better job natively), but the OS wouldn't allow us to change the engine for UI elements, so at one point Hebrew looked good when reading books, but not so much in other areas of the app (like on right-click menus). Some of this can be designed around (by doing things like stripping vowels out of the menu items).

For years when Apple wasn't rendering Open Type Hebrew properly, the official solution was supposed to be something like: go make an Apple font. But there didn't seem to be any takers on the idea of spending all the time and money necessary to make a good Unicode biblical Hebrew font that could only be used on a Mac (or maybe someone tried that and it didn't work as well as they hoped). But since Android uses the same rendering engine as iOS (just an older version in the case of your first-gen Kindle Fire), it's theoretically possible that someone did just that. There's also the possibility of making a font that doesn't use layout tables at all, but just applies negative spacing to the combining marks so they appear more or less in the right spot. But since Hebrew letters have different widths, and because of the way accents and vowels often have to share space under a letter, there's no way to make cantillated Unicode Hebrew this way that is as beautiful as an Open Type font can be.

While designing a new font or implementing ASCII hacks are not really options for us, we are investigating alternate text rendering options, so it may be that someday we'll have a solution that works well on old versions of the Android OS. But I have no idea how close we are in this investigation.

I have a first generation Kindle Fire, too, so I feel your pain. I'm pretty bummed about being locked into Amazon's custom Android build that never seems to get updated as Android pushes ahead. My next tablet device will be an iPad or a real Android tablet that can be updated as the OS improves.

BKMitchell

https://community.logos.com/discussion/comment/465392#Comment_465392

I have a first generation Kindle Fire, too, so I feel your pain. I'm pretty bummed about being locked into Amazon's custom Android build that never seems to get updated as Android pushes ahead. My next tablet device will be an iPad or a real Android tablet that can be updated as the OS improves.

Well, there is another solution to the problem, but it's not for the faint of heart check this out(same post different link):

http://www.gadgettweet.com/2012/12/install-android-jelly-bean-on-original-kindle-fire.html

http://liliputing.com/2012/12/install-android-4-2-on-the-original-amazon-kindle-fire.html