Tamil and other fonts in ODK Collect

Christopher_Robert · January 31, 2012, 6:17am

Dear all,

We're piloting ODK for a series of surveys in rural Tamil Nadu, in Southern
India. Our surveyors don't know English and most of them would not
understand any transliterated version of Tamil, so it's important that our
surveys use the Tamil script. So far, our options seem to be:

Use the Samsung Galaxy Y or Galaxy Note, since both of these show
Unicode Tamil in our ODK surveys right out of the box. The trouble is, the
Galaxy Y's on-screen keyboard is a touch too small, and the Galaxy Note is
way too expensive.
"Root" our devices and hand-install Tamil fonts. In principle, this can
work with any device, but frankly we are scared. We would like to use the
Motorola Fire, for example, but its rooting procedure seems particularly
sketchy and ill-defined. Even if a tech wizard can root a device and
install the font successfully, it seems a tall order to do this to every
device we purchase.

My impression is that ODK implementers typically punt on this issue, either
using English or some transliterated version of the local language, in
order to avoid needing support for different fonts. If any of you have had
success with other Unicode fonts, would you share your experiences? Did you
go with devices that happened to have those fonts pre-installed, or did you
go the rooting route? Any advice would be greatly appreciated.

Thank you very much,

Chris

P.S. The issue goes beyond whether a font is or isn't present. For example,
Spice's budget tablet supports Tamil text, but shows it in an archaic,
formal script that many cannot understand.

yanokwa · January 31, 2012, 6:21am

Another option is to use images instead of text for the question text.
We've done that for some Hindi forms and it works pretty well.

···

On Mon, Jan 30, 2012 at 22:17, Christopher Robert wrote: > Dear all, > > We're piloting ODK for a series of surveys in rural Tamil Nadu, in Southern > India. Our surveyors don't know English and most of them would not > understand any transliterated version of Tamil, so it's important that our > surveys use the Tamil script. So far, our options seem to be: > > 1. Use the Samsung Galaxy Y or Galaxy Note, since both of these show Unicode > Tamil in our ODK surveys right out of the box. The trouble is, the Galaxy > Y's on-screen keyboard is a touch too small, and the Galaxy Note is way too > expensive. > > 2. "Root" our devices and hand-install Tamil fonts. In principle, this can > work with any device, but frankly we are scared. We would like to use the > Motorola Fire, for example, but its rooting procedure seems particularly > sketchy and ill-defined. Even if a tech wizard can root a device and install > the font successfully, it seems a tall order to do this to every device we > purchase. > > My impression is that ODK implementers typically punt on this issue, either > using English or some transliterated version of the local language, in order > to avoid needing support for different fonts. If any of you have had success > with other Unicode fonts, would you share your experiences? Did you go with > devices that happened to have those fonts pre-installed, or did you go the > rooting route? Any advice would be greatly appreciated. > > Thank you very much, > > Chris > > P.S. The issue goes beyond whether a font is or isn't present. For example, > Spice's budget tablet supports Tamil text, but shows it in an archaic, > formal script that many cannot understand. > > -- > Post: opendatakit@googlegroups.com > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > Options: http://groups.google.com/group/opendatakit?hl=en

Christopher_Robert · January 31, 2012, 6:33am

Dear Yaw,

Thanks for the lightning-fast reply!

My big worry with images is just the practical difficulty associated with
creating appropriately-sized/wrapped images, uploading them, etc. Right now
we use XLS2XForm and the RA team can very easily manage the surveys
themselves. It looks like XLS2XForm supports a media:image column, however,
so maybe the only complication is making images that are sized and wrapped
appropriately. Did you have good luck with a particular software package
for image-creation and -editing? I suppose we'd just need to come up with
the question-image dimensions that work best on our device of choice, then
standardize on a software package and font for creating images of that
size. I'd be grateful for any additional advice from your Hindi experience.

Thanks,

Chris

···

On Tuesday, January 31, 2012, Yaw Anokwa wrote:

Another option is to use images instead of text for the question text.
We've done that for some Hindi forms and it works pretty well.

On Mon, Jan 30, 2012 at 22:17, Christopher Robert <chris_robert@hksphd.harvard.edu <javascript:;>> wrote:

Dear all,

We're piloting ODK for a series of surveys in rural Tamil Nadu, in
Southern
India. Our surveyors don't know English and most of them would not
understand any transliterated version of Tamil, so it's important that
our
surveys use the Tamil script. So far, our options seem to be:

Use the Samsung Galaxy Y or Galaxy Note, since both of these show
Unicode
Tamil in our ODK surveys right out of the box. The trouble is, the Galaxy
Y's on-screen keyboard is a touch too small, and the Galaxy Note is way
too
expensive.

"Root" our devices and hand-install Tamil fonts. In principle, this
can
work with any device, but frankly we are scared. We would like to use the
Motorola Fire, for example, but its rooting procedure seems particularly
sketchy and ill-defined. Even if a tech wizard can root a device and
install
the font successfully, it seems a tall order to do this to every device
we
purchase.

My impression is that ODK implementers typically punt on this issue,
either
using English or some transliterated version of the local language, in
order
to avoid needing support for different fonts. If any of you have had
success
with other Unicode fonts, would you share your experiences? Did you go
with
devices that happened to have those fonts pre-installed, or did you go
the
rooting route? Any advice would be greatly appreciated.

Thank you very much,

Chris

P.S. The issue goes beyond whether a font is or isn't present. For
example,
Spice's budget tablet supports Tamil text, but shows it in an archaic,
formal script that many cannot understand.

--
Post: opendatakit@googlegroups.com <javascript:;>
Unsubscribe: opendatakit+unsubscribe@googlegroups.com <javascript:;>
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com <javascript:;>
Unsubscribe: opendatakit+unsubscribe@googlegroups.com <javascript:;>
Options: http://groups.google.com/group/opendatakit?hl=en

Christopher_Robert · January 31, 2012, 9:40am

Sorry, but a related question: has anybody tried embedding a font with a
custom-built ODK Collect? Since individual Android apps are supposed to be
able to embed their own Unicode fonts, this seems like it could be one
potential solution.

Thanks again to all for the ideas and assistance,

Chris

···

On Tuesday, January 31, 2012, Christopher Robert wrote:

Dear all,

We're piloting ODK for a series of surveys in rural Tamil Nadu, in
Southern India. Our surveyors don't know English and most of them would not
understand any transliterated version of Tamil, so it's important that our
surveys use the Tamil script. So far, our options seem to be:

Use the Samsung Galaxy Y or Galaxy Note, since both of these show
Unicode Tamil in our ODK surveys right out of the box. The trouble is, the
Galaxy Y's on-screen keyboard is a touch too small, and the Galaxy Note is
way too expensive.

"Root" our devices and hand-install Tamil fonts. In principle, this can
work with any device, but frankly we are scared. We would like to use the
Motorola Fire, for example, but its rooting procedure seems particularly
sketchy and ill-defined. Even if a tech wizard can root a device and
install the font successfully, it seems a tall order to do this to every
device we purchase.

My impression is that ODK implementers typically punt on this issue,
either using English or some transliterated version of the local language,
in order to avoid needing support for different fonts. If any of you have
had success with other Unicode fonts, would you share your experiences? Did
you go with devices that happened to have those fonts pre-installed, or did
you go the rooting route? Any advice would be greatly appreciated.

Thank you very much,

Chris

P.S. The issue goes beyond whether a font is or isn't present. For
example, Spice's budget tablet supports Tamil text, but shows it in an
archaic, formal script that many cannot understand.

Carl_Hartung · January 31, 2012, 4:59pm

I know people have tried to add fonts like Hindi on the system level, but I
think Android lacks the proper rendering support for several scripting
languages. That is, it can display the fonts, but given a glyph that can
have 3 or so different placements to mean different things, it always puts
them in the first spot. I don't know of anyone who has tried adding
Devangari to ODK, but I have used applications that reportedly support
Hindi only to have boxes show up on my phone instead.

If you look at the Android release notes, they purportedly started
supporting Hindi around Android 2.2 or 2.3. I'm not sure what their
definition of "support" is, but I've never seen Hindi work on a
non-customized build, and there are only a few phones I've heard of with
proprietary builds that support it.

The relevant android bug is here:
http://code.google.com/p/android/issues/detail?id=4153

···

On Tue, Jan 31, 2012 at 1:40 AM, Christopher Robert < chris_robert@hksphd.harvard.edu> wrote:

Sorry, but a related question: has anybody tried embedding a font with a
custom-built ODK Collect? Since individual Android apps are supposed to be
able to embed their own Unicode fonts, this seems like it could be one
potential solution.

Thanks again to all for the ideas and assistance,

Chris

On Tuesday, January 31, 2012, Christopher Robert wrote:

Dear all,

We're piloting ODK for a series of surveys in rural Tamil Nadu, in
Southern India. Our surveyors don't know English and most of them would not
understand any transliterated version of Tamil, so it's important that our
surveys use the Tamil script. So far, our options seem to be:

Use the Samsung Galaxy Y or Galaxy Note, since both of these show
Unicode Tamil in our ODK surveys right out of the box. The trouble is, the
Galaxy Y's on-screen keyboard is a touch too small, and the Galaxy Note is
way too expensive.

