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

Revision as of 23:27, 1 November 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.

Does localization extend to using different numerals for chapter & verse navigation & verse markers ? Or do some Frontends retain digits 0...9 even when everything else is localized? David Haslam 19:02, 6 March 2009 (UTC)

I think BD is the only one that does bi-directional number shaping. That is the user can type in localized digits and BD will shape it into 0-9 (if not already as such). And when displaying it transforms from 0-9 into the user's localized representation, if different. We only do this for user input and program generated numbers. We don't do it for numbers that are explicitly in the text. IMHO, text should be displayed as is. (For ICU's Javadoc on it see: http://icu-project.org/apiref/icu4j/com/ibm/icu/text/ArabicShaping.html).--Dmsmith 20:55, 6 March 2009 (UTC)

Here is A Table of Numbers in various scripts from Arabic to Tibetan (and more). David Haslam 15:16, 7 March 2009 (UTC)

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)

I'll put together a PortableApps version of BibleCS this weekend so that we can put the whole issue to rest. No need to continue debating, but continue if it makes you happy. --Osk 06:10, 5 March 2009 (UTC)

A PortableApps version now sits in SVN. Running with the commandline argument "--noreg" will disable writing to the registry. When 1.5.12 drops, I may package a PortableApps installer. --Osk 03:12, 9 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

The program FlashCards (Greek/Hebrew learning tool) will load a font without installing them to the local OS. Not installing them locally is important for PortableApps' "leave no trace." I've thought of adding this capability to JSword and distribute some SIL fonts with it. It would be cool to be able to specify by URL some fonts to download. My thought it that we would host a open source fonts on the CrossWire server and serve them as we do modules and a new conf's entry FontSource would provide that URL.--Dmsmith 12:20, 5 March 2009 (UTC)

You can install and uninstall fonts temporarily with a DLL call and a window message. In NSIS, it's System::Call "gdi32::AddFontResource(t'X:\Fonts\file.ttf')i .r2" and System::Call "gdi32::RemoveFontResource(t'X:\Fonts\file.ttf')i .r2", each one followed by SendMessage ${HWND_BROADCAST} ${WM_FONTCHANGE} 0 0, where HWND_BROADCAST is 0xFFFF and WM_FONTCHANGE is 0x001D. r2/$2, the return value, gets filled with 0 if it failed. You'll need to convert this into another langauge if you want to use it other than in NSIS though, of course. Chris Morgan 06:40, 19 May 2009 (UTC)

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)

Among the frontends with which I am familiar, BD does this very nicely. David Haslam 18:32, 5 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

BD, MS, SPW, (others?) show their parallel Bibles in the same pane with a single scroll bar. BD also allows for commentaries to be shown in parallel view. So all of these have synchronized vertical scrolling. In BD (and perhaps the others) you can choose to show Bibles in different views (tabs or windows) and each has their own scroll bar. From what I have heard, but not seen, I believe Xiphos is unique in that you can tie any two verse number based views together (i.e. Bibles and/or Commentaries) and scrolling one will scroll the other so that they show the same material (in so far as is possible).

If Xiphos has this, I do not know how to do it :) I've considered adding a feature like this and would like to sometime, but it is not there now.--Mwtalbert 22:12, 5 March 2009 (UTC)

I should add that Xiphos does allow parallel scrolling in the same manner as others. Not with commentary (yet).--Mwtalbert 22:28, 5 March 2009 (UTC)

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)

I think there is one argument I can see for (whatever not officially supported) image format - and that is copyright restrictions. Stuff like "distribute at will, but do not change in any form or way". Having said this I have not come across this wrt image formats and would consider a limitation of formats which ensures that all frontends can make equal use of it is a useful thing. What might be worthwhile though - and that goes way beyond this particular comparison page is a test module with every semi-relevant image format under the sun thrown in and then we could map which frontends (and not just the PC/Mac) ones can deal with them. It is clear that Webkit and Xul derrived fronends are pretty limitless in their support, while others might be a lot more restricted. It would be good to know. refdoc:talk

Osk, this is a strong statement, even though I agree with it. I think that our "module making" guide should be explicit in stating "Only use jpeg now and after 1.5.12, you can also use png. Using any other kind of image will result in a module that cannot be used in one or more SWORD applications. Submission of a module with other image formats will hinder its acceptance into the CrossWire repository as such images will need to be converted into a supported format."--Dmsmith 13:11, 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

Software & module updates - checking for updates via a proxy server?

If your frontend is installed on a computer that accesses the internet via a proxy server, when the application checks for either software updates or module updates, one of the features we should expect is whether this has configurable support for access via a proxy server. Please compare on this. David Haslam 18:26, 5 March 2009 (UTC)

For an example of a program that does this nicely, see PDF-XChange Viewer. David Haslam 18:29, 5 March 2009 (UTC)

I think all which use a module manager do this.

