[sword-devel] Sword release roadmap suggestions

[Martin Gruner]

Hi Chris,

thank you for this valuable information. =)

> I think we should go ahead an do a 1.5.3 release of both Sword & BibleCS
> this week or next.  I think these should include only the functionality
> currently in CVS with bug fixes if necessary.  (The ICU stuff &
> right-to-left changes in the new BibleCS alpha are not completely in
> CVS, and should be left out of the next release I feel.)

Yes. Let me say thank you and thank everybody else who is actively working on 
sword. It is making very fast and nice progress!

> The other major aspect of 1.5.4 will be moving much of the functionality
> that gets repeated in all front-ends back into the API.  Rather than
> creating their own encoding & markup filters (GBFHTML, Latin1UTF8,
> UnicodeRTF, etc.), front end authors will simply tell SWMgr which
> encoding & markup they desire and it will handle any necessary
> conversion for them.  This not only simplifies front end creation, it
> allows addition of new formats to the library without requiring any more
> than a recompile.

A very good idea! But the markup part should be flexible enough to support 
frontend specific handling of HREFs (references, footnotes etc) as well as 
other things like color etc. We should discuss this. Maybe the markup part is 
too complex to do in sword?

> Something I would like to see before we get to Sword 1.6.0 is a
> switchover to UTF-16 from UTF-8/Latin-1 for all internal processing.
> This will speed up all ICU calls since they won't need to do UTF-8 to
> UTF-16 to UTF-8 conversion and should speed Win32 & WinCE for the same
> reason.  Most of all, it simplifies searches and other internal
> character processing.  I don't see much advantage to UTF-32, even though
> we already have one module that uses characters that need surrogate
> support (characters outside of Unicode Plane 0, > 0xFFFF, that need 2
> 16-bit values in UTF-16).  This is a big change, though, and will
> require breaking most of our filters as we convert them to use 16-bit
> values instead of chars.  UTF-8 output will still be supported, of
> course.  And I have no plans to support UTF-16 encoded modules because
> either SCSU or UTF-8 should always encode them using equal or less space
> and the byte-order issues raised by UTF-16 encoded file would just cause
> performance problems on some platforms.

>From the perspective of a frontend programmer I only wish to be able to still 
get and put everything in UTF-8.

Martin