[jsword-devel] display methods

Wed, 17 Mar 2004 23:11:53 +0000

DM Smith wrote:

> My personal bias on web page development from XML source is that XSLT 
> should be used to do structural transformations, CSS should be used to 
> do styling and JavaScript should add bells and whistles, if desirable.

Agreed.

>> The requirements are, it must:
>> - work using XML input
>> - be easily understood for the developer (which fairly much means HTML)
>> - work over webstart
>> - be freely re-distributable
>> - allow some DHTML like flexibility
>
> So JEditorPane in JDK1.4 makes a fairly lousy HTML renderer. I've been 
> weighing up some alternatives.
>
> What JavaScript features would be desirable?

I would like to be able to have regions of the page hidden until the 
user takes some action. Generally speaking you just want to read, and 
strongs numbers/references/etc get in the way. It would be good to be 
able to hide them until needed.
I don't have a specific design in mind, but I have a hunch that this 
could be useful. I wrote a JavaDoc navigator that uses this principle: 
http://www.getahead.ltd.uk/doctree/

>> Some of those are tough requirements, but here's what I've come up with.
>>
>> JEditorPane in JDK1.4:
>>    does not do JavaScript or CSS level anything
>
> I have notice in JSword that when Strong's numbering is rendered the 
> words all run together because the space between words (In this case, 
> it would be between <A href="">word</A> tags) is missing. I have not 
> looked into where the hypertext is created yet.
>
> What are the other shortcomings (other than CSS or JavaScript)?

The lack of CSS is a biggy because it limits you to the available tags. 
I seem to remember giving up on tables that were anything other than 
very simple too. Div is obviously out.

>> JEditorPane in JDK1.5:
>>    big improvement - does CSS, but not JavaScript. Not released for 
>> another 6 months?
>
> And with the desire to support the Mac platform, it may be longer 
> before it is supported there.

Yes. I'd prefer not to wait that long for an opening release.

>> JRex (Embed Mozilla)
>>    very good html displayer, but probably very complex to get working 
>> and installed, especially over WebStart. JNI+webstart anyone? see 
>> http://jrex.mozdev.org/index.html
>
> JRex requires mozilla to be installed and the application embedding 
> JRex to know where that is. Also, I have had problems upgrading 
> mozilla from 1.3 to 1.4 or higher and was not successful until I 
> re-installed windows XP (for other reasons).

Separate install sounds like a hassle to me.

>> Jazilla (Mozilla re-write in Java)
>>    Interesting project, but one that seems more interested in XUL 
>> than the Java renderer, proceeding slowly. see 
>> http://jazilla.mcbridematt.sniperhq.net/
>
> The documentation of the supported capabilites is not promising. You 
> can see the supported set here:
> https://sourceforge.net/docman/display_doc.php?docid=21531&group_id=582

I'd given up on this one. They didn't seem to realise that the world 
doesn't need another browser, certainly not a Java/Swing one. The Java 
world however needs a HTML component.

>> JXWB (OSS Java Browser)
>>    Commercial software made free. Works well with Swing (includes 
>> customized implementations of javax.swing.text.Document and 
>> javax.swing.text.EditorKit) Things have moved on quite a bit 
>> recently. See http://sourceforge.net/projects/jxwb
>
> This looks like very early alpha code. The 0.1 release was the first 
> of this year.

Could be, but one man's alpha is another's JDK1.4 html component so I 
thought it was worth a further look. From talking to the lead developer 
I got the impression that the work was mostly in taking a commercial 
project and OSSing it, but I need to find out more.

>> SWT Browser Component
>>    Don't think we could easily embed an SWT component in swing (since 
>> SWT is heavyweight in AWT speak) and I don't particularly want to 
>> re-write the whole app in SWT.
>
> I think the other drawback in using SWT is that a lot fewer developers 
> are familiar with it and this would slow down collaborative development.
>
> Using SWT directly or indirectly will complicate the webstart jnlp 
> file as we willl need to have os specific jars (since swt is 
> heavyweight). Not that big a deal. For Unix users we would have to 
> choose for them whether they use SWT with a gtk, photon or motif 
> interface. This may give a conflicting look and feel with what a unix 
> user expects.
>
> Also it will add an additional 1Meg to the download. This is not that 
> much but it all adds up. Especially over dialup.

I don't have much to add to this. While SWT is interesting, I don't 
think is a very good idea for us with WebStart.

>> FOP -> PNG
>>    FOP is XSL:FO renderer (http://xml.apache.org/fop/index.html) that 
>> can create PDFs and various graphics files. Could give very slick 
>> output, but no DHTML, quite slow and FO is not easy to use. Probably 
>> not  one of the best ideas.
>
> I have used Tex to produce PDFs and it produces some very good looking 
> documents. However, I don't like PDF as the core solution, primarily 
> because they are hard for the end user to work with the docs as they 
> wish. If we were delivering licensed documents where cut and paste, 
> printing, drag and drop needed to be controlled, I can see how it 
> would make sense. I think it also makes sense as an alternate delivery 
> mechanism. That is as a "Save As..." target.

Yes, Save As PDF sounds like a good idea. I don't see why something like 
that couldn't be used in a fairly professional environment too.

>> Dynamic Swing GUI
>>    There are plenty of XML->Swing converters. JDK 1.4 even includes 
>> one. Maybe we could write a OSIS->SwingXML converter in XSL and then 
>> render OSIS text in swing components. Could be very fancy. XSL could 
>> be complex.
>
> This sounds cool. Do you know of a demo of this kind of conversion?

There is a poor example in the almanac:
    http://javaalmanac.com/egs/java.beans/ReadXml.html
The parent page may be more help:
    http://javaalmanac.com/egs/java.beans/pkg.html
And there was a "swing connection" article a while back:
    http://java.sun.com/products/jfc/tsc/articles/persistence4/index.html

> Just brainstorming: Have you given any thought about rendering 
> directly in the user's default browser?

That sounds like a good idea - I'd not thought of that at all. It would 
require a fair old change to the UI because the current model assumes 
that the app surrounds the view window, but it could be very simple to 
implement and things like print-preview come free.
Maybe it would be a good option just to get easy printing!

> I'm thinking it would be good to have a pluggable system, but I'm not 
> sure which of these to turn to first. I'm thinking (in order) JXWB, 
> Dynamic Swing GUI, SwingWT, JRex at the moment.

I'm now thinking:
- JXWB
- Dynamic Swing GUI
- Default Browser
- SwingWT

Joe.