"Root" our devices and hand-install Tamil fonts. In principle, this
can work with any device, but frankly we are scared. We would like to use
the Motorola Fire, for example, but its rooting procedure seems
particularly sketchy and ill-defined. Even if a tech wizard can root a
device and install the font successfully, it seems a tall order to do this
to every device we purchase.

My impression is that ODK implementers typically punt on this issue,
either using English or some transliterated version of the local language,
in order to avoid needing support for different fonts. If any of you have
had success with other Unicode fonts, would you share your experiences? Did
you go with devices that happened to have those fonts pre-installed, or did
you go the rooting route? Any advice would be greatly appreciated.

Thank you very much,

Chris

P.S. The issue goes beyond whether a font is or isn't present. For
example, Spice's budget tablet supports Tamil text, but shows it in an
archaic, formal script that many cannot understand.

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

yanokwa · January 31, 2012, 5:16pm

I believe you can also add the font to the application itself, but
like Carl pointed out, the positioning problem will still exist.

···

On Tue, Jan 31, 2012 at 08:59, Carl Hartung wrote: > I know people have tried to add fonts like Hindi on the system level, but I > think Android lacks the proper rendering support for several scripting > languages. That is, it can display the fonts, but given a glyph that can > have 3 or so different placements to mean different things, it always puts > them in the first spot. I don't know of anyone who has tried adding > Devangari to ODK, but I have used applications that reportedly support Hindi > only to have boxes show up on my phone instead. > > If you look at the Android release notes, they purportedly started > supporting Hindi around Android 2.2 or 2.3. I'm not sure what their > definition of "support" is, but I've never seen Hindi work on a > non-customized build, and there are only a few phones I've heard of with > proprietary builds that support it. > > The relevant android bug is here: > http://code.google.com/p/android/issues/detail?id=4153 > > > > > > On Tue, Jan 31, 2012 at 1:40 AM, Christopher Robert wrote: >> >> Sorry, but a related question: has anybody tried embedding a font with a >> custom-built ODK Collect? Since individual Android apps are supposed to be >> able to embed their own Unicode fonts, this seems like it could be one >> potential solution. >> >> Thanks again to all for the ideas and assistance, >> >> Chris >> >> >> On Tuesday, January 31, 2012, Christopher Robert wrote: >>> >>> Dear all, >>> >>> We're piloting ODK for a series of surveys in rural Tamil Nadu, in >>> Southern India. Our surveyors don't know English and most of them would not >>> understand any transliterated version of Tamil, so it's important that our >>> surveys use the Tamil script. So far, our options seem to be: >>> >>> 1. Use the Samsung Galaxy Y or Galaxy Note, since both of these show >>> Unicode Tamil in our ODK surveys right out of the box. The trouble is, the >>> Galaxy Y's on-screen keyboard is a touch too small, and the Galaxy Note is >>> way too expensive. >>> >>> 2. "Root" our devices and hand-install Tamil fonts. In principle, this >>> can work with any device, but frankly we are scared. We would like to use >>> the Motorola Fire, for example, but its rooting procedure seems particularly >>> sketchy and ill-defined. Even if a tech wizard can root a device and install >>> the font successfully, it seems a tall order to do this to every device we >>> purchase. >>> >>> My impression is that ODK implementers typically punt on this issue, >>> either using English or some transliterated version of the local language, >>> in order to avoid needing support for different fonts. If any of you have >>> had success with other Unicode fonts, would you share your experiences? Did >>> you go with devices that happened to have those fonts pre-installed, or did >>> you go the rooting route? Any advice would be greatly appreciated. >>> >>> Thank you very much, >>> >>> Chris >>> >>> P.S. The issue goes beyond whether a font is or isn't present. For >>> example, Spice's budget tablet supports Tamil text, but shows it in an >>> archaic, formal script that many cannot understand. >>> >> -- >> Post: opendatakit@googlegroups.com >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >> Options: http://groups.google.com/group/opendatakit?hl=en > > > -- > Post: opendatakit@googlegroups.com > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > Options: http://groups.google.com/group/opendatakit?hl=en

Matt_Berg · January 31, 2012, 6:44am

Chris,

We're experiencing many of the same issues trying to get Kannada support
working.

We are about to work on something that we hope will help provide a
temporary fix to this problem for those who use XLS2XForm.

First, due to the great work of Nathan Breit on the ODK team we'll be
releasing an updated spec of XLS2XForm very soon that consolidates some of
the differences between the ODK and formhub/xform.childcount.org versions.
We've also simplified the syntax a bit and provided better support for
multimedia / calculations, etc. We hope to share more details on this very
soon.

Back to this language issue. We're planning on modifying XLS2XForm to
automatically generate the text into images and then automatically link
them properly in the xform to represent question labels, option labs and
hints. If you have any question, Prabhas who is the main person behind
this will have more details. This doesn't get around the issue of data
entry but we think it'll at least be helpful in providing a temporary fix
to many of these issues.

We'll let you know when we are closer to having something to show.

Thanks,

Matt

···

On Tue, Jan 31, 2012 at 9:33 AM, Christopher Robert < chris_robert@hksphd.harvard.edu> wrote:

Dear Yaw,

Thanks for the lightning-fast reply!

My big worry with images is just the practical difficulty associated with
creating appropriately-sized/wrapped images, uploading them, etc. Right now
we use XLS2XForm and the RA team can very easily manage the surveys
themselves. It looks like XLS2XForm supports a media:image column, however,
so maybe the only complication is making images that are sized and wrapped
appropriately. Did you have good luck with a particular software package
for image-creation and -editing? I suppose we'd just need to come up with
the question-image dimensions that work best on our device of choice, then
standardize on a software package and font for creating images of that
size. I'd be grateful for any additional advice from your Hindi experience.

Thanks,

Chris

On Tuesday, January 31, 2012, Yaw Anokwa wrote:

Another option is to use images instead of text for the question text.
We've done that for some Hindi forms and it works pretty well.

On Mon, Jan 30, 2012 at 22:17, Christopher Robert chris_robert@hksphd.harvard.edu wrote:

Dear all,

We're piloting ODK for a series of surveys in rural Tamil Nadu, in
Southern
India. Our surveyors don't know English and most of them would not
understand any transliterated version of Tamil, so it's important that
our
surveys use the Tamil script. So far, our options seem to be:

Use the Samsung Galaxy Y or Galaxy Note, since both of these show
Unicode
Tamil in our ODK surveys right out of the box. The trouble is, the
Galaxy
Y's on-screen keyboard is a touch too small, and the Galaxy Note is way
too
expensive.

"Root" our devices and hand-install Tamil fonts. In principle, this
can
work with any device, but frankly we are scared. We would like to use
the
Motorola Fire, for example, but its rooting procedure seems particularly
sketchy and ill-defined. Even if a tech wizard can root a device and
install
the font successfully, it seems a tall order to do this to every device
we
purchase.

My impression is that ODK implementers typically punt on this issue,
either
using English or some transliterated version of the local language, in
order
to avoid needing support for different fonts. If any of you have had
success
with other Unicode fonts, would you share your experiences? Did you go
with
devices that happened to have those fonts pre-installed, or did you go
the
rooting route? Any advice would be greatly appreciated.

Thank you very much,

Chris

P.S. The issue goes beyond whether a font is or isn't present. For
example,
Spice's budget tablet supports Tamil text, but shows it in an archaic,
formal script that many cannot understand.

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

Christopher_Robert · January 31, 2012, 7:21am

Hi Matt,

Thanks for the reply -- and for the ray of hope. Auto-generating the images
is a great idea -- though of course it's somewhat absurd that the Android
platform would force us into such contortions!

I suppose that the image auto-generator will need to take a few parameters,
namely the image width and perhaps a preferred font size. I'll eagerly
await more news on this, as it does sound like it will make our lives much
easier.

This talk of updates to XLS2XForm makes me wonder: do you recommend that
users install and run their own XLS2XForm server instances? I'm sure that
you'll seek to maintain backward compatibility in new updates, but if I
have an RA team trained on a particular version, and a bunch of surveys
developed for that version, then it seems like I might like to have that
version of XLS2XForm running someplace safe, in case of small updates to
the surveys. Is that encouraged/supported?

Thanks again,

Chris

···

On Tuesday, January 31, 2012, Matt Berg wrote:

Chris,

We're experiencing many of the same issues trying to get Kannada support
working.

We are about to work on something that we hope will help provide a
temporary fix to this problem for those who use XLS2XForm.

First, due to the great work of Nathan Breit on the ODK team we'll be
releasing an updated spec of XLS2XForm very soon that consolidates some of
the differences between the ODK and formhub/xform.childcount.orgversions. We've also simplified the syntax a bit and provided better
support for multimedia / calculations, etc. We hope to share more details
on this very soon.

Back to this language issue. We're planning on modifying XLS2XForm to
automatically generate the text into images and then automatically link
them properly in the xform to represent question labels, option labs and
hints. If you have any question, Prabhas who is the main person behind
this will have more details. This doesn't get around the issue of data
entry but we think it'll at least be helpful in providing a temporary fix
to many of these issues.

We'll let you know when we are closer to having something to show.

Thanks,

Matt

On Tue, Jan 31, 2012 at 9:33 AM, Christopher Robert < chris_robert@hksphd.harvard.edu> wrote:

