Talk:Choosing a SWORD program

Project Links

For the front end links, we need to choose either links to homepages or links to wiki pages, not both. --Osk 06:27, 28 February 2009 (UTC)

Localization

I would recommend not listing that front ends can be localized. I don't think that actually matters to any users. What is important, and hence what we should list, is the existing list of UI localizations for each front end. (Ability to display RtoL text is a separate issue, independent of UI localization, so I think that's fine to keep.) --Osk 06:42, 28 February 2009 (UTC)

The original intention of each entry in the table was/is that it gets removed if a feature is present in all frontends. This one means little to end users , but it means something to translators and developers. If we can find out whether SwordBible can get translated easily then all are localisable and the feature should be listed above the table

Archiving

"Archiving" means what? Removal to another location? Compression? Consider whether this is a feature that is actually important to users in their process of making a decision between front ends--not just an attempt at one-upping. --Osk 01:45, 1 March 2009 (UTC)

Osk - if you mistook this table as one-upmanship then you are badly mistaken. I tried to unravel the narrative everyone seems to give about their frontend. Archiving is GS tem for keeping modules out of sight but available. It does what it says on the tin. BT has (I think) a different solution to the same concern. The tables are quite obviously increasingly not anymore for first time users, but that is quite irrelevant. We can always finally extract the core points for a message to users, but there are other uses for these tables possible too - for developers, for translators - where to concentrate effort etc refdoc:talk

Xiphos's concept of archiving is different than what is explained here. It does not actually 'hide' the module; it will still be available after archiving. Archiving zips up the module (preserving correct paths) so that it can be easily transferred to another machine. This is handy for user-created modules if you want to share them with someone else, and will probably be an integral part of future plans to allow uploading modules. Also, you can archive a module, then remove it (which would also affect other apps). Xiphos provides no way for 'hiding' without complete removal (although it probably should). However, the archiving feature is unique and provides benefit to end users. --Mwtalbert 22:16, 3 March 2009 (UTC)

Complex Scripts

What does "Complex Scripts" mean in this context? When people talk about complex scripts, they're not generally talking about basic things like Arabic shaping. They generally mean things like contextual shaping of Indic or rising baseline Arabic calligraphy. And this feature could have differing values for a single front end, depending on the platform. --Osk 02:03, 1 March 2009 (UTC)

I think originally Peter meant support for Myanmar which BibleCS lacks. I take issue with the notation (with Uniscribe) because I *have* Uniscribe, and have told BibleCS to use a font that I *know* has the correct symbols, yet BibleCS can still not display the text. --mwtalbert

This is a bad misunderstanding or misquote. I never singled out BibleCS in this matter. All frontends failed BurJudson, some worse some less bad. The level of support can clearly not always get answered with simply yes/no. But as such it is an important matter - as some frontends are constitutionally incapable of rendereing such scripts and others require additional work (which is fine if it works) refdoc:talk 23:04, 1 March 2009 (UTC)

So, should we change the category "Complex Scripts" to "BurJudson works"? I could release a module (assuming I could get permission, that is) that would universally fail because none of the existing front ends can support its writing system. Would we then mark all front ends as not supporting complex scripts?

The notation about Uniscribe is more descriptive than a "yes" or "no", since the best possible result any front end can report is support of some complex scripts. Unless I'm simply mistaken (which is certainly possible) and BibleCS's RTF control doesn't actually use Uniscribe, the failure to correctly render BurJudson is simply indicative of Uniscribe not completely supporting that script yet. (I will investigate whether I'm wrong about Uniscribe.) --Osk 20:59, 1 March 2009 (UTC)

If you could explain how you managed to get BibleCS to do anything more than display little boxes for the text in BurJudson, I'd be interested in knowing. --Mwtalbert 04:43, 2 March 2009 (UTC)