Xiphos does not allow specifying a proxy server and I have not seen such a feature in any of the other programs. In linux, Xiphos should pick this up from the environment. On Windows, I do not know what the behavior would be. For Xiphos, I suspect that this would be something that would have to be added to the engine, although I don't know for sure. Perhaps there is an environment variable that curl will pick up. Although we haven't had reports yet, this is something that concerns me. I know from experience that configuring a program to use FTP through one or more firewalls, plus a proxy server is very difficult, particularly when the program doesn't allow setting the proxy manually but expects the environment to handle it. So in summary, no not all which use the module manager do this, certainly not Xiphos. --Mwtalbert 23:41, 5 March 2009 (UTC)

Just wanted to add that the first time I ever used GnomeSword, I was behind a proxy (this was in linux, of course). I don't believe I ever got it working properly.--Mwtalbert 23:55, 5 March 2009 (UTC)

I just realized that BibleDesktop does allow specifying a proxy server. I believe this was why I first used BD rather than one of the other frontends. Kudos, DM --Mwtalbert 23:58, 5 March 2009 (UTC)

Mwtalbert, thank you. The other thing that we do is http rather than ftp. Many firewalls block ftp but not http. (We still have the old ftp code lying around, but it was being blocked by XP SP2) So when we added http we also added proxy.--Dmsmith 04:04, 6 March 2009 (UTC)

Friendly dates?

What is meant by friendly dates? David Haslam 18:56, 6 March 2009 (UTC)

23 of February instead of 02.23 refdoc:talk

Also it should be in the user's language.--Dmsmith 20:40, 6 March 2009 (UTC)

Footnote expansion

The reported "1221 character limit" in BibleCS footnotes is an issue somewhat--and there's a fairly simple fix that we put out in some test builds back when the NET was being encoded. But it should be borne in mind that the NET, as encoded, is not official CrossWire content and warnings were given at the time it was produced about long footnotes. It's not clear to me that this is really a failing in BibleCS, rather that the NET is badly encoded (and I know others have the same opinion, if for other reasons, such as bad character encoding). So, ability to display improperly long footnotes should be fixed in BibleCS, but the single case where this arises as a problem should also be repaired. --Osk 19:56, 7 March 2009 (UTC)

This problem is not just for the NET. I have seen other things truncated, such as Strong's entries. --Mwtalbert 21:22, 7 March 2009 (UTC)

Okay... I spent a couple minutes testing this and can explain the behavior. There is no "1221 character limit". Firstly, there's no set character limit, there's actually a size limit, which depends on the text itself unless you use a monospaced font and which depends on the font size you use itself. Almost all notes, Strong's entries, etc. will display fine, assuming you don't increase the font size. But I have verified that Eccl 1.1 note 1, the longest note in NET according to Karl, does still get truncated. So I still think BibleCS should apply the NOTES commentary virtual module that we tested briefly. And I still think the NET is poorly encoded. --Osk 02:20, 8 March 2009 (UTC)

one of the first things I do is increase the font size. You're saying that it shouldn't be considered a bug if you can read it without increasing the font size. This is fairly horrible program design in my opinion. It is surely something I would want to know as a user. Again, I haven't actually tried the NET, I saw this with other notes. See, for example, http://picasaweb.google.com/ransom1982/Gnomesword#5277582407118819138. --Mwtalbert 09:26, 8 March 2009 (UTC)

No, I didn't say it wasn't a bug. The report was erroneous. I have corrected it. --Osk 11:23, 8 March 2009 (UTC)

Except that I wouldn't consider 15 lines extremely long. Perhaps it should say something about depending on the font size. --Mwtalbert 16:43, 8 March 2009 (UTC)

So I tried it at my preferred font size of 14pt. It truncates after about 15 lines, which happens fairly frequently for the NETfree I was testing, and for strong's references routinely for another module I have. This module is not using the default strong's but one with somewhat longer definitions (privately created). In addition, with NETfree, many of the Greek words were unreadable in the footnotes. --Mwtalbert 09:43, 8 March 2009 (UTC)

If the module is shipped with a default font that has inadequate precomposed Greek coverage (or with no default font at all when the user has his default font set to one with inadequate Greek coverage), then, yes, Greek obviously won't show up correctly. --Osk 11:23, 8 March 2009 (UTC)

Actually, this isn't obvious at all. The program should either use Window's normal font fallback methods or provide its own. Windows by default has excellent fallback mechanisms so if any font on the system has the symbol, Windows will substitute that font. Xiphos is dependent on Pango which has chosen to ignore the Window's methods for this and instead provides another fallback mechanism. It isn't as reliable (imo), however, it will certainly allow multiple fonts to be used in a single text to fulfill all of the symbols needed. So if BibleCS can't do this at all (and it can't as far as I can tell) that's another serious limitation. There are relatively few fonts with good enough coverage on their own to cover multiple languages in the same text, so fallback mechanisms are essential. --Mwtalbert 16:43, 8 March 2009 (UTC)

I'll try to check into this further, but BibleCS does use a font fallback mechanism (there are more than one used in Windows). You can see this by loading a Chinese text, for example--they don't specify fonts, but grab the correct font using (I believe) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink. The problem with relying on such a fallback mechanism is that they trust the fonts when they report their coverage. The font in this case reports that it supports Greek, which is correct. Arial & Times New Roman, which are the most common default fonts, depending on your color scheme, support basic Greek, but not pre-composed polytonic. The only other default font in one of the shipping schemes, Tahoma, has no problem displaying polytonic Greek. This comes down to a module error, more specifically a .conf error, since it could all be corrected by specifying a different font. --Osk 03:08, 9 March 2009 (UTC)