Dear Yaw,

Thanks for the lightning-fast reply!

My big worry with images is just the practical difficulty associated with
creating appropriately-sized/wrapped images, uploading them, etc. Right now
we use XLS2XForm and the RA team can very easily manage the surveys
themselves. It looks like XLS2XForm supports a media:image column, however,
so maybe the only complication is making images that are sized and wrapped
appropriately. Did you have good luck with a particular software package
for image-creation and -editing? I suppose we'd just need to come up with
the question-image dimensions that work best on our device of choice, then
standardize on a software package and font for creating images of that
size. I'd be grateful for any additional advice from your Hindi experience.

Thanks,

Chris

On Tuesday, January 31, 2012, Yaw Anokwa wrote:

Another option is to use images instead of text for the question text.
We've done that for some Hindi forms and it works pretty well.

On Mon, Jan 30, 2012 at 22:17, Christopher Robert chris_robert@hksphd.harvard.edu wrote:

Dear all,

We're piloting ODK for a series of surveys in rural Tamil Nadu, in
Southern
India. Our surveyors don't know English and most of them would not
understand any transliterated version of Tamil, so it's important that
our
surveys use the Tamil script. So far, our options seem to be:

Use the Samsung Galaxy Y or Galaxy Note, since both of these show
Unicode
Tamil in our ODK surveys right out of the box. The trouble is, the
Galaxy
Y's on-screen keyboard is a touch too small, and the Galaxy Note is
way too
expensive.

"Root" our devices and hand-install Tamil fonts. In principle, this
can
work with any device, but frankly we are scared. We would like to use
the
Motorola Fire, for example, but its rooting procedure seems
particularly
sketchy and ill-defined. Even if a tech wizard can root a device and
install
the font successfully, it seems a tall order to do this to every
device we
purchase.

My impression is that ODK implementers typically punt on this issue,
either
using English or some transliterated version of the local language, in
order
to avoid needing support for different fonts. If any of you have had
success
with other Unicode fonts, would you share your experiences? Did you go
with
devices that happened to have those fonts pre-installed, or did you go
the
rooting route? Any advice would be greatly appreciated.

Thank you very much,

Chris

P.S. The issue goes beyond whether a font is or isn't present. For
example,
Spice's budget tablet supports Tamil text, but shows it in an archaic,
formal script that many cannot understand.

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

Emily_Kumpel1 · January 31, 2012, 9:18pm

The new release of Android, 4.0, includes support for some Indic
scripts (Devanagari, Tamil, and Bengali). It seems Tamil works in
some applications: http://microblog.ravidreams.net/android-ics-support-for-tamil-indic-languages/
and that some 2011 phones will likely be getting an upgrade soonish
(http://www.techradar.com/news/phone-and-communications/mobile-phones/
android-4-0-release-date-when-will-you-get-it--1048272), which means
there would be affordable options.

Would this mean that ODK would be able to show these fonts if the
phone has Android 4.0?

The new $60 Indian Ubislate 7+ doesn't support Indic fonts, though I
wouldn't be surprised if the version after that supported 4.0 and its
accompanying fonts, considering its target audience.

···

On Jan 31, 9:16 am, Yaw Anokwa wrote: > I believe you can also add the font to the application itself, but > like Carl pointed out, the positioning problem will still exist. > > > > On Tue, Jan 31, 2012 at 08:59, Carl Hartung wrote: > > I know people have tried to add fonts like Hindi on the system level, but I > > think Android lacks the proper rendering support for several scripting > > languages. That is, it can display the fonts, but given a glyph that can > > have 3 or so different placements to mean different things, it always puts > > them in the first spot. I don't know of anyone who has tried adding > > Devangari to ODK, but I have used applications that reportedly support Hindi > > only to have boxes show up on my phone instead. > > > If you look at the Android release notes, they purportedly started > > supporting Hindi around Android 2.2 or 2.3. I'm not sure what their > > definition of "support" is, but I've never seen Hindi work on a > > non-customized build, and there are only a few phones I've heard of with > > proprietary builds that support it. > > > The relevant android bug is here: > >http://code.google.com/p/android/issues/detail?id=4153 > > > On Tue, Jan 31, 2012 at 1:40 AM, Christopher Robert wrote: > > >> Sorry, but a related question: has anybody tried embedding a font with a > >> custom-built ODK Collect? Since individual Android apps are supposed to be > >> able to embed their own Unicode fonts, this seems like it could be one > >> potential solution. > > >> Thanks again to all for the ideas and assistance, > > >> Chris > > >> On Tuesday, January 31, 2012, Christopher Robert wrote: > > >>> Dear all, > > >>> We're piloting ODK for a series of surveys in rural Tamil Nadu, in > >>> Southern India. Our surveyors don't know English and most of them would not > >>> understand any transliterated version of Tamil, so it's important that our > >>> surveys use the Tamil script. So far, our options seem to be: > > >>> 1. Use the Samsung Galaxy Y or Galaxy Note, since both of these show > >>> Unicode Tamil in our ODK surveys right out of the box. The trouble is, the > >>> Galaxy Y's on-screen keyboard is a touch too small, and the Galaxy Note is > >>> way too expensive. > > >>> 2. "Root" our devices and hand-install Tamil fonts. In principle, this > >>> can work with any device, but frankly we are scared. We would like to use > >>> the Motorola Fire, for example, but its rooting procedure seems particularly > >>> sketchy and ill-defined. Even if a tech wizard can root a device and install > >>> the font successfully, it seems a tall order to do this to every device we > >>> purchase. > > >>> My impression is that ODK implementers typically punt on this issue, > >>> either using English or some transliterated version of the local language, > >>> in order to avoid needing support for different fonts. If any of you have > >>> had success with other Unicode fonts, would you share your experiences? Did > >>> you go with devices that happened to have those fonts pre-installed, or did > >>> you go the rooting route? Any advice would be greatly appreciated. > > >>> Thank you very much, > > >>> Chris > > >>> P.S. The issue goes beyond whether a font is or isn't present. For > >>> example, Spice's budget tablet supports Tamil text, but shows it in an > >>> archaic, formal script that many cannot understand. > > >> -- > >> Post: opendatakit@googlegroups.com > >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com > >> Options:http://groups.google.com/group/opendatakit?hl=en > > > -- > > Post: opendatakit@googlegroups.com > > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > > Options:http://groups.google.com/group/opendatakit?hl=en

yanokwa · January 31, 2012, 9:52pm

We just ordered some Android 4.0 devices. Should know very soon what,
if any, changes we'll have to make to support Indic scripts.

···

On Tue, Jan 31, 2012 at 13:18, Emily Kumpel wrote: > The new release of Android, 4.0, includes support for some Indic > scripts (Devanagari, Tamil, and Bengali). It seems Tamil works in > some applications: http://microblog.ravidreams.net/android-ics-support-for-tamil-indic-languages/ > and that some 2011 phones will likely be getting an upgrade soonish > (http://www.techradar.com/news/phone-and-communications/mobile-phones/ > android-4-0-release-date-when-will-you-get-it--1048272), which means > there would be affordable options. > > Would this mean that ODK would be able to show these fonts if the > phone has Android 4.0? > > > The new $60 Indian Ubislate 7+ doesn't support Indic fonts, though I > wouldn't be surprised if the version after that supported 4.0 and its > accompanying fonts, considering its target audience. > > > On Jan 31, 9:16 am, Yaw Anokwa wrote: >> I believe you can also add the font to the application itself, but >> like Carl pointed out, the positioning problem will still exist. >> >> >> >> On Tue, Jan 31, 2012 at 08:59, Carl Hartung wrote: >> > I know people have tried to add fonts like Hindi on the system level, but I >> > think Android lacks the proper rendering support for several scripting >> > languages. That is, it can display the fonts, but given a glyph that can >> > have 3 or so different placements to mean different things, it always puts >> > them in the first spot. I don't know of anyone who has tried adding >> > Devangari to ODK, but I have used applications that reportedly support Hindi >> > only to have boxes show up on my phone instead. >> >> > If you look at the Android release notes, they purportedly started >> > supporting Hindi around Android 2.2 or 2.3. I'm not sure what their >> > definition of "support" is, but I've never seen Hindi work on a >> > non-customized build, and there are only a few phones I've heard of with >> > proprietary builds that support it. >> >> > The relevant android bug is here: >> >http://code.google.com/p/android/issues/detail?id=4153 >> >> > On Tue, Jan 31, 2012 at 1:40 AM, Christopher Robert wrote: >> >> >> Sorry, but a related question: has anybody tried embedding a font with a >> >> custom-built ODK Collect? Since individual Android apps are supposed to be >> >> able to embed their own Unicode fonts, this seems like it could be one >> >> potential solution. >> >> >> Thanks again to all for the ideas and assistance, >> >> >> Chris >> >> >> On Tuesday, January 31, 2012, Christopher Robert wrote: >> >> >>> Dear all, >> >> >>> We're piloting ODK for a series of surveys in rural Tamil Nadu, in >> >>> Southern India. Our surveyors don't know English and most of them would not >> >>> understand any transliterated version of Tamil, so it's important that our >> >>> surveys use the Tamil script. So far, our options seem to be: >> >> >>> 1. Use the Samsung Galaxy Y or Galaxy Note, since both of these show >> >>> Unicode Tamil in our ODK surveys right out of the box. The trouble is, the >> >>> Galaxy Y's on-screen keyboard is a touch too small, and the Galaxy Note is >> >>> way too expensive. >> >> >>> 2. "Root" our devices and hand-install Tamil fonts. In principle, this >> >>> can work with any device, but frankly we are scared. We would like to use >> >>> the Motorola Fire, for example, but its rooting procedure seems particularly >> >>> sketchy and ill-defined. Even if a tech wizard can root a device and install >> >>> the font successfully, it seems a tall order to do this to every device we >> >>> purchase. >> >> >>> My impression is that ODK implementers typically punt on this issue, >> >>> either using English or some transliterated version of the local language, >> >>> in order to avoid needing support for different fonts. If any of you have >> >>> had success with other Unicode fonts, would you share your experiences? Did >> >>> you go with devices that happened to have those fonts pre-installed, or did >> >>> you go the rooting route? Any advice would be greatly appreciated. >> >> >>> Thank you very much, >> >> >>> Chris >> >> >>> P.S. The issue goes beyond whether a font is or isn't present. For >> >>> example, Spice's budget tablet supports Tamil text, but shows it in an >> >>> archaic, formal script that many cannot understand. >> >> >> -- >> >> Post: opendatakit@googlegroups.com >> >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >> >> Options:http://groups.google.com/group/opendatakit?hl=en >> >> > -- >> > Post: opendatakit@googlegroups.com >> > Unsubscribe: opendatakit+unsubscribe@googlegroups.com >> > Options:http://groups.google.com/group/opendatakit?hl=en > > -- > Post: opendatakit@googlegroups.com > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > Options: http://groups.google.com/group/opendatakit?hl=en