I just updated BurJudson to expect Padauk by default so following an update or manual font change it should work for you, but prior to that it had required the PadaukOT font. The latter has since been discontinued since SIL added OT tables to their font. If you have another Unicode font with Myanmar support, you will have to set it either in the .conf directly or via the module preferences panel. --Osk 08:46, 2 March 2009 (UTC)

I expected that when I changed all the Bible texts to use Padauk it would attempt to use that for BurJudson. Apparently it doesn't work that way. I changed the .conf to use Paduak instead of PadaukOT and it works now (at least to the point of showing the characters, I didn't check specific rendering issues).--Mwtalbert 03:29, 3 March 2009 (UTC)

It should probably be mentioned, since BurJudson is being taken as indicative of complex script rendering capability, that Myanmar text is probably the least likely to exhibit correct rendering of any script. Myanmar was first added to Unicode at version 4.0 in 2003. Apparently no one liked the encoding model, so it was radically changed in Unicode 5.1 (released last April). As a result documents may not be updated to Unicode 5.1 encoding (I doubt BurJudson has been)--although many fonts have already been updated to Unicode 5.1's Myanmar encoding model (Padauk and PadaukOT both are). Furthermore, text layout engines may or may not be updated. (I would guess that Graphite has been updated, but the latest Uniscribe has not.) So it would be reasonable to expect a bit of chaos within the world of Myanmar text for the next couple years. --Osk 08:46, 2 March 2009 (UTC)

Fair point. Do we have any other module which tests well the same concepts? refdoc:talk 09:10, 2 March 2009 (UTC)

I'm (slowly) working on a script demo module, which will include an entry for each script identified in ISO 15924. I had intended it for testing transliteration facilities, but we can also use it to test rendering in general. More immediately, the UDHR module contains texts in many languages, using many scripts, a good portion of them complex (though about 80% of the entries are probably either Latin or Cyrillic). Notably, UDHR contains the same Myanmar text encoded using the Unicode 4.0 model (called BURMESE (UNICODE 5)) and the Unicode 5.1 model (called BURMESE (UNICODE 6)). --Osk 10:29, 2 March 2009 (UTC)

I also think the column should go into module support next to the RtoL support - I will do this later today. refdoc:talk

Image GenBook support

Users do not know what GenBook means. Are images really unsupported in any kind of module type? --Osk 02:03, 1 March 2009 (UTC)

There is a bug in Bible Desktop, that has been fixed in SVN, that did not properly determine the proper display a Dictionary (LD) with images that is also marked Category=Maps. BD/JSword support all image types that Java can render. I don't know what that is, but at least it includes all the types that we would use in a module.--Dmsmith 14:01, 1 March 2009 (UTC)

Image Formats / other Image Module support

These are not things that an end-user cares about. --Osk 02:03, 1 March 2009 (UTC)

I agree. I think this can be generalized to a bigger issue. Karl has a wonderful repository of non-official, very useful modules. These may show problems in end-user applications. For example, if his map modules have png images, then there is some front-end that does not support it. The user cares about available modules working or not working.

I already mentioned the Bible Desktop bug regarding LD image modules marked as Maps. While I routinely test JSword/BD against all CrossWire modules, I don't against Karl's repository. Given it's visibility and value, I think I should.

The bigger question is how do we note short-comings/bugs in a particular application? I don't think this is the appropriate venue. (Though I don't mind JSword being called out as lagging SWORD.)--Dmsmith 14:10, 1 March 2009 (UTC)

I have to run to church right now, but as soon as I get a chance, I'm going to nuke the whole Images category down to a single, uninformative "Supports Images" column, universally marked with "yes". --Osk 18:57, 1 March 2009 (UTC)

What was this, Osk? I have restored the section and would appreciate if it stays up. This section has meaning and is reflected in existing modules refdoc:talk

To be clear this is not about bugs but about frontend limitations - so once it is clear that all frontends can actually deal with all module types then the point simply gets deleted and amalgamated in the "all frontends do xyz" list. refdoc:talk

