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

Manfred Bergmann bergmannmd at web.de
Wed Jul 30 03:12:49 MST 2008


Am 30.07.2008 um 11:17 schrieb 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.

JavaScript, hmm...
I think we mean something different.
With 'word' I meant that the word itself should be the link.
I.e. in Gen 1:1: the whole term 'In the beginning' is tagged with  
lemma. So I want to be this whole term a link that doesn't look like a  
link and while moving the mouse over the link showing a tooltip.
This requires creating my own HTMLHREF filter subclass I guess. But no  
problem as long as I can do it.
Do I need to create a filter subclass for all raw types then?

> 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.

Yes, a small indication.




Manfred



>
>>
>> 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
>
>
> _______________________________________________
> 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




More information about the sword-devel mailing list