Christopher_Robert · February 3, 2012, 1:00pm

Hi Carl,

Thanks for the reply.

As I mentioned earlier, our Tamil text is showing great (in ODK) on our
Samsung Galaxy Y's. The Android bug discussion likewise mentions some LG
and other models that support Hindi out of the box. The question is whether
these manufacturers are doing anything more than simply dropping the fonts
into the fonts folder. If they are simply bundling the fonts, then I
thought that we might do the same in the app itself. There seems to be a
fair bit of skepticism whether that would work, however. If I manage to
give it a try, then I'll report back with the results. (I don't, as yet,
know how to bundle with ODK, but I should be able to figure that out.)

Thanks again,

Chris

···

On Tuesday, January 31, 2012, Carl Hartung wrote:

I know people have tried to add fonts like Hindi on the system level, but
I think Android lacks the proper rendering support for several scripting
languages. That is, it can display the fonts, but given a glyph that can
have 3 or so different placements to mean different things, it always puts
them in the first spot. I don't know of anyone who has tried adding
Devangari to ODK, but I have used applications that reportedly support
Hindi only to have boxes show up on my phone instead.

If you look at the Android release notes, they purportedly started
supporting Hindi around Android 2.2 or 2.3. I'm not sure what their
definition of "support" is, but I've never seen Hindi work on a
non-customized build, and there are only a few phones I've heard of with
proprietary builds that support it.

The relevant android bug is here:
http://code.google.com/p/android/issues/detail?id=4153

On Tue, Jan 31, 2012 at 1:40 AM, Christopher Robert < chris_robert@hksphd.harvard.edu <javascript:_e({}, 'cvml', 'chris_robert@hksphd.harvard.edu');>> wrote:

Sorry, but a related question: has anybody tried embedding a font with a
custom-built ODK Collect? Since individual Android apps are supposed to be
able to embed their own Unicode fonts, this seems like it could be one
potential solution.

Thanks again to all for the ideas and assistance,

Chris

On Tuesday, January 31, 2012, Christopher Robert wrote:

Dear all,

We're piloting ODK for a series of surveys in rural Tamil Nadu, in
Southern India. Our surveyors don't know English and most of them would not
understand any transliterated version of Tamil, so it's important that our
surveys use the Tamil script. So far, our options seem to be:

Use the Samsung Galaxy Y or Galaxy Note, since both of these show
Unicode Tamil in our ODK surveys right out of the box. The trouble is, the
Galaxy Y's on-screen keyboard is a touch too small, and the Galaxy Note is
way too expensive.

"Root" our devices and hand-install Tamil fonts. In principle, this
can work with any device, but frankly we are scared. We would like to use
the Motorola Fire, for example, but its rooting procedure seems
particularly sketchy and ill-defined. Even if a tech wizard can root a
device and install the font successfully, it seems a tall order to do this
to every device we purchase.

My impression is that ODK implementers typically punt on this issue,
either using English or some transliterated version of the local language,
in order to avoid needing support for different fonts. If any of you have
had success with other Unicode fonts, would you share your experiences? Did
you go with devices that happened to have those fonts pre-installed, or did
you go the rooting route? Any advice would be greatly appreciated.

Thank you very much,

Chris

P.S. The issue goes beyond whether a font is or isn't present. For
example, Spice's budget tablet supports Tamil text, but shows it in an
archaic, formal script that many cannot understand.

--
Post: opendatakit@googlegroups.com <javascript:_e({}, 'cvml',
'opendatakit@googlegroups.com');>
Unsubscribe: opendatakit+unsubscribe@googlegroups.com <javascript:_e({},
'cvml', 'opendatakit%2Bunsubscribe@googlegroups.com');>
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com <javascript:_e({}, 'cvml',
'opendatakit@googlegroups.com');>
Unsubscribe: opendatakit+unsubscribe@googlegroups.com <javascript:_e({},
'cvml', 'opendatakit%2Bunsubscribe@googlegroups.com');>
Options: http://groups.google.com/group/opendatakit?hl=en

yanokwa · February 8, 2012, 9:25am

Just wanted to confirm with everyone that Indic scripts work well on
Android 4.0.2 (at least on a Galaxy Nexus). It apparently also works
on some Android 2.3 devices.

http://code.google.com/p/android/issues/detail?id=4153#c143 has
screenshots of my tests. I've also tested a full survey in ODK (thanks
to Chris Robert!) and it looks good there too.

···

On Tue, Jan 31, 2012 at 13:52, Yaw Anokwa wrote: > We just ordered some Android 4.0 devices. Should know very soon what, > if any, changes we'll have to make to support Indic scripts.

Patrick_McNeal · February 21, 2012, 10:07am

First, due to the great work of Nathan Breit on the ODK team we'll be
releasing an updated spec of XLS2XForm very soon that consolidates some of
the differences between the ODK and formhub/xform.childcount.orgversions. We've also simplified the syntax a bit and provided better
support for multimedia / calculations, etc. We hope to share more details
on this very soon.

Any update on this consolidation? I'm working on some training, and don't
want to create material on something that's soon to be outdated soon.

Thanks

--Patrick

···

On Tue, Jan 31, 2012 at 12:14 PM, Matt Berg wrote:

gaetano · January 31, 2012, 7:28am

We have something preliminary working. If you can work with us on this, we
may be able to get you going. The first step are to prepare a spreadsheet
with columns for the question text in the languages (using the appropriate
font file - .ttf - and having set excel to show unicode). An additional
column for each language should have the name to be given that image file.
If you can generate such a spreadsheet - even a test one - we can push it
through and send you the results. You are right about experimenting with
text size height. Our approach right now is to manually insert line breaks
once a width is finalized (easiest and most reliable), we then count the
line breaks to determine the height of the image. Up for this?

Gaetano

···

On Mon, Jan 30, 2012 at 11:21 PM, Christopher Robert < chris_robert@hksphd.harvard.edu> wrote:

Hi Matt,

Thanks for the reply -- and for the ray of hope. Auto-generating the
images is a great idea -- though of course it's somewhat absurd that the
Android platform would force us into such contortions!

I suppose that the image auto-generator will need to take a few
parameters, namely the image width and perhaps a preferred font size. I'll
eagerly await more news on this, as it does sound like it will make our
lives much easier.

This talk of updates to XLS2XForm makes me wonder: do you recommend that
users install and run their own XLS2XForm server instances? I'm sure that
you'll seek to maintain backward compatibility in new updates, but if I
have an RA team trained on a particular version, and a bunch of surveys
developed for that version, then it seems like I might like to have that
version of XLS2XForm running someplace safe, in case of small updates to
the surveys. Is that encouraged/supported?

Thanks again,

Chris

On Tuesday, January 31, 2012, Matt Berg wrote:

Chris,

We're experiencing many of the same issues trying to get Kannada support
working.

We are about to work on something that we hope will help provide a
temporary fix to this problem for those who use XLS2XForm.

First, due to the great work of Nathan Breit on the ODK team we'll be
releasing an updated spec of XLS2XForm very soon that consolidates some of
the differences between the ODK and formhub/xform.childcount.orgversions. We've also simplified the syntax a bit and provided better
support for multimedia / calculations, etc. We hope to share more details
on this very soon.

Back to this language issue. We're planning on modifying XLS2XForm to
automatically generate the text into images and then automatically link
them properly in the xform to represent question labels, option labs and
hints. If you have any question, Prabhas who is the main person behind
this will have more details. This doesn't get around the issue of data
entry but we think it'll at least be helpful in providing a temporary fix
to many of these issues.