All front ends support basically the same set of features, with respect to images, in either their current release or in SVN. And these are not end-user concerns, they are developer concerns. Users don't know which format module images use or which kind of module they will appear in, they simply expect content they download to work. So this whole section is completely unnecessary to users. Front end developers don't need it either, since all limitations have already been worked around (namely, the SVN versions of all front ends should now support JPEG & PNG images in all module types). (I don't consider other formats necessary, so we won't ever release content that uses other image formats.) The particulars of which versions of various front ends support which formats & which module types may be useful to content developers, but I can advise them of that during the submission process, and this need not be included as part of a feature matrix aimed at end users. --Osk 03:16, 2 March 2009 (UTC)

Do they? If all frontends (at current svn level) can have all module types laced with images this column will obviously go the same way as any other column which is all round "yes". Wrt image formats - svg is the one notable format which brings enormous benefits (due to its translatability) , so svg support is something which is valuable. refdoc:talk 09:01, 2 March 2009 (UTC)

There are already modules that have images in gif format, so I think it should be listed. Not sure why it should *never* be supported. --Mwtalbert 00:33, 5 March 2009 (UTC)

Study Notes

What are study notes in the tagging section? Benpmorgan 09:00, 1 March 2009 (UTC)

Study notes are simply a text editor type note taking facility which then can get exported - e.g. for sermon preparation. This could have gone just as well to other, or where ever, but in the end it is often the final result of a search and bookmarking exercise that you go and write something up which tyou then print and take somewhere else. refdoc:talk 22:52, 1 March 2009 (UTC)

Personal study notes in a multi-user OS may be global (all users see them) or individual (current user sees only his/her own). Could we include a table row that shows which applies? David Haslam 20:58, 3 March 2009 (UTC)

BibleCS Portability

BibleCS is not properly portable. For once I'm not even applying the stringent PortableApps.com "stealth" requirements. It depends on some libraries (which they are escapes me) and controls which may not be installed on the local user's machine. Also, it leaves stuff all over the place in the registry, and registers itself and so on in a way which leaves orphaned entries in the registry in a most horrible way. What I really complain about though is the fact that on some computers, it won't even just be "Just Works™". For reference on some issues, see this thread on PortableApps.com. Chris Morgan 10:53, 1 March 2009 (UTC)

I have just read the thread and I don't think it applies. BibleCS is properly portable wrt to the registry, but it takes some work. First, one has to install it to the default location, which uses the registry. Then one copies c:\Program Files\CrossWire\The SWORD Project to a thumb drive. Then it is un-installed from the local machine. This is a one time operation. Second, the user has to use the built-in module installer and not the windows modules downloaded from CrossWire in Windows format. The latter uses the registry. Is it this specific path that prevents the "Just Works". It would be simple enough to zip the contents of that directory and make it available as a portable download. Would that qualify as "Just Works"?

As to the library problem, if you can recall them that would be great. This it the first I have heard of this.--Dmsmith 14:28, 1 March 2009 (UTC)

It registers all sorts of messy things... in my books, that ruins it, but it still Just Works™. See my comment a bit lower down as to the rest. Absolute paths can be a big problem though. Chris Morgan 06:31, 2 March 2009 (UTC)

You can't recall which libraries it requires because it doesn't. Everything needed by BibleCS is contained within its directory. It writes a few registry entries, but does not need them for its own functioning (only for private protocol calls). And those registry entries really could be deleted upon exit, if desired. So if you move BibleCS around to computers other than that to which it was installed, it will work perfectly fine. --Osk 18:53, 1 March 2009 (UTC)

Got a feeling it was the rich text component or something. The protocol and executable registration is a nuisance as well, and I'd need to test whether it was really dependant on these - if so, it's unlikely to run as a limited user on a new machine. Chris Morgan 06:31, 2 March 2009 (UTC)

