[jsword-devel] HTML Browser for BibleDesktop

DM Smith dmsmith555 at yahoo.com
Thu Mar 13 12:39:21 MST 2008

Keith Watson wrote:
> Are all of the issues listed some where?
Hmm, *all* is a big task. So probably not. Joe and I have tried to be 
pro-active and list the issues that we find at www.crosswire.org/bugs under
Common for our common utilities
JSword for the Java implementation of the Sword Engine, which uses Common.
BibleDesktop for the GUI built on JSword and Common.

Probably some of the issues are mis-filed. Many are somewhat vague or 

For example we know that Java's browser is inadequate, so rather than 
enumerating all the problems with it, we just leave it as needing to be 

Please feel free to sign up and log all problems you find. I don't get 
mail when the issues are logged so also mention them here.

> I had previously looked at a few of the projects you listed and came away
> with the conclusion that the solution people take is to embed a real
> browser.  The other solutions I saw which people had built were all
> abandoned.
I found the same thing. My take was to wait for one to mature (they are 
getting close) and focus on other things. Namely missing functionality, 
badly broken features and things that are easy to do.

In my estimation, at this point the only major missing pieces of 
functionality are persistence and the ability to modify/create modules 
(which would give us personal commentary).

> The Java documents talk about creating your own renderer.  If there is a
> limited set of problems to address could that be a solution?
It is possible. I think there is an example of that in the incubator.

Some other possibilities is to convert the OSIS intermediate form to PDF 
and show that. Another was to use an XML viewer.

The problem with a custom renderer is that we would not be able to reuse 
the capability. For example, it would be cool to write a web service for 
JSword that would be accessible from any web enabled browser. We had a 
simple demo of it that hasn't worked for ages. So we took it down.

The other problem is given a good embeddable browser, it should only 
take a couple of hours to get it up and running. For me it would be hard 
to justify migrating all the logic that's in simple.xsl.

But, if you want to go down that path, I'd be willing to accept patches.

> Wile I discovered there is limited CSS support, the biggest problem I have
> found (with English text support) is whitespace issues.
Part of this problem is that we generate whitespace when we shouldn't. 
I've tried to minimize that.
Basically a rule that is nicely indented will produce whitespace between 
Also, sometimes, we should detect whether a blank line or space was 
produced before doing another. This sometimes crops up with titles.
I fix these as I find them or as they are reported.

>   A few of them are:
> default margins are way bigger than the norm;
I'm not sure what you mean by default margins or where you are seeing 
this problem. There is one problem in the displaying of notes that the % 
for the columns is not being honored.

>  comments in the XSL file get
> turned in to blank lines in the html file which are then rendered as a blank
> line.  Blank (empty) lines in html should never be rendered.
My guess is that this is an example of what I mentioned before.
If we have a rule like:
<xsl:template match="xxx">
     <!-- Set bold for the xxxx -->
     <xsl:value-of select="@xxxx"/>
This will result in something like:
Note: the spaces in the template before the first and last "thingy" are 
suppressed. the second line starts with 4 spaces. The problem is not the 
comment it is how the template is written.

When this is rendered, HTML will see this as <b> xxxx</b> (note the 
space before the xxxx.

However the following would probably produce the expected results.
<xsl:template match="xxx">
    <b><!-- Set bold for the xxxx --><xsl:value-of select="@xxxx"/></b>

I'll test it but I don't think that the browser is rendering blank lines 
as <br/>.

More information about the jsword-devel mailing list