We'll let you know when we are closer to having something to show.

Thanks,

Matt

On Tue, Jan 31, 2012 at 9:33 AM, Christopher Robert < chris_robert@hksphd.harvard.edu> wrote:

Dear Yaw,

Thanks for the lightning-fast reply!

My big worry with images is just the practical difficulty associated
with creating appropriately-sized/wrapped images, uploading them, etc.
Right now we use XLS2XForm and the RA team can very easily manage the
surveys themselves. It looks like XLS2XForm supports a media:image column,
however, so maybe the only complication is making images that are sized and
wrapped appropriately. Did you have good luck with a particular software
package for image-creation and -editing? I suppose we'd just need to come
up with the question-image dimensions that work best on our device of
choice, then standardize on a software package and font for creating images
of that size. I'd be grateful for any additional advice from your Hindi
experience.

Thanks,

Chris

On Tuesday, January 31, 2012, Yaw Anokwa wrote:

Another option is to use images instead of text for the question text.
We've done that for some Hindi forms and it works pretty well.

On Mon, Jan 30, 2012 at 22:17, Christopher Robert chris_robert@hksphd.harvard.edu wrote:

Dear all,

We're piloting ODK for a series of surveys in rural Tamil Nadu, in
Southern
India. Our surveyors don't know English and most of them would not
understand any transliterated version of Tamil, so it's important
that our
surveys use the Tamil script. So far, our options seem to be:

Use the Samsung Galaxy Y or Galaxy Note, since both of these show
Unicode
Tamil in our ODK surveys right out of the box. The trouble is, the
Galaxy
Y's on-screen keyboard is a touch too small, and the Galaxy Note is
way too
expensive.

"Root" our devices and hand-install Tamil fonts. In principle,
this can
work with any device, but frankly we are scared. We would like to use
the
Motorola Fire, for example, but its rooting procedure seems
particularly
sketchy and ill-defined. Even if a tech wizard can root a device and
install
the font successfully, it seems a tall order to do this to every
device we
purchase.

My impression is that ODK implementers typically punt on this issue,
either
using English or some transliterated version of the local language,
in order
to avoid needing support for different fonts. If any of you have had
success
with other Unicode fonts, would you share your experiences? Did you
go with
devices that happened to have those fonts pre-installed, or did you
go the
rooting route? Any advice would be greatly appreciated.

Thank you very much,

Chris

P.S. The issue goes beyond whether a font is or isn't present. For
example,
Spice's budget tablet supports Tamil text, but shows it in an archaic,
formal script that many cannot understand.

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

gaetano · January 31, 2012, 7:38am

Separate tool for now. Intention was to build it into xls2xform if there
is enough demand. But it would need a bit more work to do it right.

···

On Mon, Jan 30, 2012 at 11:34 PM, Matt Berg wrote:

Gaetano - Just to clarify is this an extension of xls2xform or a separate
tool you've built to do this?

Chris - good question. We're really hoping the changes we made are a
one-time deal and their won't be any major changes moving forward on the
spec. The changes are mostly just renaming some of the column headers and
field names so it should be pretty easy to update your existing forms.

We're debating leaving some alias support to provide
backwards compatibility but we would really like to get people moving
forward with a common standard.

On Tue, Jan 31, 2012 at 10:28 AM, Gaetano Borriello < gaetano@cs.washington.edu> wrote:

We have something preliminary working. If you can work with us on this,
we may be able to get you going. The first step are to prepare a
spreadsheet with columns for the question text in the languages (using the
appropriate font file - .ttf - and having set excel to show unicode). An
additional column for each language should have the name to be given that
image file. If you can generate such a spreadsheet - even a test one - we
can push it through and send you the results. You are right about
experimenting with text size height. Our approach right now is to manually
insert line breaks once a width is finalized (easiest and most reliable),
we then count the line breaks to determine the height of the image. Up for
this?

Gaetano

On Mon, Jan 30, 2012 at 11:21 PM, Christopher Robert < chris_robert@hksphd.harvard.edu> wrote:

Hi Matt,

Thanks for the reply -- and for the ray of hope. Auto-generating the
images is a great idea -- though of course it's somewhat absurd that the
Android platform would force us into such contortions!

I suppose that the image auto-generator will need to take a few
parameters, namely the image width and perhaps a preferred font size. I'll
eagerly await more news on this, as it does sound like it will make our
lives much easier.

This talk of updates to XLS2XForm makes me wonder: do you recommend that
users install and run their own XLS2XForm server instances? I'm sure that
you'll seek to maintain backward compatibility in new updates, but if I
have an RA team trained on a particular version, and a bunch of surveys
developed for that version, then it seems like I might like to have that
version of XLS2XForm running someplace safe, in case of small updates to
the surveys. Is that encouraged/supported?

Thanks again,

Chris

On Tuesday, January 31, 2012, Matt Berg wrote:

Chris,

We're experiencing many of the same issues trying to get Kannada
support working.

We are about to work on something that we hope will help provide a
temporary fix to this problem for those who use XLS2XForm.

First, due to the great work of Nathan Breit on the ODK team we'll be
releasing an updated spec of XLS2XForm very soon that consolidates some of
the differences between the ODK and formhub/xform.childcount.orgversions. We've also simplified the syntax a bit and provided better
support for multimedia / calculations, etc. We hope to share more details
on this very soon.

Back to this language issue. We're planning on modifying XLS2XForm to
automatically generate the text into images and then automatically link
them properly in the xform to represent question labels, option labs and
hints. If you have any question, Prabhas who is the main person behind
this will have more details. This doesn't get around the issue of data
entry but we think it'll at least be helpful in providing a temporary fix
to many of these issues.

We'll let you know when we are closer to having something to show.

Thanks,

Matt

On Tue, Jan 31, 2012 at 9:33 AM, Christopher Robert < chris_robert@hksphd.harvard.edu> wrote:

Dear Yaw,

Thanks for the lightning-fast reply!

My big worry with images is just the practical difficulty associated
with creating appropriately-sized/wrapped images, uploading them, etc.
Right now we use XLS2XForm and the RA team can very easily manage the
surveys themselves. It looks like XLS2XForm supports a media:image column,
however, so maybe the only complication is making images that are sized and
wrapped appropriately. Did you have good luck with a particular software
package for image-creation and -editing? I suppose we'd just need to come
up with the question-image dimensions that work best on our device of
choice, then standardize on a software package and font for creating images
of that size. I'd be grateful for any additional advice from your Hindi
experience.

Thanks,

Chris

On Tuesday, January 31, 2012, Yaw Anokwa wrote:

Another option is to use images instead of text for the question text.
We've done that for some Hindi forms and it works pretty well.

On Mon, Jan 30, 2012 at 22:17, Christopher Robert chris_robert@hksphd.harvard.edu wrote:

Dear all,

We're piloting ODK for a series of surveys in rural Tamil Nadu, in
Southern
India. Our surveyors don't know English and most of them would not
understand any transliterated version of Tamil, so it's important
that our
surveys use the Tamil script. So far, our options seem to be:

Use the Samsung Galaxy Y or Galaxy Note, since both of these
show Unicode
Tamil in our ODK surveys right out of the box. The trouble is, the
Galaxy
Y's on-screen keyboard is a touch too small, and the Galaxy Note is
way too
expensive.

"Root" our devices and hand-install Tamil fonts. In principle,
this can
work with any device, but frankly we are scared. We would like to
use the
Motorola Fire, for example, but its rooting procedure seems
particularly
sketchy and ill-defined. Even if a tech wizard can root a device
and install
the font successfully, it seems a tall order to do this to every
device we
purchase.

My impression is that ODK implementers typically punt on this
issue, either
using English or some transliterated version of the local language,
in order
to avoid needing support for different fonts. If any of you have
had success
with other Unicode fonts, would you share your experiences? Did you
go with
devices that happened to have those fonts pre-installed, or did you
go the
rooting route? Any advice would be greatly appreciated.

Thank you very much,

Chris

P.S. The issue goes beyond whether a font is or isn't present. For
example,
Spice's budget tablet supports Tamil text, but shows it in an
archaic,
formal script that many cannot understand.

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

Matt_Berg · January 31, 2012, 7:34am

Gaetano - Just to clarify is this an extension of xls2xform or a separate
tool you've built to do this?

Chris - good question. We're really hoping the changes we made are a
one-time deal and their won't be any major changes moving forward on the
spec. The changes are mostly just renaming some of the column headers and
field names so it should be pretty easy to update your existing forms.

We're debating leaving some alias support to provide
backwards compatibility but we would really like to get people moving
forward with a common standard.

···

On Tue, Jan 31, 2012 at 10:28 AM, Gaetano Borriello < gaetano@cs.washington.edu> wrote:

We have something preliminary working. If you can work with us on this,
we may be able to get you going. The first step are to prepare a
spreadsheet with columns for the question text in the languages (using the
appropriate font file - .ttf - and having set excel to show unicode). An
additional column for each language should have the name to be given that
image file. If you can generate such a spreadsheet - even a test one - we
can push it through and send you the results. You are right about
experimenting with text size height. Our approach right now is to manually
insert line breaks once a width is finalized (easiest and most reliable),
we then count the line breaks to determine the height of the image. Up for
this?

Gaetano

