[sword-devel] Sword enhancement proposal [was: HTML filter cross references link]

[Troy A. Griffitts]

>> What don't you like about how HTMLHREF display?  Is it the superscripted
>> 'x'?  Could we put it in a <span class="footnote_marker"> allowing you
>> to write a CSS rule to display or hide as you would like?
> 
> What I have in mind is that all additional information in the HTML is 
> hidden. It actually could be plain text then.
> Some information should be shown while moving the mouse over the words 
> in the HTML view or somewhere in another floating information window.
> That would mean making the word a link that has normal display 
> attributes. But the data of the link might be something individual.
> I don't kknow at the moment if this can be done by adding a marker and 
> using CSS. Actually I didn't thought about using CSS.

Have a look at SWORDWeb (click on any word in the text):

http://crosswire.org/study/passagestudy.jsp

This is done by hiding the looking information into 
getEntryAttributes().  If you change lookup.cpp back to WEBIF output, 
you can see how it is done.  It obviously doesn't have to operate with 
onclick, but could be on a hover over action.  I think most of the other 
frontends do the similar things while moving the mouse over words.

I think with footnotes though, it is a little different.  The user 
doesn't really know where a footnote is, so there should be some marker 
in the text which lets them know that further information is available 
here.  And obviously there should be a way to turn these things on and off.

Is this helpful, or have I not understood what you desire to do?

	-Troy.


PS.  You are very welcome to contribute to the engine code!  In fact, my 
hope is that most of the work currently done in the frontends, which 
isn't UI specific might merge and be added as a feature in the engine.



> 
> The thing is that I want to have the text display for text only (or 
> almost only) and other information is shown somewhere else. The text 
> display should be kept as simple as possible.
> 
> Maybe this can be achieved somehow by creating HTML filter subclasses. I 
> was also thinking about using the OSIS filters that Chrtis mentioned. 
> But parsing XML myself is actually something I don't want to do.
> 
> 
> 
> Regards,
> Manfred
> 
> 
>>
>>
>> Manfred Bergmann wrote:
>>> Am 29.07.2008 um 09:25 schrieb Chris Little:
>>>
>>>>
>>>> Manfred Bergmann wrote:
>>>>> Am 29.07.2008 um 09:10 schrieb Chris Little:
>>>>>
>>>>>> Greg Hellings wrote:
>>>>>>> On Tue, Jul 29, 2008 at 1:45 AM, Manfred Bergmann
>>>>>>> <bergmannmd at web.de <mailto:bergmannmd at web.de>> wrote:
>>>>>>>> Although I don't understand right now how the Sword module data is
>>>>>>>> stored,
>>>>>>>> my proposal here is that Sword should have a simple intermediate
>>>>>>>> XML format
>>>>>>>> that can be used by API users to have full access to the module
>>>>>>>> data.
>>>>>>>> Simple HTML/RTF can still be produced from this intermediate
>>>>>>>> format by
>>>>>>>> Sword. But HTML should not be used to give access to the module
>>>>>>>> data while
>>>>>>>> at the same time raw data access should not be used.
>>>>>>>> Having XSDs would make is easy for API-users to use XML->Object
>>>>>>>> binding (I
>>>>>>>> only know JAXB in Java but this might be available to most
>>>>>>>> languages as it
>>>>>>>> is used in protocols like SOAP).
>>>>>>>> Also XSLT stylesheets can be used to produce HTML or whatever
>>>>>>>> output.
>>>>>>>> Frontends could choose to use the HTML rendered output or choose
>>>>>>>> totally
>>>>>>>> different approaches by using the data of the intermediate XML.
>>>>>>>> Let me know what you think.
>>>>>>> It seems to me that this is one of the better ideas.  After all,  
>>>>>>> the
>>>>>>> library should supply display-agnostic data to the front end, which
>>>>>>> then renders it into a display format, rather than presenting it  
>>>>>>> with
>>>>>>> a list of a few preselected display formats which are supported at
>>>>>>> the
>>>>>>> engine level.
>>>>>> If you want OSIS, just ask the engine for OSIS. There's no  
>>>>>> requirement
>>>>>> that you tell the API to render text as HTML or RTF. You can just as
>>>>>> easily tell the API to render to OSIS, and it will happily perform  
>>>>>> (or
>>>>>> at least attempt) the conversion from GBF and ThML to OSIS. The
>>>>>> GBFOSIS
>>>>>> and ThMLOSIS filters might need a little more work, but they should
>>>>>> already work fairly well.
>>>>> So that means, basically, there is something like intermediate XML
>>>>> produced on the fly.
>>>> Not by default, but you can certainly ask the API for XML in a single
>>>> format.
>>>
>>> Do you know approximately how expensive it is to filter to OSIS  
>>> instead of HTML?
>>>
>>>
>>>
>>> Manfred
>>>
>>>
>>> _______________________________________________
>>> sword-devel mailing list: sword-devel at crosswire.org 
>>> <mailto:sword-devel at crosswire.org>
>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>
>>
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org 
>> <mailto:sword-devel at crosswire.org>
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page