FWIW I consider this discussion a bit beside the point. If something runs off a USB drive it is portable in all practical sense. If it leaves a little bit of bit-garbage behind then it is still portable, but not securely portable in the sense that no one will ever know you used it there - but that is a second matter. If the reason that you do not want to leave anything behind is indeed your physical or job security then even portable apps has a massive problem - and that is teh fact that USB drives get logged by Windows - at least if you do a half decent set-up. The only way to securely (in that particular sense) deploy an application is by running it off a bootable CD. refdoc:talk 08:52, 2 March 2009 (UTC)

I'm not trying to get involved in this discussion, as it doesn't matter to me at all. However, I just uninstalled BibleCS from my Windows 7 computer, and it left icudt38.dll, InstallManager.exe, and userprefs.conf in the installation directory. Perhaps something is wrong in the uninstaller? --Mwtalbert 03:27, 3 March 2009 (UTC)

small addition. I could not find any registry keys left behind. Also, I performed the uninstall on XP, and it left the same files behind, although the installer briefly flashed that it was uninstalling InstallManager.exe. --Mwtalbert 05:54, 3 March 2009 (UTC)

My opinion as the original author of the installer: The uninstaller leaving modules and application generated content is not a bug. But leaving icudt38.dll and InstallManager.exe is. Conceptually the installer installs two parts: BibleCS specific parts (the executables and their dlls) and shareable parts (i.e. locales.d, the modules and other things that all SWORD apps can use). I think it should have an option regarding the shareable parts. It probably should put these elsewhere and not in "The SWORD Project" directory.

My personal opinion is that leaving anything at all under Program Files is a bug. As a user, I would expect to be able to delete that and not delete my personal preferences as I would expect them to be stored with all my other application preferences. That's beside the point here. If it helps any, I did choose to leave the shared parts during both uninstalls. Perhaps InstallManager.exe and icudt38.dll got put in the wrong place in the uninstall script?--Mwtalbert 18:15, 3 March 2009 (UTC)

OK, I'll try again. Osk reverted my correction last time I did it. BibleCS, when run from a USB disk, will leave stuff behind; for starters (I haven't done a full scan, but these are the ones I remember and found):

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\sword.exe (put in by BibleCS)

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs\[install path]\sword.exe (not sure, probably put in by BibleCS)