On Mon, Jan 30, 2012 at 11:21 PM, Christopher Robert < chris_robert@hksphd.harvard.edu> wrote:

Hi Matt,

Thanks for the reply -- and for the ray of hope. Auto-generating the
images is a great idea -- though of course it's somewhat absurd that the
Android platform would force us into such contortions!

I suppose that the image auto-generator will need to take a few
parameters, namely the image width and perhaps a preferred font size. I'll
eagerly await more news on this, as it does sound like it will make our
lives much easier.

This talk of updates to XLS2XForm makes me wonder: do you recommend that
users install and run their own XLS2XForm server instances? I'm sure that
you'll seek to maintain backward compatibility in new updates, but if I
have an RA team trained on a particular version, and a bunch of surveys
developed for that version, then it seems like I might like to have that
version of XLS2XForm running someplace safe, in case of small updates to
the surveys. Is that encouraged/supported?

Thanks again,

Chris

On Tuesday, January 31, 2012, Matt Berg wrote:

Chris,

We're experiencing many of the same issues trying to get Kannada support
working.

We are about to work on something that we hope will help provide a
temporary fix to this problem for those who use XLS2XForm.

First, due to the great work of Nathan Breit on the ODK team we'll be
releasing an updated spec of XLS2XForm very soon that consolidates some of
the differences between the ODK and formhub/xform.childcount.orgversions. We've also simplified the syntax a bit and provided better
support for multimedia / calculations, etc. We hope to share more details
on this very soon.

Back to this language issue. We're planning on modifying XLS2XForm to
automatically generate the text into images and then automatically link
them properly in the xform to represent question labels, option labs and
hints. If you have any question, Prabhas who is the main person behind
this will have more details. This doesn't get around the issue of data
entry but we think it'll at least be helpful in providing a temporary fix
to many of these issues.

We'll let you know when we are closer to having something to show.

Thanks,

Matt

On Tue, Jan 31, 2012 at 9:33 AM, Christopher Robert < chris_robert@hksphd.harvard.edu> wrote:

Dear Yaw,

Thanks for the lightning-fast reply!

My big worry with images is just the practical difficulty associated
with creating appropriately-sized/wrapped images, uploading them, etc.
Right now we use XLS2XForm and the RA team can very easily manage the
surveys themselves. It looks like XLS2XForm supports a media:image column,
however, so maybe the only complication is making images that are sized and
wrapped appropriately. Did you have good luck with a particular software
package for image-creation and -editing? I suppose we'd just need to come
up with the question-image dimensions that work best on our device of
choice, then standardize on a software package and font for creating images
of that size. I'd be grateful for any additional advice from your Hindi
experience.

Thanks,

Chris

On Tuesday, January 31, 2012, Yaw Anokwa wrote:

Another option is to use images instead of text for the question text.
We've done that for some Hindi forms and it works pretty well.

On Mon, Jan 30, 2012 at 22:17, Christopher Robert chris_robert@hksphd.harvard.edu wrote:

Dear all,

We're piloting ODK for a series of surveys in rural Tamil Nadu, in
Southern
India. Our surveyors don't know English and most of them would not
understand any transliterated version of Tamil, so it's important
that our
surveys use the Tamil script. So far, our options seem to be:

Use the Samsung Galaxy Y or Galaxy Note, since both of these show
Unicode
Tamil in our ODK surveys right out of the box. The trouble is, the
Galaxy
Y's on-screen keyboard is a touch too small, and the Galaxy Note is
way too
expensive.

"Root" our devices and hand-install Tamil fonts. In principle,
this can
work with any device, but frankly we are scared. We would like to
use the
Motorola Fire, for example, but its rooting procedure seems
particularly
sketchy and ill-defined. Even if a tech wizard can root a device and
install
the font successfully, it seems a tall order to do this to every
device we
purchase.

My impression is that ODK implementers typically punt on this issue,
either
using English or some transliterated version of the local language,
in order
to avoid needing support for different fonts. If any of you have had
success
with other Unicode fonts, would you share your experiences? Did you
go with
devices that happened to have those fonts pre-installed, or did you
go the
rooting route? Any advice would be greatly appreciated.

Thank you very much,

Chris

P.S. The issue goes beyond whether a font is or isn't present. For
example,
Spice's budget tablet supports Tamil text, but shows it in an
archaic,
formal script that many cannot understand.

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

Christopher_Robert · January 31, 2012, 7:54am

Hi Matt,

Our surveys are meant to be in the field for 3-4 years, with the potential
for very minor changes along the way. In the short-run, renaming columns
and making other tweaks should be no problem, but in the longer-run I guess
that it makes me nervous if we could end up with a bunch of form
definitions that might become out-of-date. Would it be feasible for us to
run our own server instance so that we could always convert XLS->XML using
the codebase that went with the original forms?

Thanks,

Chris

···

On Tuesday, January 31, 2012, Matt Berg wrote:

Gaetano - Just to clarify is this an extension of xls2xform or a separate
tool you've built to do this?

Chris - good question. We're really hoping the changes we made are a
one-time deal and their won't be any major changes moving forward on the
spec. The changes are mostly just renaming some of the column headers and
field names so it should be pretty easy to update your existing forms.

We're debating leaving some alias support to provide
backwards compatibility but we would really like to get people moving
forward with a common standard.

On Tue, Jan 31, 2012 at 10:28 AM, Gaetano Borriello < gaetano@cs.washington.edu> wrote:

We have something preliminary working. If you can work with us on this,
we may be able to get you going. The first step are to prepare a
spreadsheet with columns for the question text in the languages (using the
appropriate font file - .ttf - and having set excel to show unicode). An
additional column for each language should have the name to be given that
image file. If you can generate such a spreadsheet - even a test one - we
can push it through and send you the results. You are right about
experimenting with text size height. Our approach right now is to manually
insert line breaks once a width is finalized (easiest and most reliable),
we then count the line breaks to determine the height of the image. Up for
this?

Gaetano

On Mon, Jan 30, 2012 at 11:21 PM, Christopher Robert < chris_robert@hksphd.harvard.edu> wrote:

Hi Matt,

Thanks for the reply -- and for the ray of hope. Auto-generating the
images is a great idea -- though of course it's somewhat absurd that the
Android platform would force us into such contortions!

I suppose that the image auto-generator will need to take a few
parameters, namely the image width and perhaps a preferred font size. I'll
eagerly await more news on this, as it does sound like it will make our
lives much easier.

This talk of updates to XLS2XForm makes me wonder: do you recommend that
users install and run their own XLS2XForm server instances? I'm sure that
you'll seek to maintain backward compatibility in new updates, but if I
have an RA team trained on a particular version, and a bunch of surveys
developed for that version, then it seems like I might like to have that
version of XLS2XForm running someplace safe, in case of small updates to
the surveys. Is that encouraged/supported?

Thanks again,

Chris

On Tuesday, January 31, 2012, Matt Berg wrote:

Chris,

We're experiencing many of the same issues trying to get Kannada support
working.

We are about to work on something that we hope will help provide a
temporary fix to this problem for those who use XLS2XForm.

First, due to the great work of Nathan Breit on the ODK team we'll be
releasing an updated spec of XLS2XForm very soon that consolidates some of
the differences between the ODK and formhub/xform.childcount.orgversions. We've also simplified the syntax a bit and provided better
support for multimedia / calculations, etc. We hope to share more details
on this very soon.

Back to this language issue. We're planning on modifying XLS2XForm to
automatically generate the text into images and then automatically link
them properly in the xform to represent question labels, option labs and
hints. If you have any question, Prabhas who is the main person behind
this will have more details. This doesn't get around the issue of data
entry but we think it'll at least be helpful in providing a temporary fix
to many of these issues.

We'll let you know when we are closer to having something to show.

Thanks,

Matt

On Tue, Jan 31, 2012 at 9:33 AM, Christopher Robert < chris_robert@hksphd.harvard.edu> wrote:

Dear Yaw,

Thanks for the lightning-fast reply!

My big worry with images is just the practical difficulty associated with
creating appropriately-sized/wrapped images, uploading them, etc. Right now
we use XLS2XForm and the RA team can very easily manage the surveys
themselves. It looks like XLS2XForm supports a media:image column, however,
so maybe the only complication is making images that are sized and wrapped
appropriately. Did you have good luck with a particular software package
for image-creation and -editing? I suppose we'd just need to come up

--
Post: opendatakit@googlegroups.com <javascript:_e({}, 'cvml',
'opendatakit@googlegroups.com');>
Unsubscribe: opendatakit+unsubscribe@googlegroups.com <javascript:_e({},
'cvml', 'opendatakit%2Bunsubscribe@googlegroups.com');>
Options: http://groups.google.com/group/opendatakit?hl=en

Prabhas_Pokharel1 · February 2, 2012, 2:00pm

Gaetano, as Matt said, if the code was out there somewhere, it would be
great to have a look. Displaying Kannada, which needs complex character
rendering like most Indic languages, is a requirement for one of our
projects, and we are planning to build image rendering into xls2xform in
order to do that. We are planning to use pango/cairo and python, and so far
have only learned enough that we can generate an image with rendered
unicode when width and height are specified. If there is code that has
actually taken the steps to take this to images that work well with ODK,
etc., might be useful to study it before we start working.

