Am 21.01.2009 um 05:29 schrieb Chris Little:
ICU is not a requirement for using UTF-8 modules; rather than use
ICU, most frontends (certainly BPBible, GnomeSword, BibleTime and I
think MacSword as well) have defined their own string manager code
(generally using the platform - qt, glib or python).
DM is really correct that we're coming to the point where ICU is
going to be a necessity for app i18n/l10n. ICU provides up-to-date
collation and normalization facilities that are a necessity for
correctly managing Unicode data in anything other than a braindead
manner (like our byte-ordered LD entries currently are). Searching,
including functions like accent normalization and correct case
folding, aren't possible without certain level of Unicode knowledge
within the app. And when we actually think about doing lookup via
transliteration (something every other piece of professional Bible
software handles) we can either go to the effort of rolling our own
transliteration facility or use the ready-made one provided in ICU
(as Logos does).
MacSword may be exempt from needing ICU for a while, as would any
other MacOS or iPhone program, for the simple fact that many of ICUs
functionality should be available through platform APIs. That's
because Apple has included ICU on both of these platforms, though it
won't ever be the most recent release and may lack some data.
Additionally although they include the library, they don't prodide the
headers. So you couldn't use it to compile something.
Manfred
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