HKEY_CLASSES_ROOT\sword (sword:// protocol, put in by BibleCS, not sure if BibleCS depends on it)

If any of these are created by BibleCS if they are not there, which they are, then it does leave traces on the host machine.

Perhaps we could also say "don't use the Install Manager", as I understand it just plain doesn't work (it was the main reason Kevin Porter abandoned The SWORD Project for Windows Portable). At least, though, can we remove the word "no" in "leaves no traces on host machine" once more? Chris Morgan 06:17, 4 March 2009 (UTC)

No, actually, no I didn't. --Osk 15:16, 4 March 2009 (UTC)

It was me who changed this. refdoc:talk

Chris, did you find these keys on a computer that did not have them after running sword.exe or InstallManager.exe from the USB drive? I find that hard to believe. My experience, if you use the installer to install it to a USB device, it will leave traces on the computer on which you did the install. But if you install it temporarily to a computer and copy c:\Program Files\CrossWire\The SWORD Project to the USB drive and then use that USB drive on a different computer, it should not change the registry of that machine. AFAIR, it is the installer that puts these keys into the registry, not the program. AFAIR, the InstallManager.exe does not change the registry, either. This program will use the mods.d and modules folder in the same directory to write it's modules.

In the thread last year "[GnomeSword-developers] win32 installer for testing", Chris Little said: "I'm not sure whether you're setting the private protocol handler in the installer or in the GS app, but you should be aware that BibleCS sets the handler to call itself every time it is launched. (It also sets the private protocol handler used by Logos iff it is not already set.)". So just based on that I would say it does set registry entries on startup, not on install. Not sure about installmanager, though Benpmorgan 02:31, 5 March 2009 (UTC)

Windowing and Text Display

I have taken out the Complex Scripts bit and shoved into Module support - it belongs more into that category. The narrative for windows display I think is best expressed in an adequate screenshot. The relevant principles which can be answerd with yes/no are - so far, I think, please add

1. Un/linkable texts - e.g Commentary and Bible or several Bibles (both needs to be present - linking and unlinking)
2. Parallel display of whole passages in a side by side fashion,
3. the ability to hide unneeded Windows/screen areas.
4. The ability to have several texts of a kind open at different books/chapters and being able to switch forward and backward
5. Unconnected passages on one tab/window

A fair number of BD's list of Others is conceptually also an expression of verse lists

refdoc:talk

What exactly is meant by poetry display here? Xiphos does display poetry with the correct line breaks and indentation (as in the module, but not exactly as the printed ESV as BPB does)--Mwtalbert 22:12, 3 March 2009 (UTC)

Installer

Refdoc, I see that you have that BibleCS's installer sorts modules by language. I don't see that. I see it by type only.--Dmsmith 12:46, 3 March 2009 (UTC)

Have I? mistake. This layout of the table is much better, but i still get confused occasionally. Please do check. Thanks refdoc:talk Sorted. refdoc:talk

Soon?

I really do not like "soon" as an entry. What is the cut off point for soon? I'd rather that things are yes/no/partial/not applicable and once something is implemented it will change to yes. Otherwise we will have a totally meaningless table. My honest/humble opinion. refdoc:talk 13:55, 3 March 2009 (UTC)

I had a second look at what you marked as soon and I think this is actually fair enough - but I remarked it as partial. refdoc:talk 14:19, 3 March 2009 (UTC)

I think soon or planned are fine categories, but it needs to have specific meaning. To me "soon" means that the capability is in beta and is generally available for testing. Perhaps, "beta" would be better than "soon" and it would have a link to the beta. To me "planned" means that the feature has been checked into source code control and will be part of the next release. Right now we have "yes" with footnotes stating this or that will be available with 1.5.12. Perhaps, "ready" would be better than "planned".--Dmsmith 14:25, 3 March 2009 (UTC)

Indexed Search

We have listed the technology, but what are the practical differences? Do all applications index on the same fields? Presumably yes, in which case the technology should be come an internal like other toolkits used. refdoc:talk 16:21, 3 March 2009 (UTC)

The practical outworkings of above technological differences could/should form simply new rows - like crossboundary searches etc.refdoc:talk

I agree with the new rows. Not sure what they should be.

Compared to SWORD (with key, body and strong), JSword indexes these and additional fields, allowing:

• note:(Abraham) - Find verses with notes about Abraham
• xref:(John 3:16) - Find verses with cross-references to John 3:16. (JSword will normalize the reference to an OSIS ID.)
• heading:(Moses) - Find verses with headings containing Moses.

JSword indexes also allow stemmed searches. It also has different analyzers for different languages. Our Thai analyzer, is necessary to get the word breaks correctly.

The other thing that a search engine bring is a search syntax. Each is different. CLucene and Lucene have the same syntax. I presume BPBible and MacSword have a different one.

Even with Lucene and CLucene, there are differences. JSword can use a SWORD index, but SWORD can't use a JSword index. The reason is that JSword is using Lucene 2.x and Clucene is compatible with 1.4.x. These have different storage formats. CLucene will never catch up with Lucene. We moved away from 1.4.x for outrageous performance gains.

The other thing that JSword has (and I think some others do) is passage restricted searching. This is layered on top of the search engine. If there is a different engine being used by an app, this feature might not be there.

That an app uses Lucene/CLucene/Apple Search/Custom is not a user concern, but it's impact is. One impact of MacSword using Apple's search is that it is available to Spotlight, the global search of the Mac. This is awesome! --Dmsmith 18:00, 3 March 2009 (UTC)

Which make sme think whether at least Linux applications could not do the same - beagle etc. refdoc:talk 18:24, 3 March 2009 (UTC)

In addition to this, BibleTime also indexes several fields that Xiphos and SPW do not. I believe they include the fields that JSword indexes. This is an important distinction, and one where the official Sword indexing is lagging behind these others (at least as regards fields indexed, but it's a definite negative imo) As far as I know, only Xiphos and SPW are using the official Sword indexing --Mwtalbert 18:09, 3 March 2009 (UTC)

Bookmarking, Tagging, Listing and Notes

The second table under this heading should be transposed, and should use abbreviations for the frontend applications. David Haslam 18:38, 4 March 2009 (UTC)

No. It is the source table for the first table it is the last table not completely imported into the vertical format. Once completely imported it will get deleted. Reason for the delay being thet I a) had no time for it yet and b) there are some things which do not add up in my testing refdoc:talk 19:26, 4 March 2009 (UTC)