The other thing working on such an exercise suggests is that it would be
great if ODK could automatically pull media files from a server; through
something like a medialist that went along with the formlist. I'm sure
there has been thought that has been put in along those lines; would love
to hear more.

···

On Tuesday, January 31, 2012 2:38:21 AM UTC-5, Gaetano Borriello wrote: > > Separate tool for now. Intention was to build it into xls2xform if there > is enough demand. But it would need a bit more work to do it right. > > > On Mon, Jan 30, 2012 at 11:34 PM, Matt Berg wrote: > >> Gaetano - Just to clarify is this an extension of xls2xform or a separate >> tool you've built to do this? >> >> Chris - good question. We're really hoping the changes we made are a >> one-time deal and their won't be any major changes moving forward on the >> spec. The changes are mostly just renaming some of the column headers and >> field names so it should be pretty easy to update your existing forms. >> >> We're debating leaving some alias support to provide >> backwards compatibility but we would really like to get people moving >> forward with a common standard. >> >> >> On Tue, Jan 31, 2012 at 10:28 AM, Gaetano Borriello < gaetano@cs.washington.edu> wrote: >> >>> We have something preliminary working. If you can work with us on this, >>> we may be able to get you going. The first step are to prepare a >>> spreadsheet with columns for the question text in the languages (using the >>> appropriate font file - .ttf - and having set excel to show unicode). An >>> additional column for each language should have the name to be given that >>> image file. If you can generate such a spreadsheet - even a test one - we >>> can push it through and send you the results. You are right about >>> experimenting with text size height. Our approach right now is to manually >>> insert line breaks once a width is finalized (easiest and most reliable), >>> we then count the line breaks to determine the height of the image. Up for >>> this? >>> >>> Gaetano >>> >>> >>> >>> On Mon, Jan 30, 2012 at 11:21 PM, Christopher Robert < chris_robert@hksphd.harvard.edu> wrote: >>> >>>> Hi Matt, >>>> >>>> Thanks for the reply -- and for the ray of hope. Auto-generating the >>>> images is a great idea -- though of course it's somewhat absurd that the >>>> Android platform would force us into such contortions! >>>> >>>> I suppose that the image auto-generator will need to take a few >>>> parameters, namely the image width and perhaps a preferred font size. I'll >>>> eagerly await more news on this, as it does sound like it will make our >>>> lives much easier. >>>> >>>> This talk of updates to XLS2XForm makes me wonder: do you recommend >>>> that users install and run their own XLS2XForm server instances? I'm sure >>>> that you'll seek to maintain backward compatibility in new updates, but if >>>> I have an RA team trained on a particular version, and a bunch of surveys >>>> developed for that version, then it seems like I might like to have that >>>> version of XLS2XForm running someplace safe, in case of small updates to >>>> the surveys. Is that encouraged/supported? >>>> >>>> Thanks again, >>>> >>>> Chris >>>> >>>> On Tuesday, January 31, 2012, Matt Berg wrote: >>>> >>>>> Chris, >>>>> >>>>> We're experiencing many of the same issues trying to get Kannada >>>>> support working. >>>>> >>>>> We are about to work on something that we hope will help provide a >>>>> temporary fix to this problem for those who use XLS2XForm. >>>>> >>>>> First, due to the great work of Nathan Breit on the ODK team we'll be >>>>> releasing an updated spec of XLS2XForm very soon that consolidates some of >>>>> the differences between the ODK and formhub/xform.childcount.orgversions. We've also simplified the syntax a bit and provided better >>>>> support for multimedia / calculations, etc. We hope to share more details >>>>> on this very soon. >>>>> >>>>> Back to this language issue. We're planning on modifying XLS2XForm to >>>>> automatically generate the text into images and then automatically link >>>>> them properly in the xform to represent question labels, option labs and >>>>> hints. If you have any question, Prabhas who is the main person behind >>>>> this will have more details. This doesn't get around the issue of data >>>>> entry but we think it'll at least be helpful in providing a temporary fix >>>>> to many of these issues. >>>>> >>>>> We'll let you know when we are closer to having something to show. >>>>> >>>>> Thanks, >>>>> >>>>> Matt >>>>> >>>>> >>>>> On Tue, Jan 31, 2012 at 9:33 AM, Christopher Robert < chris_robert@hksphd.harvard.edu> wrote: >>>>> >>>>>> Dear Yaw, >>>>>> >>>>>> Thanks for the lightning-fast reply! >>>>>> >>>>>> My big worry with images is just the practical difficulty associated >>>>>> with creating appropriately-sized/wrapped images, uploading them, etc. >>>>>> Right now we use XLS2XForm and the RA team can very easily manage the >>>>>> surveys themselves. It looks like XLS2XForm supports a media:image column, >>>>>> however, so maybe the only complication is making images that are sized and >>>>>> wrapped appropriately. Did you have good luck with a particular software >>>>>> package for image-creation and -editing? I suppose we'd just need to come >>>>>> up with the question-image dimensions that work best on our device of >>>>>> choice, then standardize on a software package and font for creating images >>>>>> of that size. I'd be grateful for any additional advice from your Hindi >>>>>> experience. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> On Tuesday, January 31, 2012, Yaw Anokwa wrote: >>>>>> >>>>>>> Another option is to use images instead of text for the question >>>>>>> text. >>>>>>> We've done that for some Hindi forms and it works pretty well. >>>>>>> >>>>>>> On Mon, Jan 30, 2012 at 22:17, Christopher Robert wrote: >>>>>>> > Dear all, >>>>>>> > >>>>>>> > We're piloting ODK for a series of surveys in rural Tamil Nadu, in >>>>>>> Southern >>>>>>> > India. Our surveyors don't know English and most of them would not >>>>>>> > understand any transliterated version of Tamil, so it's important >>>>>>> that our >>>>>>> > surveys use the Tamil script. So far, our options seem to be: >>>>>>> > >>>>>>> > 1. Use the Samsung Galaxy Y or Galaxy Note, since both of these >>>>>>> show Unicode >>>>>>> > Tamil in our ODK surveys right out of the box. The trouble is, the >>>>>>> Galaxy >>>>>>> > Y's on-screen keyboard is a touch too small, and the Galaxy Note >>>>>>> is way too >>>>>>> > expensive. >>>>>>> > >>>>>>> > 2. "Root" our devices and hand-install Tamil fonts. In principle, >>>>>>> this can >>>>>>> > work with any device, but frankly we are scared. We would like to >>>>>>> use the >>>>>>> > Motorola Fire, for example, but its rooting procedure seems >>>>>>> particularly >>>>>>> > sketchy and ill-defined. Even if a tech wizard can root a device >>>>>>> and install >>>>>>> > the font successfully, it seems a tall order to do this to every >>>>>>> device we >>>>>>> > purchase. >>>>>>> > >>>>>>> > My impression is that ODK implementers typically punt on this >>>>>>> issue, either >>>>>>> > using English or some transliterated version of the local >>>>>>> language, in order >>>>>>> > to avoid needing support for different fonts. If any of you have >>>>>>> had success >>>>>>> > with other Unicode fonts, would you share your experiences? Did >>>>>>> you go with >>>>>>> > devices that happened to have those fonts pre-installed, or did >>>>>>> you go the >>>>>>> > rooting route? Any advice would be greatly appreciated. >>>>>>> > >>>>>>> > Thank you very much, >>>>>>> > >>>>>>> > Chris >>>>>>> > >>>>>>> > P.S. The issue goes beyond whether a font is or isn't present. For >>>>>>> example, >>>>>>> > Spice's budget tablet supports Tamil text, but shows it in an >>>>>>> archaic, >>>>>>> > formal script that many cannot understand. >>>>>>> > >>>>>>> > -- >>>>>>> > Post: opendatakit@googlegroups.com >>>>>>> > Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>>>>>> > Options: http://groups.google.com/group/opendatakit?hl=en >>>>>>> >>>>>>> -- >>>>>>> Post: opendatakit@googlegroups.com >>>>>>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>>>>>> Options: http://groups.google.com/group/opendatakit?hl=en >>>>>>> >>>>>> -- >>>>>> Post: opendatakit@googlegroups.com >>>>>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>>>>> Options: http://groups.google.com/group/opendatakit?hl=en >>>>>> >>>>> >>>>> -- >>>>> Post: opendatakit@googlegroups.com >>>>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>>>> Options: http://groups.google.com/group/opendatakit?hl=en >>>>> >>>> -- >>>> Post: opendatakit@googlegroups.com >>>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>>> Options: http://groups.google.com/group/opendatakit?hl=en >>>> >>> >>> -- >>> Post: opendatakit@googlegroups.com >>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>> Options: http://groups.google.com/group/opendatakit?hl=en >>> >> >> -- >> Post: opendatakit@googlegroups.com >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >> Options: http://groups.google.com/group/opendatakit?hl=en >> > >

Nathan · February 3, 2012, 6:57pm

Here's the site I've been working on for rendering internationalized
text:
http://bit.ly/wKHwje
I'm working on making it possible to upload a spreadsheet and get back
a zipped directory with an image for every row. For now it can only
generate one image at a time.
Regards,
-Nathan

···