Well--my bad for having implemented this and then deleted or lost it, but I dug through the mailing list archives for the discussion of virtual modules and think it should be fairly easy to re-create the NOTES commentary virtual module. Some further discussion of this and other virtual modules here: Whiteboard/Virtual_Modules. --Osk 08:28, 8 March 2009 (UTC)

Poetry Indentation levels

Probably 1 level or 2 level does not accurately describe what is being referred to here. BPB has poetry support for the ESV to match the printed version. This requires indenting on more than just the first line (which is what Xiphos does). See http://www.gnpcb.org/esv/search/?q=psalm+1&src=esv.org for a comparison. Also search the sword-devel archives for this "Poetry and indented lines".

The ESV SWORD module does not mark up 2 level poetry using standard OSIS. OSIS does not support such a notion. When I created the OSIS for the ESV, I preserved the markup in the original file using types. So there are <l> elements with type="x-br". This is entirely an invention of mine. It is not reasonable to have any x-types that I make up for a particular module as being meaningful. That is, I don't think any frontend should look for x-br on a <l> element and do something different. If we update the module, this may change. If we discuss it and then document the behavior in OSIS Bibles that would be fine.--Dmsmith 19:58, 8 March 2009 (UTC)

This looks like an appropriate response to the email I referenced above, which got no replies. Perhaps you should reply to it? --Mwtalbert 20:16, 8 March 2009 (UTC)

I'd be glad to, but I'm not sure which one you are referring to. Would you mind giving date and subject? Thanks.--Dmsmith 22:53, 8 March 2009 (UTC)

As above, subject is "Poetry and indented lines", date is 11/04/08. Direct link http://www.crosswire.org/pipermail/sword-devel/2008-November/029486.html --Mwtalbert 00:02, 9 March 2009 (UTC)

Actually, according to the email, BPB is using the "x-indent" marker for this, which seems like a very reasonable thing to do. --Mwtalbert 00:05, 9 March 2009 (UTC)

I've replied to the email and based upon Osk's response I have updated OSIS Bibles#Marking poetic material to indicate that the level attribute indicates indentation. Now it is a matter for SWORD and JSword to do something in their renderers if they don't already and for modules with non-standard indentation to be fixed up.--Dmsmith 18:28, 9 March 2009 (UTC)

Print options, scope and features

It may be useful to compare print options, scope and features for all the frontends. David Haslam 11:03, 14 April 2009 (UTC)

Section added, and first row partially filled. Would others please fill in the blanks. Thanks. David Haslam 14:18, 16 August 2009 (UTC)

Is this page near completion yet?

The page now contains a mass of detailed information - there have been fewer edits of late - so is it near enough complete such that is now ready to be linked from the main page? David Haslam 14:42, 15 October 2009 (UTC)

As no-one has responded, I have now linked it from the main page. David Haslam 16:57, 18 October 2009 (UTC)

Module Management table needs updating to match FireBible 1.1

Brian recently announced FireBible 1.1, for which he stated:
"Added Book manager which allows you to install/uninstall books and set book/language fonts from within FireBible (this is the BD book installer)".

A consequence of this is that the Module Management table needs to be updated for the FB column. David Haslam 21:23, 19 October 2009 (UTC)

I have just made a start towards this. David Haslam 21:24, 19 October 2009 (UTC)

Brian did a lot more edits, though I am puzzled why FB<>BD for "User is warned if module already exists", as they both use the same JSword module manager. David Haslam 21:43, 24 October 2009 (UTC)

JSword, which is not a GUI, allows one to ask if a module already exists. It is up to the frontend to ask and do something with the answer. There should be no difference if FB uses BD's installer.--Dmsmith 23:27, 1 November 2009 (UTC)

Search features

Though the SWORD (and JSword) API has a very powerful search syntax, not all of the front-ends compared in the search table make the maximum use of the API search capabilities. This is why I just added two rows to that table, and edited the wording of the first sentence in the common features section. David Haslam 22:22, 24 October 2009 (UTC)

Aesthetics and software skins

I have just added a row for Skinnable to the last table. Has anyone begun to consider the aesthetic aspects of our various front-end applications? David Haslam 17:20, 26 October 2009 (UTC)

It's nice to see that in The Bible Tool the user can select from a choice of Themes. David Haslam 18:24, 26 October 2009 (UTC)

I'm apprehensive about this section. All of the front ends can take skins or themes according to the extent to which their platform permits these and to which they use native UI components. None of them have actual skinning facilities themselves. Most can change text & background colors, and a few can save preset text & background themes. I don't actually think this is something that anyone considers when choosing between pieces of software. --Osk 03:33, 27 October 2009 (UTC)

Fair comment. Let's leave it in to promote some creative thinking. David Haslam 09:29, 27 October 2009 (UTC)