Do any frontends or modules also install fonts?

Another question to ask of each application is, "Do any frontends or modules also install fonts?". David Haslam 19:38, 4 March 2009 (UTC)

none do as far as I am aware refdoc:talk

The Xiphos Windows installer does install fonts --Mwtalbert 20:59, 4 March 2009 (UTC)

Not sure if this is what was meant. More rather would/could the programme chase up needed fonts and download them. Or did I misunderstand you David? refdoc:talk

Display of information about the source text?

Frontends differ in the amount of information they display about the source text for each module, and on how they manage this. This too needs a comparison chart. It's especially important for textual provenance and copyright status, etc. It is a chore to always have to refer to the CrossWire downloads page. David Haslam 19:49, 4 March 2009 (UTC)

Syncrhonized scrolling?

Do all frontends that support parallel texts also provide an optional setting for synchronized vertical scrolling? If not, please compare. David Haslam 20:19, 4 March 2009 (UTC)

do any? refdoc:talk

GIFs

I removed the note about GIF in graphics format support, changing it to JPEG only. I can see no reasonable reason to support GIF in Sword. PNG is far superior at all of the things GIF was previously used for. You can achieve the same or better quality with greater compression using PNG rather than GIF. Also, we don't actually support GIF on BibleCS, though it would take about 10 minutes to add support for it. (None of this has anything to do with the patents that encumbered GIF in the past, since they're all expired.) --Osk 00:14, 5 March 2009 (UTC)

As I noted above, there are already modules using GIF; there may be cases where content is already in GIF, in which case it's perhaps easiest to just leave it that way. If it's trivial to add it, why not just add it? --Mwtalbert 00:47, 5 March 2009 (UTC)

To my knowledge, there is only one module using GIFs, and it's not CrossWire content. Material in GIFs can be bulk converted to PNGs. The only officially supported image file format is JPEG (although the first image test module actually consisted of BMPs). I think it's very reasonable to expand that to include PNGs, since they are useful in a variety of circumstances where JPEG is an inferior choice. But I can't see anything that GIF offers that PNG doesn't do better. --Osk 03:04, 5 March 2009 (UTC)

BpBible and font handling

I think there is some serious misunderstanding here - unless I do not understand BpBible or do something seriously wrong. When I run BpBible I can change the fonts used to display material. But I can not set a font for a specific module - FarTPV with Nazli while ESV with Times new Roman. This is meant with font per module - or All Farsi modules get to use Nazli while all English ones use Sans Serif. The font handling of BpBible does not work when e.g. an Armenian module and a Farsi commentary is open as there is no font handling both languages. So I reverted Ben's contribution here. refdoc:talk 00:39, 5 March 2009 (UTC)

Are you using 0.4? It does this. Benpmorgan 00:43, 5 March 2009 (UTC)

refdoc: file->set fonts--Mwtalbert 00:47, 5 March 2009 (UTC)

.Yes I use 0.4. But using file-setfonts results in all texts on dispolay changing their font. refdoc:talk Sorry, my apologies Ben - I had downloaded 0.4 but was using 0.3 on this laptop. I test on a couple of different machines and got mixed up. This is now corrected. refdoc:talk