Difference between revisions of "Talk:Choosing a SWORD program"

Revision as of 13:22, 3 March 2009

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

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)

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)

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.

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

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