On Feb 3, 5:00 am, Christopher Robert wrote: > Hi Carl, > > Thanks for the reply. > > As I mentioned earlier, our Tamil text is showing great (in ODK) on our > Samsung Galaxy Y's. The Android bug discussion likewise mentions some LG > and other models that support Hindi out of the box. The question is whether > these manufacturers are doing anything more than simply dropping the fonts > into the fonts folder. If they are simply bundling the fonts, then I > thought that we might do the same in the app itself. There seems to be a > fair bit of skepticism whether that would work, however. If I manage to > give it a try, then I'll report back with the results. (I don't, as yet, > know how to bundle with ODK, but I should be able to figure that out.) > > Thanks again, > > Chris > > > > > > > > On Tuesday, January 31, 2012, Carl Hartung wrote: > > I know people have tried to add fonts like Hindi on the system level, but > > I think Android lacks the proper rendering support for several scripting > > languages. That is, it can display the fonts, but given a glyph that can > > have 3 or so different placements to mean different things, it always puts > > them in the first spot. I don't know of anyone who has tried adding > > Devangari to ODK, but I have used applications that reportedly support > > Hindi only to have boxes show up on my phone instead. > > > If you look at the Android release notes, they purportedly started > > supporting Hindi around Android 2.2 or 2.3. I'm not sure what their > > definition of "support" is, but I've never seen Hindi work on a > > non-customized build, and there are only a few phones I've heard of with > > proprietary builds that support it. > > > The relevant android bug is here: > >http://code.google.com/p/android/issues/detail?id=4153 > > > On Tue, Jan 31, 2012 at 1:40 AM, Christopher Robert < chris_rob...@hksphd.harvard.edu > wrote: > > >> Sorry, but a related question: has anybody tried embedding a font with a > >> custom-built ODK Collect? Since individual Android apps are supposed to be > >> able to embed their own Unicode fonts, this seems like it could be one > >> potential solution. > > >> Thanks again to all for the ideas and assistance, > > >> Chris > > >> On Tuesday, January 31, 2012, Christopher Robert wrote: > > >>> Dear all, > > >>> We're piloting ODK for a series of surveys in rural Tamil Nadu, in > >>> Southern India. Our surveyors don't know English and most of them would not > >>> understand any transliterated version of Tamil, so it's important that our > >>> surveys use the Tamil script. So far, our options seem to be: > > >>> 1. Use the Samsung Galaxy Y or Galaxy Note, since both of these show > >>> Unicode Tamil in our ODK surveys right out of the box. The trouble is, the > >>> Galaxy Y's on-screen keyboard is a touch too small, and the Galaxy Note is > >>> way too expensive. > > >>> 2. "Root" our devices and hand-install Tamil fonts. In principle, this > >>> can work with any device, but frankly we are scared. We would like to use > >>> the Motorola Fire, for example, but its rooting procedure seems > >>> particularly sketchy and ill-defined. Even if a tech wizard can root a > >>> device and install the font successfully, it seems a tall order to do this > >>> to every device we purchase. > > >>> My impression is that ODK implementers typically punt on this issue, > >>> either using English or some transliterated version of the local language, > >>> in order to avoid needing support for different fonts. If any of you have > >>> had success with other Unicode fonts, would you share your experiences? Did > >>> you go with devices that happened to have those fonts pre-installed, or did > >>> you go the rooting route? Any advice would be greatly appreciated. > > >>> Thank you very much, > > >>> Chris > > >>> P.S. The issue goes beyond whether a font is or isn't present. For > >>> example, Spice's budget tablet supports Tamil text, but shows it in an > >>> archaic, formal script that many cannot understand. > > >>> -- > >> Post: opendatakit@googlegroups.com >> 'opendatakit@googlegroups.com');> > >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >> 'cvml', 'opendatakit%2Bunsubscribe@googlegroups.com');> > >> Options:http://groups.google.com/group/opendatakit?hl=en > > > -- > > Post: opendatakit@googlegroups.com > 'opendatakit@googlegroups.com');> > > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > 'cvml', 'opendatakit%2Bunsubscribe@googlegroups.com');> > > Options:http://groups.google.com/group/opendatakit?hl=en

Christopher_Robert · February 4, 2012, 5:07am

Hi Nathan,

I uploaded TamilMN.ttf, then pasted in one of our Tamil prompts. It
uploaded a blob.png to the server (attached), which is small and low-res --
but it has all its dots in the right places. It also put a
rendered_text.png at the top of the screen (also attached), which is larger
and higher-res -- but has its dots in the wrong places (at the ends of
characters rather than over them). Seems like maybe the blob.png is
originating on my computer with my font, but then that's the same
TamilMN.ttf that I uploaded... so not sure why rendered_text.png is
different. Maybe you can make sense of this, though.

Thanks,

Chris

···

On Friday, February 3, 2012, Nathan wrote:

Here's the site I've been working on for rendering internationalized
text:
http://bit.ly/wKHwje
I'm working on making it possible to upload a spreadsheet and get back
a zipped directory with an image for every row. For now it can only
generate one image at a time.
Regards,
-Nathan

On Feb 3, 5:00 am, Christopher Robert <chris_rob...@hksphd.harvard.edu <javascript:;>> wrote:

Hi Carl,

Thanks for the reply.

As I mentioned earlier, our Tamil text is showing great (in ODK) on our
Samsung Galaxy Y's. The Android bug discussion likewise mentions some LG
and other models that support Hindi out of the box. The question is
whether
these manufacturers are doing anything more than simply dropping the
fonts
into the fonts folder. If they are simply bundling the fonts, then I
thought that we might do the same in the app itself. There seems to be a
fair bit of skepticism whether that would work, however. If I manage to
give it a try, then I'll report back with the results. (I don't, as yet,
know how to bundle with ODK, but I should be able to figure that out.)

Thanks again,

Chris

On Tuesday, January 31, 2012, Carl Hartung wrote:

I know people have tried to add fonts like Hindi on the system level,
but
I think Android lacks the proper rendering support for several
scripting
languages. That is, it can display the fonts, but given a glyph that
can
have 3 or so different placements to mean different things, it always
puts
them in the first spot. I don't know of anyone who has tried adding
Devangari to ODK, but I have used applications that reportedly support
Hindi only to have boxes show up on my phone instead.

If you look at the Android release notes, they purportedly started
supporting Hindi around Android 2.2 or 2.3. I'm not sure what their
definition of "support" is, but I've never seen Hindi work on a
non-customized build, and there are only a few phones I've heard of
with
proprietary builds that support it.

The relevant android bug is here:
http://code.google.com/p/android/issues/detail?id=4153

On Tue, Jan 31, 2012 at 1:40 AM, Christopher Robert < chris_rob...@hksphd.harvard.edu <javascript:;> <javascript:_e({}, 'cvml', 'chris_rob...@hksphd.harvard.edu <javascript:;>');>> wrote:

Sorry, but a related question: has anybody tried embedding a font
with a
custom-built ODK Collect? Since individual Android apps are supposed
to be
able to embed their own Unicode fonts, this seems like it could be one
potential solution.

Thanks again to all for the ideas and assistance,

Chris

On Tuesday, January 31, 2012, Christopher Robert wrote:

Dear all,

We're piloting ODK for a series of surveys in rural Tamil Nadu, in
Southern India. Our surveyors don't know English and most of them
would not
understand any transliterated version of Tamil, so it's important
that our
surveys use the Tamil script. So far, our options seem to be:

Use the Samsung Galaxy Y or Galaxy Note, since both of these show
Unicode Tamil in our ODK surveys right out of the box. The trouble
is, the
Galaxy Y's on-screen keyboard is a touch too small, and the Galaxy
Note is
way too expensive.

"Root" our devices and hand-install Tamil fonts. In principle,
this
can work with any device, but frankly we are scared. We would like
to use
the Motorola Fire, for example, but its rooting procedure seems
particularly sketchy and ill-defined. Even if a tech wizard can root
a
device and install the font successfully, it seems a tall order to
do this
to every device we purchase.

My impression is that ODK implementers typically punt on this issue,
either using English or some transliterated version of the local
language,
in order to avoid needing support for different fonts. If any of you
have
had success with other Unicode fonts, would you share your
experiences? Did
you go with devices that happened to have those fonts pre-installed,
or did
you go the rooting route? Any advice would be greatly appreciated.

Thank you very much,

Chris

P.S. The issue goes beyond whether a font is or isn't present. For
example, Spice's budget tablet supports Tamil text, but shows it in
an
archaic, formal script that many cannot understand.

--
Post: opendatakit@googlegroups.com <javascript:;> <javascript:_e({},
'cvml',
'opendatakit@googlegroups.com <javascript:;>');>
Unsubscribe: opendatakit+unsubscribe@googlegroups.com <javascript:;><javascript:_e({},
'cvml', 'opendatakit%2Bunsubscribe@googlegroups.com <javascript:;>
');>
Options:http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com <javascript:;> <javascript:_e({},
'cvml',
'opendatakit@googlegroups.com <javascript:;>');>
Unsubscribe: opendatakit+unsubscribe@googlegroups.com <javascript:;><javascript:_e({},
'cvml', 'opendatakit%2Bunsubscribe@googlegroups.com <javascript:;>');>
Options:http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com <javascript:;>
Unsubscribe: opendatakit+unsubscribe@googlegroups.com <javascript:;>
Options: http://groups.google.com/group/opendatakit?hl=en