Re: [sword-devel] Markup Options

[Greg Hellings]

On Wed, Dec 1, 2010 at 9:25 AM, Ben Morgan  wrote:
> Hi Greg,
> I agree the mechanism is simple enough; the ramifications are potentially
> not. Personally, I would mostly prefer that modules cannot provide their own
> stylesheets. On the web, every site has its own style; in print, each Bible
> has its own style. But when different Bibles are gathered together (say a
> print 4-version Bible) they all use the same formatting. Just so with our
> software - a consistent look throughout different Bibles is important, and
> having each module specifying what font it wants and size and colour has too
> much potential to lose consistency throughout the application.
> Your particular problem, Greg, where you wanted to duplicate the look and
> feel for modules as compared to existing systems, would be better
> addressed I feel by allowing the user to specify their own stylesheet,
> rather than per-module styling. This would still maintain a consistent look
> and feel across all modules.

User-specified stylesheets would not help me much at all.  Since each
module has its own look and feel that it needs to maintain.  Yes,
there is a certain uniformity to them, since they largely all come
through the same publisher, but there are differences - differences it
would be ridiculous to ask the user to try and specify out of the blue
(our target audience with these modules are people who are largely
without technology at all except for when they sit in front of the
Bible app we provide them with).  Instead, each module came with its
own layout and styling and should maintain it.

Your print analogy is perfect here, but I think you draw the backwards
conclusion from it.  Every print Bible has its own style, layout,
formatting, etc.  In the same way, every module should have its own
styling, layout and formatting.  When a publisher creates a 4-in-1 or
8-in-1 print, then they hold the prerogative to determine a basic
formatting for all of them.  Likewise, every SWORD module should have
its own styling unless the user is viewing it in parallel with other
modules.  By forcing the styling to be placed inline, you are
surrendering that ability.  Now, I just place my styling inline and it
gets foisted on the parallel display and individual displays alike.
It looks great in the individual display but messes up the parallel
display.  With external stylesheets you avoid that by simply opting to
exclude it from parallel displays and inserting it during solo
viewing.

> I'm all for giving the application and user more control; I'm just not
> convinced we should give module creators this level of control. I fear
> per-module stylesheets would be somewhat brittle, liable to be targeted at a
> particular frontend (which is what Jon was saying above), and likely to
> reduce the consistency in the interface. That said, I can see there could be
> a few cases where it might be necessary - say if a publisher insisted that
> their Bible look the way their print one does - but I would prefer
> consistency to each Bible looking like their print counterpart.

This is exactly the scenario I am in.  The publisher is insisting that
these modules look the same way in BibleTime and Xiphos as they do in
Logos.  So I force the style inline and take away control of the
display from both the application and user.  What I am offering is a
way to make my job easier (I only have to produce an external
stylesheet which can easily be adapted to an OSIS source later when
these modules go that direction) AND it returns control back to the
user and application by allowing them to opt-out of the stylesheet
when it is inappropriate - the same way web browsers opt out of screen
stylesheets when printing.

--Greg

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Bible/Commentary headings

[Greg Hellings]

That appears to have done it.  Thanks.

--Greg

On Wed, Dec 1, 2010 at 4:56 PM, Ben Morgan  wrote:
> Maybe swapping the order of chapter and verse around may help? The code I
> remember does some special handling of zeroes, but I can't check it at the
> moment.
> e.g.
>        vkey->Verse(0);
>        vkey->Chapter(0);
> to
>        vkey->Chapter(0);
>        vkey->Verse(0);
> God Bless,
> Ben
> ---
> Multitudes, multitudes,
>     in the valley of decision!
> For the day of the LORD is near
>     in the valley of decision.
>
> Giôên 3:14 (ESV)
>
>
>
> On Thu, Dec 2, 2010 at 9:48 AM, Greg Hellings 
> wrote:
>>
>> One of the commentaries I have has a book header (in this instance it
>> is for 1 Peter) which is held in the module in the key "1 Peter 0:0".
>> Behavior concerning that introduction varies with different
>> applications.
>>
>> 1) example/cmdline/lookup 'A Commentary on I Peter' '1 Peter 0:0'
>> This works perfectly.
>> 2) diatheke -b 'A Commentary on I Peter' -k 1pet.0.0
>> This autonormalizes to James 4:17 or something similar. 1pet.1.0
>> autonormalizes to James 5:22 or thereabouts.  Diatheke seems to lack a
>> call to AutoNormalize(0), so this behavior - while suboptimal IMHO -
>> is expected.  Perhaps one of the diatheke options disables
>> autonormalizing and turns on Headings, not sure.
>> 3) Bibletime, opening the module to 1 Peter 1:1
>> This displays the heading plus the contents of the verse 1:1, and
>> autoscrolls the display to where the 1:1 text begins.  This is
>> Bibletime's expected behavior and is good.
>> 4) Xiphos, opening the module to 1 Peter 1:1
>> This displays the text of 1 Peter 1:1 and is good.  I then right click
>> on the commentary panel and select Dispaly Book Heading.  This brings
>> up a blank panel.  The same with Display Chapter Heading.  I was
>> hashing this over on IRC before Karl had to leave and we were
>> comparing Bibletime and Xiphos' code.  The relevant portion of
>> Bibletime's code appears to be here:
>>
>> http://gitorious.org/bibletime/bibletime/blobs/master/src/backend/rendering/centrydisplay.cpp#line42.
>>  It doesn't seem terribly different from Xiphos' code which begins
>> around line 114 of src/main/sword.cc in terms of how it actually uses
>> the engine.
>>
>> Xiphos' code reads thus at that point:
>>
>>        VerseKey *vkey;
>>        SWMgr *mgr = backend->get_mgr();
>>
>>        backend->display_mod = mgr->Modules[mod_name];
>>        vkey = (VerseKey*)(SWKey*)(*backend->display_mod);
>>        vkey->Headings(1);
>>        vkey->AutoNormalize(0);
>>        vkey->Verse(0);
>>        vkey->Chapter(0);
>>        backend->display_mod->Display();
>>
>> which doesn't seem to work properly.  When I change that code to this
>>
>>       VerseKey *vkey;
>>        SWMgr *mgr = backend->get_mgr();
>>
>>        backend->display_mod = mgr->Modules[mod_name];
>>        vkey = (VerseKey*)(SWKey*)(*backend->display_mod);
>>        vkey->Headings(1);
>>        vkey->AutoNormalize(0);
>>        SWBuf ll = SWBuf(vkey->getOSISBookName());
>>        ll += " 0:0";
>>        vkey->setText(ll.c_str());
>>        backend->display_mod->Display();
>>
>> it behaves as expected.  I discovered this "workaround" when I was
>> working on mod2osis and just tried it on Xiphos on a whim.
>>
>> What might be going wrong here when Xiphos seems to be doing what I
>> would understand should display the heading?
>>
>> --Greg
>>
>> ___
>> sword-devel mailing list: sword-devel@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@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@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Bible/Commentary headings

[Ben Morgan]

Maybe swapping the order of chapter and verse around may help? The code I
remember does some special handling of zeroes, but I can't check it at the
moment.
e.g.
   vkey->Verse(0);
   vkey->Chapter(0);
to
   vkey->Chapter(0);
   vkey->Verse(0);

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)



On Thu, Dec 2, 2010 at 9:48 AM, Greg Hellings wrote:

> One of the commentaries I have has a book header (in this instance it
> is for 1 Peter) which is held in the module in the key "1 Peter 0:0".
> Behavior concerning that introduction varies with different
> applications.
>
> 1) example/cmdline/lookup 'A Commentary on I Peter' '1 Peter 0:0'
> This works perfectly.
> 2) diatheke -b 'A Commentary on I Peter' -k 1pet.0.0
> This autonormalizes to James 4:17 or something similar. 1pet.1.0
> autonormalizes to James 5:22 or thereabouts.  Diatheke seems to lack a
> call to AutoNormalize(0), so this behavior - while suboptimal IMHO -
> is expected.  Perhaps one of the diatheke options disables
> autonormalizing and turns on Headings, not sure.
> 3) Bibletime, opening the module to 1 Peter 1:1
> This displays the heading plus the contents of the verse 1:1, and
> autoscrolls the display to where the 1:1 text begins.  This is
> Bibletime's expected behavior and is good.
> 4) Xiphos, opening the module to 1 Peter 1:1
> This displays the text of 1 Peter 1:1 and is good.  I then right click
> on the commentary panel and select Dispaly Book Heading.  This brings
> up a blank panel.  The same with Display Chapter Heading.  I was
> hashing this over on IRC before Karl had to leave and we were
> comparing Bibletime and Xiphos' code.  The relevant portion of
> Bibletime's code appears to be here:
>
> http://gitorious.org/bibletime/bibletime/blobs/master/src/backend/rendering/centrydisplay.cpp#line42
> .
>  It doesn't seem terribly different from Xiphos' code which begins
> around line 114 of src/main/sword.cc in terms of how it actually uses
> the engine.
>
> Xiphos' code reads thus at that point:
>
>VerseKey *vkey;
>SWMgr *mgr = backend->get_mgr();
>
>backend->display_mod = mgr->Modules[mod_name];
>vkey = (VerseKey*)(SWKey*)(*backend->display_mod);
>vkey->Headings(1);
>vkey->AutoNormalize(0);
>vkey->Verse(0);
>vkey->Chapter(0);
>backend->display_mod->Display();
>
> which doesn't seem to work properly.  When I change that code to this
>
>   VerseKey *vkey;
>SWMgr *mgr = backend->get_mgr();
>
>backend->display_mod = mgr->Modules[mod_name];
>vkey = (VerseKey*)(SWKey*)(*backend->display_mod);
>vkey->Headings(1);
>vkey->AutoNormalize(0);
>SWBuf ll = SWBuf(vkey->getOSISBookName());
>ll += " 0:0";
>vkey->setText(ll.c_str());
>backend->display_mod->Display();
>
> it behaves as expected.  I discovered this "workaround" when I was
> working on mod2osis and just tried it on Xiphos on a whim.
>
> What might be going wrong here when Xiphos seems to be doing what I
> would understand should display the heading?
>
> --Greg
>
> ___
> sword-devel mailing list: sword-devel@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@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

[sword-devel] Bible/Commentary headings

[Greg Hellings]

One of the commentaries I have has a book header (in this instance it
is for 1 Peter) which is held in the module in the key "1 Peter 0:0".
Behavior concerning that introduction varies with different
applications.

1) example/cmdline/lookup 'A Commentary on I Peter' '1 Peter 0:0'
This works perfectly.
2) diatheke -b 'A Commentary on I Peter' -k 1pet.0.0
This autonormalizes to James 4:17 or something similar. 1pet.1.0
autonormalizes to James 5:22 or thereabouts.  Diatheke seems to lack a
call to AutoNormalize(0), so this behavior - while suboptimal IMHO -
is expected.  Perhaps one of the diatheke options disables
autonormalizing and turns on Headings, not sure.
3) Bibletime, opening the module to 1 Peter 1:1
This displays the heading plus the contents of the verse 1:1, and
autoscrolls the display to where the 1:1 text begins.  This is
Bibletime's expected behavior and is good.
4) Xiphos, opening the module to 1 Peter 1:1
This displays the text of 1 Peter 1:1 and is good.  I then right click
on the commentary panel and select Dispaly Book Heading.  This brings
up a blank panel.  The same with Display Chapter Heading.  I was
hashing this over on IRC before Karl had to leave and we were
comparing Bibletime and Xiphos' code.  The relevant portion of
Bibletime's code appears to be here:
http://gitorious.org/bibletime/bibletime/blobs/master/src/backend/rendering/centrydisplay.cpp#line42.
 It doesn't seem terribly different from Xiphos' code which begins
around line 114 of src/main/sword.cc in terms of how it actually uses
the engine.

Xiphos' code reads thus at that point:

VerseKey *vkey;
SWMgr *mgr = backend->get_mgr();

backend->display_mod = mgr->Modules[mod_name];
vkey = (VerseKey*)(SWKey*)(*backend->display_mod);
vkey->Headings(1);
vkey->AutoNormalize(0);
vkey->Verse(0);
vkey->Chapter(0);
backend->display_mod->Display();

which doesn't seem to work properly.  When I change that code to this

   VerseKey *vkey;
SWMgr *mgr = backend->get_mgr();

backend->display_mod = mgr->Modules[mod_name];
vkey = (VerseKey*)(SWKey*)(*backend->display_mod);
vkey->Headings(1);
vkey->AutoNormalize(0);
SWBuf ll = SWBuf(vkey->getOSISBookName());
ll += " 0:0";
vkey->setText(ll.c_str());
backend->display_mod->Display();

it behaves as expected.  I discovered this "workaround" when I was
working on mod2osis and just tried it on Xiphos on a whim.

What might be going wrong here when Xiphos seems to be doing what I
would understand should display the heading?

--Greg

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] cipherraw

[Greg Hellings]

I believe he had to switch to using mod2zmod.

Some time ago when I was working with ciphered modules, I had to
switch to mod2zmod, as I never could get raw modules to encrypt.  That
might be a bug with cipherraw, it might be a bug with the engine, or
it might be design.  Not sure.

--Greg

On Wed, Dec 1, 2010 at 1:24 PM, DM Smith  wrote:
> Was it a bug or a usage problem. If it is a bug, I'll submit a bug report in
> Jira for it.
>
> On 12/01/2010 01:38 PM, Greg Hellings wrote:
>>
>> This is not true.  He was answered on IRC.
>>
>> On Wed, Dec 1, 2010 at 12:34 PM, David Haslam
>>  wrote:
>>>
>>> No-one has answered Peter yet.  O Come all ye experts!
>>>
>>> David
>>> --
>>> View this message in context:
>>> http://sword-dev.350566.n4.nabble.com/cipherraw-tp3045962p3067825.html
>>> Sent from the SWORD Dev mailing list archive at Nabble.com.
>>>
>>> ___
>>> sword-devel mailing list: sword-devel@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@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@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@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] cipherraw

[DM Smith]

Was it a bug or a usage problem. If it is a bug, I'll submit a bug 
report in Jira for it.


On 12/01/2010 01:38 PM, Greg Hellings wrote:

This is not true.  He was answered on IRC.

On Wed, Dec 1, 2010 at 12:34 PM, David Haslam  wrote:

No-one has answered Peter yet.  O Come all ye experts!

David
--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/cipherraw-tp3045962p3067825.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
sword-devel mailing list: sword-devel@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@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@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] cipherraw

[Greg Hellings]

This is not true.  He was answered on IRC.

On Wed, Dec 1, 2010 at 12:34 PM, David Haslam  wrote:
>
> No-one has answered Peter yet.  O Come all ye experts!
>
> David
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/cipherraw-tp3045962p3067825.html
> Sent from the SWORD Dev mailing list archive at Nabble.com.
>
> ___
> sword-devel mailing list: sword-devel@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@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] cipherraw

[David Haslam]

No-one has answered Peter yet.  O Come all ye experts!

David
-- 
View this message in context: 
http://sword-dev.350566.n4.nabble.com/cipherraw-tp3045962p3067825.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] XSLT vs. C++

[DM Smith]

Not so much regarding Troy's comment about Plato's Form. Rather about 
the model that JSword uses. It is meant for illumination.


JSword converts ThML, GBF, PlainText and OSIS on a verse by verse basis 
into well-defined fragments of XML. These fragments use the tags of 
OSIS, but might not produce a valid fragment. For ease of explanation, 
we say that it is converted into OSIS. If for some reason a verse in 
ThML or OSIS is not well-formed, it is hacked by successively stripping 
out xml parts until it parses or until only the text remains. This hack 
is rather unfortunate and should be removed or improved. E.g. notes and 
xrefs should never be inlined as plain text if they are marked up properly.


Though it can, JSword does not use XSLT on a verse by verse basis to 
render a verse. Rather it gathers all the verses as XML fragments into 
an XML document. Typically this is a chapter of verses, but it might 
also be the set of verses returned from a search result, specified by 
the user, or given as a cross-reference. JSword will also collect verses 
from several modules into the document for parallel display.


It is this document that is rendered. How this document is rendered is 
up to the application. It could use SAX. It could walk the DOM. But 
Bible Desktop uses XSLT and many other JSword front-ends do so as well. 
In answer to an earlier question, the XSLT is read once and reused for 
all rendering of modules. It is way to expensive to do this frequently. 
Once per run or only when the underlying file changes is sufficient.


An aspect that JSword dictates on a processor of the document. All 
rendering/filtering happens within it. The BD style sheet is 
parametrized for each render option. Using these it shows/hides notes, 
xrefs, strongs, and morph; does verse per line; changes in the 
representation of the verse number; and so forth.


There are several values in rendering a chapter as a whole. There are 
many constructs that can include more than one verse. One can start a 
tag in the middle of one verse and close it in another. If one only 
rendered verse-by-verse the start and end might not be matched up 
correctly. For example, SWORD's osishtmlhref filter has a quote stack 
and a highlight stack. If a quote starts in one verse and ends in 
another, the stack is reset going from one verse to another. So the 
quote marks might not match up. (Note: osis2mod is aware of this 
shortcoming and adjusts for it. However, if the module maker uses 
imp2mod or vpl2mod it can happen). For the  tag when an opening tag 
is found, it is pushed on a stack (allowing for nesting). When an end 
tag is found, the stack is consulted to see what it was the start tag 
was. If it were bold then it closes bold, otherwise it closes italics. 
However, if the stack is empty, it closes italics.


This spanning problem affects JSword's rendering of a collection of 
arbitrary verses. A tag can be open in one verse, but because the verse 
is not show in context, it is never closed.


There is also an advantage of using XSLT over SAX, it is not limited to 
a single pass of the document. For example, this is used in Bible 
Desktop to show margin notes.


Regarding TEI, JSword pretends it is OSIS. This is not a far stretch 
since OSIS was influenced by TEI. The XSLT has a few entries to be able 
to display key elements. Since TEI is rather open, and in flux, not all 
of what we will use will be found in it. I haven't looked at it but 
Chris has a TEI schema he uses for validation. That could be used to 
improve the XSLT or for TEI modules to have their own XSLT.


Regarding ThML, JSword would do well to not convert it to OSIS but have 
XSLT for it as well.


Regarding the speed of XSLT vs SAX vs SWORDs renderers. Except for 
handhelds (pda, phone, ...) it is a moot point. I figure that 5-6 years 
is the maximum useful lifespan of a computer. The processing power of a 
computer in these years, even a netbook, is sufficient to run XSLT fast 
enough over a chapter's worth of verses to satisfy end users. I have an 
old 486, Windows 98 laptop with limited memory that runs it acceptably. 
Even my OLPC (one laptop per child) is fast enough.


Beyond JSword and how it could be used in SWORD with out much change to 
the current library:
I'm not sure, but I think any SWORD front-end can try out XSLT if they 
like on OSIS documents using the osisosis.cpp filter. The filter does 
not attempt to do too much except reconstruct verses. It might need to 
be modified to output milestoned verse markers instead of the begin/end 
tags it does now. Using begin/end tags makes the assumption that a verse 
is a well-formed fragment. Just use it to "render" a chapter and then 
pass that chapter to xslt.


I'm hearing that lots of people won't seriously look at XSLT. It has a 
steep but short learning curve. Kind of like Perl. There are two basic 
programming models using XSLT: one that understands the containment 
model of the schema. The other handl

Re: [sword-devel] XSLT vs. C++

[Peter von Kaehne]

> So, if one were to write a new OSIS filter from scratch,   > I'd like to know 
> what has to be done to meet/match SWORD's ideal chair.

I think the single most relevant requirement is easy expandability.

I am looking - totally different example - at usfm2osis.pl and about 180 or so 
lines are now mine. But I would not have been able to do anything with it in 
its old form. Since Chris rewrote it, commented it extensively and made it 
alotgether a logical affair it is so easy to add whenever I find a USFM tag 
unsupported/poorly supported to just ad a line or ten.

If the filtyers were ever at that place - I would be delighted.
-- 
GRATIS! Movie-FLAT mit über 300 Videos. 
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] XSLT vs. C++

[Ben Morgan]

Hi Greg,

On Thu, Dec 2, 2010 at 2:19 AM, Greg Hellings wrote:

> On Wed, Dec 1, 2010 at 8:13 AM, Jonathan Morgan 
> wrote:
> > Speaking as a BPBible developer, I would tend to prefer C++ filters to
> > XSLT.  Here are some reasons why:
> > 1. It works now (well, OK, it doesn't always work as well as one might
> like,
> > but it does work).
>
> It works for our historical collection of modules, but the current
> implementations of some of the filters are rigid and very difficult to
> update or modify.  But yes, it more or less works now.
>
I agree it can be very fiddly and fragile - that's mostly the filters like
the headings filters which are run before render; the OSISHtmlHref filters
are simple enough to work with. Extending it in python once it is set up is
very easy as well (basically defining a start_ and end_ handler -
for our handling of poetic lines, for example, see
http://code.google.com/p/bpbible/source/browse/branches/webconnect/backend/osisparser.py#475
)


> > 2. It is (fairly) readily able to be customised by application developers
> > using the magic of inheritance.  BPBible at least takes advantage of
> this,
> > and 0.4.7 contained about 800 lines of Python in our filter code.  For
> 0.5
> > the OSIS filter has doubled in size.  By contrast, if we were to maintain
> an
> > app-specific XSLT file, we would probably need to duplicate the whole
> file
> > and then make changes to it, and any changes made to the base XSLT file
> > would have to be manually merged in.  Bye-bye to the idea of having only
> one
> > lot of library source to maintain.
>
> XSLT is easily extensible.  SAX is easily extensible.
>
Basically what is used already is a SAX-like model, just implemented by
Sword. Customizability is just the same as you describe.

I do not believe XSLT is a good option; for a start, it requires (AFAIK)
valid XML fragments, which we do not have within a verse in much of existing
content (or even at all necessarily). JSword I believe has fallbacks to
extract the text if not valid xml, but I would far prefer not to use such
hacks; SWORD can handle this quite well (as probably SAX could if
non-validating). Also, due to the structure of OSIS with multiple
hierarchies, however you process it it will be complicated and this loses
much of the benefits of XSLT. (Disclaimer - never used XSLT)

Also, on a personal level, due to having never used XSLT, I feel comfortable
using Python/C++ whereas XSLT is scary.

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Markup Options

[Ben Morgan]

Hi Greg,

On Thu, Dec 2, 2010 at 1:51 AM, Greg Hellings wrote:
>
> I believe the phrase would mean the SWORD library would produce a well
> defined set of HTML elements with classes attached to help preserve
> the semantic meaning.  It would then be up to the consumer of that
> HTML - the application - to provide its own CSS.  Adding extra CSS
> classes as per an application's specific desires ought to be as easy
> as extending the filter and just adding a few extra lines of code for
> each particular case.  Extraneous CSS classes can readily be ignored
> simply by not having a corresponding definition in the app's CSS.
>
That's well and good, and would cover a good chunk of customizability needs
- but it only works up to the limit of CSS.


> BPBible does lots of customization, BibleTime does as well, and
> certainly other apps do customize to some extent.  If the filters were
> good and easily extensible (and any of the XML processing technologies
> would work in that regard), BPBible's customizations could either be
> readily incorporated to the engine to benefit others who desire them
> or maintained in BPBible directly without having to throw out the base
> filters.  And, of course, BPBible would continue to maintain its own
> stylesheets.
>
BPBible's customizations are somewhat complicated and rely heavily on other
parts of the SWORD API or other data (e.g. showing two xrefs in an xref
block and putting the rest in a separate link, producing user friendly xref
text, colorcoding quotes in the ESV by speaker (experimental in 0.5),
replacing strongs numbers with greek lemma/transliterated). This is best
suited to the current way things work I feel. BPBible's filters inherit from
SWORD's ones, so the base filters are not thrown out as such.


> > 2. Some of the application specific styles and user choices may conflict
> > with the module styles.  For example, I know Bibletime has themes, which
> can
> > change colour of foreground text, background, ...  I have thought about
> > doing a similar thing for BPBible.  However, this isn't going to work in
> > cases like: our poor user has a dark background, and the module developer
> > has decided to mark a particular text feature in a dark purple which is
> > nearly illegible.
> ...
> That way the application provides the default appearances, the module
> can provide overrides to the default if it desires, and the user can
> provide overrides which take the highest priority.  Yes, if a module
> specifies Black background and the user has said they want all text to
> be in dark grey, that would be difficult to read.  But this can happen
> easily on the web already and somehow we are all able to manage.
> Since we are using identical technology, why can't we use its full
> power?
>
I agree the mechanism is simple enough; the ramifications are potentially
not. Personally, I would mostly prefer that modules cannot provide their own
stylesheets. On the web, every site has its own style; in print, each Bible
has its own style. But when different Bibles are gathered together (say a
print 4-version Bible) they all use the same formatting. Just so with our
software - a consistent look throughout different Bibles is important, and
having each module specifying what font it wants and size and colour has too
much potential to lose consistency throughout the application.

Your particular problem, Greg, where you wanted to duplicate the look and
feel for modules as compared to existing systems, would be better
addressed I feel by allowing the user to specify their own stylesheet,
rather than per-module styling. This would still maintain a consistent look
and feel across all modules.


> > 3. As well as the single verse search results Karl mentions, the parallel
> > case comes to mind.  If I have multiple books using different style
> sheets,
> > how do I manage that?  Do the parallel Bibles end up in different and
> > clashing styles?  In BPBible I think we even generate different HTML for
> > these different places, so there's not even a guarantee that these styles
> > will apply cleanly and work.  However, if any modules are created that
> rely
> > on these custom styles to look OK, then we will need to have some way of
> > making them work in all these different contexts.
>
Adding support for external stylesheets actually gives the application
> and user MORE control, not less, and still allows the module creator a
> sane way of specifying styles without having to resort to inserting
> their styles as style attributes on every single ThML element they
> want stylized (and would also allow the creation of OSIS modules where
> the style is influenced by the module creator instead of only by the
> engine and user agent, provided the applications can agree on
> well-defined mapping between OSIS and HTML).

I'm all for giving the application and user more control; I'm just not
convinced we should give module creators this level of control. I fear
per-module stylesheets would

Re: [sword-devel] XSLT vs. C++

[Greg Hellings]

On Wed, Dec 1, 2010 at 8:13 AM, Jonathan Morgan  wrote:
> Speaking as a BPBible developer, I would tend to prefer C++ filters to
> XSLT.  Here are some reasons why:
> 1. It works now (well, OK, it doesn't always work as well as one might like,
> but it does work).

It works for our historical collection of modules, but the current
implementations of some of the filters are rigid and very difficult to
update or modify.  But yes, it more or less works now.

>
> 2. It is (fairly) readily able to be customised by application developers
> using the magic of inheritance.  BPBible at least takes advantage of this,
> and 0.4.7 contained about 800 lines of Python in our filter code.  For 0.5
> the OSIS filter has doubled in size.  By contrast, if we were to maintain an
> app-specific XSLT file, we would probably need to duplicate the whole file
> and then make changes to it, and any changes made to the base XSLT file
> would have to be manually merged in.  Bye-bye to the idea of having only one
> lot of library source to maintain.

XSLT is easily extensible.  SAX is easily extensible.

In XSLT I can import another XSL file and provide overrides - no need
to merge in changes from someone else and maintain identical copies,
etc.  When I'm creating my current set of modules I have 2 XSL files
that go from the proprietary SGML to HTML and ThML.  Obviously there
is a lot of overlap between those two.  The ThML stylesheet simply
imports the HTML stylesheet and overrides a few of the templates to
produce  and other ThML-specific elements.  That way, if
there is a bug in how I translate a table display, for instance, I can
change it in the HTML stylesheet and I get the fix for free in my ThML
without touching anything.

SAX is simply an API in any desired language.  If I want to override
the behavior of a single element, I just override the processing
method and check something like
if(is element to override)
doOverride();
else
callSuperclassMethod();
All the discussion for XSL above applies to SAX processing as well.

>
> 3. It allows developers to use sources that are outside the document being
> transformed.  This has had some issues for us (from memory, the filter code
> isn't re-entrant), but we use this functionality to do things like expanding
> a list of cross-references in the user's locale, looking up the headwords
> for Strong's Numbers, and looking up the text in the current version for a
> passage in a harmony.  By contrast, unless we have some good way to call
> into C++/Python from XSLT we will not be able to use sources outside the
> current document unless we do some complex post-processing.  If we do have
> such a way it could just increase complexity.

A SAX model, of course, is able to handle the full range of what your
programming language of choice has, so you're all set there.

XSL has many ways of bringing in data from the outside.  Arguements
and variables can be passed in by the caller (man xsltproc and you'll
see the argument --param PARAMNAME PARAMVALUE. Programmatic invocation
of XSL can use the same parameter mechanism), values can be pulled out
of static XML files which the XSL can include, and there is a rather
straightforward way of creating custom functions in your invoking
language.  When I am using XSL to parse my SGML files, I have a number
of custom functions written in Python which I invoke from XSL to do
any type of processing raw XSL can't handle (example: transforming
inline RTF styles into inline CSS styles).

Increasing complexity? That really depends on the methods used and
whether they are appropriate.

>
> 4. It allows us to share common functionality between the ThML filters and
> the OSIS filters (which we do).  I think this proposal would have us still
> using C++ ThML filters while moving the OSIS filters to XSLT, which would
> make the results further apart.

The same can be done with XSL simply be factoring the shared
functionality into a single stylesheet which the ThML and
OSIS-specific stylesheets include.

SAX... well, I think you get the idea there.

>
> 5. I would be concerned if performance dropped at all, as I suspect it would
> (especially if calls into C++ were involved as well).

Calls into the parent language don't really slow down XSL unless they
invoke a method which is excruciatingly slow.  Of course, no one
really has implementations of both technologies currently in place for
us to compare SWORD's performance at present.  apt-cache showpkg
libxml2 shows me around 1000 libraries and applications in Ubuntu
which currently depend directly on libxml2 including things as diverse
as Pidgin, PHP, Postgres, VMWare, rpm2html, strigi, nautilus, Gnome,
gstreamer, abiword, xscreensaver and so on.  Performance of that
library is apparently good enough for some people.  There are even two
sets of bindings in Python (python-libxml2 and python-lxml) both of
which I have used with great success.

To give an idea of how quickly it processes, I am able to load, par

Re: [sword-devel] Markup Options

[Greg Hellings]

On Wed, Dec 1, 2010 at 7:40 AM, Jonathan Morgan  wrote:
> From an application developer's point of view, I'm not convinced that per
> module CSS is a good idea.  Here are some reasons:
> 1. I'm not convinced of "well-defined use of HTML+CSS classes".  Some things
> may be well-defined, but I know BPBible does a lot of customisation of the
> SWORD generated HTML and uses a lot of custom CSS, and some or all of these
> things might break CSS designed for other apps (and vice versa).  I also do
> not like the idea that my changes to either the HTML generated or the CSS
> breaks the display of a module I have never seen.

I believe the phrase would mean the SWORD library would produce a well
defined set of HTML elements with classes attached to help preserve
the semantic meaning.  It would then be up to the consumer of that
HTML - the application - to provide its own CSS.  Adding extra CSS
classes as per an application's specific desires ought to be as easy
as extending the filter and just adding a few extra lines of code for
each particular case.  Extraneous CSS classes can readily be ignored
simply by not having a corresponding definition in the app's CSS.

BPBible does lots of customization, BibleTime does as well, and
certainly other apps do customize to some extent.  If the filters were
good and easily extensible (and any of the XML processing technologies
would work in that regard), BPBible's customizations could either be
readily incorporated to the engine to benefit others who desire them
or maintained in BPBible directly without having to throw out the base
filters.  And, of course, BPBible would continue to maintain its own
stylesheets.

>
> 2. Some of the application specific styles and user choices may conflict
> with the module styles.  For example, I know Bibletime has themes, which can
> change colour of foreground text, background, ...  I have thought about
> doing a similar thing for BPBible.  However, this isn't going to work in
> cases like: our poor user has a dark background, and the module developer
> has decided to mark a particular text feature in a dark purple which is
> nearly illegible.

I remember Jaak voicing this complaint when I brought up CSS
stylesheets in BibleTime.  This is actually an argument FOR having
external stylesheets.  I don't see why either of you would think our
case is any different from a web browser in this regard.  CSS was
designed specifically to handle exactly the situation you bring up.
In web browsers styles will cascade downwards with earlier styles
overwriting later ones in the following order:

1) User-Agent stylesheet
2) External stylesheets
3) Internal stylesheets
4) Inline styles

Often times a user can insert their own styles for accessibility
reasons and I believe those are usually placed at priority 3.5 in that
list.  Currently SWORD applications only support (1) and (4).
BibleTime's offer of themes simply changes the values of the
User-Agent stylesheet.  My first attempt at creating SWORD modules way
back when I thought that (2) and (3) would be supported since the
library documentation claimed to support ThML, but it ends up the
entire header of the document gets thrown away during import but
inline styles remain intact.  As a result, (3) would be difficult to
handle in SWORD without major changes to the entire library and import
system but (2) would be very easy to add simply by honoring a config
option.

Since the stylesheets within each level cascade with later ones
overriding earlier ones, in order to maintain the specified order, the
following in the HTML header would be all that is required:





That way the application provides the default appearances, the module
can provide overrides to the default if it desires, and the user can
provide overrides which take the highest priority.  Yes, if a module
specifies Black background and the user has said they want all text to
be in dark grey, that would be difficult to read.  But this can happen
easily on the web already and somehow we are all able to manage.
Since we are using identical technology, why can't we use its full
power?

Currently the only way to get styles through to the display layer are
through number 4 - inline styles.  As it is, I can already mess with
every one of those settings you're worried about me messing up and the
user can do nothing about it (unless, of course, BPBible strips the
style attribute from ThML sources).  So by providing me the ability to
set an external stylesheet, you would actually be fixing what is
currently a usability bug in apps.  Thus both you and Jaak are correct
to worry about this issue, but the result of your worrying should be
to enable external styles not disable them.

>
> 3. As well as the single verse search results Karl mentions, the parallel
> case comes to mind.  If I have multiple books using different style sheets,
> how do I manage that?  Do the parallel Bibles end up in different and
> clashing styles?  In BPBible I think we even genera

Re: [sword-devel] XSLT vs. C++

[DM Smith]

I like Plato's Chair analogy. But not the conclusions drawn from it.

I think we all agree that some level of structural markup is necessary to 
identify: books, chapters, verses, titles, intros, words of Christ, footnotes, 
cross-references, and anything else we might want to treat specially beyond 
just presentation.

I like deep structural markup that goes beyond what we currently use, e.g. 
markup of names and place names, so that we are not limited by what we have 
done, but what we can envision later.

Some structural markup, such as poetry markup, today is used as merely 
presentational. As a result, it often is not structurally meaningful. This is a 
problem of the module maker creating something that looks nice but of which 
there is no value to software processing (e.g. getNextPoetryBlock() just won't 
get the desired results.

The problem with the Plato's Chair analogy is that SWORD is not merely an idea, 
but *an* implementation of that chair. I'd say it looks rather like a 1980's 
dinette chair constructed of steel tubing and vinyl cushions.

The biggest problem I see with the modules and the filters is that they are 
lossy and/or incomplete. I'll keep my remarks to the OSIS process as that is 
what I am most familiar, and since it is *a* chair, it is not too far removed 
from ThML's chair.

Regarding the modules, of necessity, we transform BSP OSIS (aka Book, Section, 
Paragraph with verse markers) into BCV (Book, Chapter, Verse) without verse 
markers. (ThML, GBF, PlainText readily lend themselves to BCV directly. I'm 
going to guess that is *a* major motivation for ThML.)

The purpose of osis2mod is to transform the publishers' chairs into SWORD's 
chairs. The shortcoming of using IMP or VPL to import OSIS (or any other module 
type) is that it bypasses such a transformation and puts the burden on the 
module maker to construct SWORD's chair directly.

Regarding the filters, there is an agreement that they need help. The problem 
with the OSIS to HTML filters is that they are not written to display what is 
defined by the OSIS spec, but only what the filter author thought was 
important. Some examples: OSIS allows for a title to be within a title, that 
is, to have sub-titles. OSIS allows rich markup within titles, such as 
footnotes, cross-references, divine name, etc. OSIS allows for significant 
content between verses. Words of Christ in verses can be punctuated by other 
words. These were or are problematic to these filters.

The second problem with these filters is that they are lossy. The filters only 
look for a subset of the OSIS tags and attributes. Examples: the "n" attribute 
on footnotes. Of the various types of  bold is handled well, but everything 
else gets italic (line-through, acrostic, illuminated, small-caps, sub, super). 
Table, row and cell are ignored (these could easily be in genbooks). And lots 
more

This is a community effort and we all have different skill sets. I'm 
particularly weak in doing C++ coding as I have been away from it for too long 
(I started with C++ 1.0 and moved to something else just before 3.0 was 
released). Otherwise, I'd have tackled the lossy-ness of the filters.

As I look at the code, the essential part of the SWORD chair seems to be how it 
pulls out of line various components into easily addressed structures: titles, 
footnotes, . I've tried but I don't understand this at all.

Within the osishtmlhref filter there are various notions that are necessary to 
understand but are entirely baffling to me: suspendTextPassThru, suspendLevel, 
lastSuspendSegment, supressAdjacentWhitespace, , .

So, if one were to write a new OSIS filter from scratch, I'd like to know what 
has to be done to meet/match SWORD's ideal chair.

In Him,
DM




On Dec 1, 2010, at 7:20 AM, Troy A. Griffitts wrote:

> The logic to get from any Publisher Source Document to rendered HTML is
> a very complex task to solve.
> 
> We conceptually create Plato's Form of, say, a Bible, and try to fit
> imperfect Publisher markup into this concept.  A Bible has verses,
> headings between verses, chapter intros, footnotes, crossrefs, lemma
> information, etc.
> 
> If we do not do this, then we become a PDF reader-- there are already
> PDF readers and we lose the ability to do Bible specific things with our
> software.  For example, if we didn't normalize the concept of crossref
> across all Books, then we couldn't turn them on and off; we couldn't
> provide a crossref panel in the reader which fills according to which
> crossref is hovered over, etc.  Same with notes, strongs, headings, etc.
> 
> This causes us to impose our Form onto a publisher's text.  I understand
> why some people may not like this, but it is very much to our end users'
> benefit that we do this.  Without this, we become a web-browser or a PDF
> reader.  Which are fine for their purpose, but we intend to provide
> common, familiar, and sometimes novel Bible study aides to our reader.
> 
> The c

[sword-devel] Why You Should Love SWORD 101 - Text Processing Flow

[Troy A. Griffitts]

EXAMPLE TEXT PROCESSING FLOW



*Publisher's Document*
/ Chaos and Unrest /


|
osis2mod
v


*SWORD Storage*
/ Unrest /
Markup normalized
Document partitioned into user-referencable, tasty bite-sized chunks


|
option filters
v


*Stage 1 Processed*
/ Some Rest /
Entity focused classes each have processed their 'concept': notes,
lemma, crossref, etc.
Interesting attributes registered to EntryAttributes map
Some editorial decisions made, like removing inlining of notes,
pre-verse headers
Features turned on or off based on user preference


|
render filters
V


*HTML output*
/ Peace and Tranquility /
Markup converted to HTML
Where inlining was removed, the residual marker tags now have direct
pointers back to their EntryAttributes section enabling the frontend to
do what they'd like on events like hover-over




*NB: There are additional stages of processing: encoding stage, decipher
stage, strip/normalize for search stage, etc., but this is a 100 level
course.

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] XSLT vs. C++

[Jonathan Morgan]

Speaking as a BPBible developer, I would tend to prefer C++ filters to
XSLT.  Here are some reasons why:
1. It works now (well, OK, it doesn't always work as well as one might like,
but it does work).

2. It is (fairly) readily able to be customised by application developers
using the magic of inheritance.  BPBible at least takes advantage of this,
and 0.4.7 contained about 800 lines of Python in our filter code.  For 0.5
the OSIS filter has doubled in size.  By contrast, if we were to maintain an
app-specific XSLT file, we would probably need to duplicate the whole file
and then make changes to it, and any changes made to the base XSLT file
would have to be manually merged in.  Bye-bye to the idea of having only one
lot of library source to maintain.

3. It allows developers to use sources that are outside the document being
transformed.  This has had some issues for us (from memory, the filter code
isn't re-entrant), but we use this functionality to do things like expanding
a list of cross-references in the user's locale, looking up the headwords
for Strong's Numbers, and looking up the text in the current version for a
passage in a harmony.  By contrast, unless we have some good way to call
into C++/Python from XSLT we will not be able to use sources outside the
current document unless we do some complex post-processing.  If we do have
such a way it could just increase complexity.

4. It allows us to share common functionality between the ThML filters and
the OSIS filters (which we do).  I think this proposal would have us still
using C++ ThML filters while moving the OSIS filters to XSLT, which would
make the results further apart.

5. I would be concerned if performance dropped at all, as I suspect it would
(especially if calls into C++ were involved as well).

6. Currently our rendering works on a verse-by-verse basis.  I'm not sure
what it would look like if we were trying to do something like a chapter at
once.  Do we run through the chapter in one go?  What kind of well formed
OSIS document can we get from a single verse or collection of verses to pass
into an XSLT?  Is there much cost to fire up an XSLT engine just for the one
verse we have in our search preview?  What would you do if you wanted to
have a discontinuous range of verses or to show versions in parallel
verse-by-verse?  We also surround each verse and a rendered section with
other extra stuff which varies depending on the context.  I'm not sure where
this would fit in the XSLT (if at all).

In short, as a BPBible developer I much prefer implementation in C++ because
it allows us to do things we want to do much more easily than with XSLT
(though if Troy or anyone else wants to improve the present implementation
they are welcome to).  I cannot speak for the pros and cons from a module
creator point of view.

Jon

On Wed, Dec 1, 2010 at 6:08 AM, Troy A. Griffitts wrote:

> Having finally returned from a hectic 2 weeks of conferences, and lots
> to do before leaving for Christmas, I'm not sure I'm up for a heated,
> passionate debate about technologies right now, but by all means, please
> commence the public discussion.
>
> Let me start by saying that everyone (I believe) agrees that we would
> like to have an HTML output from the engine which is more generic and
> would allow CSS to be applied if a frontend would like to do this.
> Currently HTMLHREF output from the engine is used by the widest number
> of frontends (to my knowledge) and would benefit everyone involved by
> becoming much more generic. e.g.,
>
>  -> 
> rather than
>  -> 
>
>  -> 
> rather than
>  -> 
>
> etc.
>
> I believe this will solve a number of issues and possibly get the BT and
> MacSword teams onboard to using the same HTML output filters as the
> other projects involve (or at least subclassing them and using the
> majority of their functionality).
>
>
> Now, as to the other issue of using XSLT internally in the engine to
> process OSIS -> HTML
>
> I will throw a few melons into the air for target practice, and let the
> shooting commence.
>
> _
> *Multiple Language*
>
> XSLT is a programming language in the same sense that C++ is a
> programming language.
>
> The SWORD Project C++ engine is written in C++.  It is not a Python
> engine; it is not a Perl engine; it is not a Java engine; it is C++.
>
> One might say, "Well, you can use XSLT from C++.  Doesn't JSword do this
> from Java?"  Well, yes, of course you can, and DM can comment, if he
> feels the desire to recommend his decision to encorporate an XSLT engine
> into the JSword logic flow.  But simply because one CAN doesn't mean one
> SHOULD.  We COULD encorporate a Perl text processing engine in our C++
> code, or an Awk processing engine...  that doesn't mean we SHOULD.  I'm
> sure some would say we SHOULD.  And obviously DM has thought he SHOULD
> encorporate XSLT processing for JSword, so I'm not intending to say it
> is a BAD decision, just that it is not a decision I would

Re: [sword-devel] XSLT vs. C++

[David Haslam]

Troy,

"I'll attempt to post a few easy to swallow SWORD 101 classes in email,
which will help us gather our thoughts and documents on how all this works.
"

Why not straight to the  http://crosswire.org/wiki/ wiki ?

David


-- 
View this message in context: 
http://sword-dev.350566.n4.nabble.com/Markup-Options-was-Re-Config-file-for-thml-module-tp3065508p3067336.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Markup Options

[Jonathan Morgan]

>From an application developer's point of view, I'm not convinced that per
module CSS is a good idea.  Here are some reasons:
1. I'm not convinced of "well-defined use of HTML+CSS classes".  Some things
may be well-defined, but I know BPBible does a lot of customisation of the
SWORD generated HTML and uses a lot of custom CSS, and some or all of these
things might break CSS designed for other apps (and vice versa).  I also do
not like the idea that my changes to either the HTML generated or the CSS
breaks the display of a module I have never seen.

2. Some of the application specific styles and user choices may conflict
with the module styles.  For example, I know Bibletime has themes, which can
change colour of foreground text, background, ...  I have thought about
doing a similar thing for BPBible.  However, this isn't going to work in
cases like: our poor user has a dark background, and the module developer
has decided to mark a particular text feature in a dark purple which is
nearly illegible.

3. As well as the single verse search results Karl mentions, the parallel
case comes to mind.  If I have multiple books using different style sheets,
how do I manage that?  Do the parallel Bibles end up in different and
clashing styles?  In BPBible I think we even generate different HTML for
these different places, so there's not even a guarantee that these styles
will apply cleanly and work.  However, if any modules are created that rely
on these custom styles to look OK, then we will need to have some way of
making them work in all these different contexts.

I could probably find more potential problems, but these will do for now.

On Wed, Dec 1, 2010 at 3:43 AM, Karl Kleinpaste  wrote:

> Greg Hellings  writes:
> > 2) I can provide an external CSS stylesheet along with my module.
> > Then I could still use OSIS and, assuming well-defined use of HTML+CSS
> > classes being produced from OSIS by the engine, I could style the
> > module the way I desired.  This would not require terribly much work
> > to be done on the OSISHTMLHREF filter, but both Jaak and Karl when I
> > spoke with them were unwilling to allow inclusion of an external CSS
> > file in a module.  Why? I may have misunderstood but it seemed they
> > were both of the opinion that presentation and appearance is of
> > paramount importance, and they want to control the presentation of
> > material in the applications.
>
> I don't specifically recall such a conversation, but I think you
> misunderstood whatever I may have said.  My perspective on CSS is that
> Xiphos cannot create a dependency on such a thing until we extricate
> ourselves from gtkhtml3, once and for all.
>
> Once we can be certain of always being able to link against a CSS-aware
> environment (xulrunner is there, of course, but we need WebKit for the
> sake of Win32), I don't think I'll even have a strong opinion, one way
> or the other, on whether a module should provide its own CSS.
>
> How to integrate it into display is another matter.  Standard filename
> within the subdir space of the content?  Probably, but not necessarily.
> And that would apply only to full-page (full chapter) displays; how to
> use such a stylesheet for single-verse search results, for example?
>
> The bigger problem with the idea of CSS is that its use will totally and
> finally leave behind all UIs which do not target HTML as their output
> methodology.  I.e. BibleCS has no hope.  I'm not sure which other UIs
> depend on something other than HTML.
>

I'm not aware of any active frontend other than BibleCS that doesn't use
some form of HTML.  Like Xiphos, BPBible's current rendering engine will not
support CSS properly, but BPBible 0.5 will.  And even without CSS, BibleCS
should still be able to display the text OK.

Jon
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Config file for thml module

[Karl Kleinpaste]

Chris Little  writes:
> I really wouldn't say that the collective output of people producing
> content in ThML for the Xiphos repository has any chance of countering the
> trend of OSIS/TEI content produced for CrossWire (numerically speaking).

It is not and never was any kind of competition.  It is simply the
objective fact that ThML is preferred for a lot of really very good
reasons in rather a lot of cases, and it's not going away.

Some non-trivial number of us continue to use ThML because It Just Works
in ways that OSIS seems unlikely ever to achieve.

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] XSLT vs. C++

[Martin Denham]

Excuse me for being pure Java and not knowing Sword C++ at all but can I add
(perhaps obviously) that an XSLT framework will perform noticeably slower
than a SAX-like framework.

Here
are
some performance comparisons.  They are old and Java-centric and so XSLT
performance may have improved but these tests show that in the worst case
XSLT was 3 times slower than SAX and a good SAX processor was twice as fast
as a good XSLT processor.  If pages are parsed at the chapter level then
users may notice a delay turning pages on smaller machines like mobile
phones.

Martin

On 1 December 2010 12:20, Troy A. Griffitts  wrote:

> The logic to get from any Publisher Source Document to rendered HTML is
> a very complex task to solve.
>
> We conceptually create Plato's Form of, say, a Bible, and try to fit
> imperfect Publisher markup into this concept.  A Bible has verses,
> headings between verses, chapter intros, footnotes, crossrefs, lemma
> information, etc.
>
> If we do not do this, then we become a PDF reader-- there are already
> PDF readers and we lose the ability to do Bible specific things with our
> software.  For example, if we didn't normalize the concept of crossref
> across all Books, then we couldn't turn them on and off; we couldn't
> provide a crossref panel in the reader which fills according to which
> crossref is hovered over, etc.  Same with notes, strongs, headings, etc.
>
> This causes us to impose our Form onto a publisher's text.  I understand
> why some people may not like this, but it is very much to our end users'
> benefit that we do this.  Without this, we become a web-browser or a PDF
> reader.  Which are fine for their purpose, but we intend to provide
> common, familiar, and sometimes novel Bible study aides to our reader.
>
> The current processing model is dark magic and I apologize for this.  It
> should be well documented and easy to modify.  I will attempt to improve
> the dissemination of knowledge of exactly WHAT our Forms are, how we
> impose those Forms on publishers' texts and improve the documentation
> and code to help others understand and have the ability to improve the
> code.
>
> I'll attempt to post a few easy to swallow SWORD 101 classes in email,
> which will help us gather our thoughts and documents on how all this works.
>
>
> Troy
>
>
>
> On 12/01/2010 12:09 AM, Greg Hellings wrote:
> > On Tue, Nov 30, 2010 at 1:08 PM, Troy A. Griffitts 
> wrote:
> >> Having finally returned from a hectic 2 weeks of conferences, and lots
> >> to do before leaving for Christmas, I'm not sure I'm up for a heated,
> >> passionate debate about technologies right now, but by all means, please
> >> commence the public discussion.
> >>
> >> Let me start by saying that everyone (I believe) agrees that we would
> >> like to have an HTML output from the engine which is more generic and
> >> would allow CSS to be applied if a frontend would like to do this.
> >> Currently HTMLHREF output from the engine is used by the widest number
> >> of frontends (to my knowledge) and would benefit everyone involved by
> >> becoming much more generic. e.g.,
> >>
> >>  -> 
> >> rather than
> >>  -> 
> >>
> >>  -> 
> >> rather than
> >>  -> 
> >>
> >> etc.
> >>
> >> I believe this will solve a number of issues and possibly get the BT and
> >> MacSword teams onboard to using the same HTML output filters as the
> >> other projects involve (or at least subclassing them and using the
> >> majority of their functionality).
> >
> > I think this is our pretty well accepted premise.  The current filters
> > stink to various degrees and currently no one is willing to step up
> > and tackle them.
> >
> >>
> >>
> >> Now, as to the other issue of using XSLT internally in the engine to
> >> process OSIS -> HTML
> >>
> >> I will throw a few melons into the air for target practice, and let the
> >> shooting commence.
> >>
> >> _
> >> *Multiple Language*
> >>
> >> XSLT is a programming language in the same sense that C++ is a
> >> programming language.
> >>
> >> The SWORD Project C++ engine is written in C++.  It is not a Python
> >> engine; it is not a Perl engine; it is not a Java engine; it is C++.
> >>
> >> One might say, "Well, you can use XSLT from C++.  Doesn't JSword do this
> >> from Java?"  Well, yes, of course you can, and DM can comment, if he
> >> feels the desire to recommend his decision to encorporate an XSLT engine
> >> into the JSword logic flow.  But simply because one CAN doesn't mean one
> >> SHOULD.  We COULD encorporate a Perl text processing engine in our C++
> >> code, or an Awk processing engine...  that doesn't mean we SHOULD.  I'm
> >> sure some would say we SHOULD.  And obviously DM has thought he SHOULD
> >> encorporate XSLT processing for JSword, so I'm not intending to say it
> >> is a BAD decision, just that it is not a decision I would make; in the
> >> same way as our projects each chose

Re: [sword-devel] XSLT vs. C++

[Peter von Kaehne]

> Von: "Troy A. Griffitts" 
> The current processing model is dark magic and I apologize for this.  It
> should be well documented and easy to modify.  I will attempt to improve
> the dissemination of knowledge of exactly WHAT our Forms are, how we
> impose those Forms on publishers' texts and improve the documentation
> and code to help others understand and have the ability to improve the
> code.
> 
> I'll attempt to post a few easy to swallow SWORD 101 classes in email,
> which will help us gather our thoughts and documents on how all this
> works.

Great! I am looking forward to that.


-- 
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] XSLT vs. C++

[Troy A. Griffitts]

The logic to get from any Publisher Source Document to rendered HTML is
a very complex task to solve.

We conceptually create Plato's Form of, say, a Bible, and try to fit
imperfect Publisher markup into this concept.  A Bible has verses,
headings between verses, chapter intros, footnotes, crossrefs, lemma
information, etc.

If we do not do this, then we become a PDF reader-- there are already
PDF readers and we lose the ability to do Bible specific things with our
software.  For example, if we didn't normalize the concept of crossref
across all Books, then we couldn't turn them on and off; we couldn't
provide a crossref panel in the reader which fills according to which
crossref is hovered over, etc.  Same with notes, strongs, headings, etc.

This causes us to impose our Form onto a publisher's text.  I understand
why some people may not like this, but it is very much to our end users'
benefit that we do this.  Without this, we become a web-browser or a PDF
reader.  Which are fine for their purpose, but we intend to provide
common, familiar, and sometimes novel Bible study aides to our reader.

The current processing model is dark magic and I apologize for this.  It
should be well documented and easy to modify.  I will attempt to improve
the dissemination of knowledge of exactly WHAT our Forms are, how we
impose those Forms on publishers' texts and improve the documentation
and code to help others understand and have the ability to improve the code.

I'll attempt to post a few easy to swallow SWORD 101 classes in email,
which will help us gather our thoughts and documents on how all this works.


Troy



On 12/01/2010 12:09 AM, Greg Hellings wrote:
> On Tue, Nov 30, 2010 at 1:08 PM, Troy A. Griffitts  
> wrote:
>> Having finally returned from a hectic 2 weeks of conferences, and lots
>> to do before leaving for Christmas, I'm not sure I'm up for a heated,
>> passionate debate about technologies right now, but by all means, please
>> commence the public discussion.
>>
>> Let me start by saying that everyone (I believe) agrees that we would
>> like to have an HTML output from the engine which is more generic and
>> would allow CSS to be applied if a frontend would like to do this.
>> Currently HTMLHREF output from the engine is used by the widest number
>> of frontends (to my knowledge) and would benefit everyone involved by
>> becoming much more generic. e.g.,
>>
>>  -> 
>> rather than
>>  -> 
>>
>>  -> 
>> rather than
>>  -> 
>>
>> etc.
>>
>> I believe this will solve a number of issues and possibly get the BT and
>> MacSword teams onboard to using the same HTML output filters as the
>> other projects involve (or at least subclassing them and using the
>> majority of their functionality).
> 
> I think this is our pretty well accepted premise.  The current filters
> stink to various degrees and currently no one is willing to step up
> and tackle them.
> 
>>
>>
>> Now, as to the other issue of using XSLT internally in the engine to
>> process OSIS -> HTML
>>
>> I will throw a few melons into the air for target practice, and let the
>> shooting commence.
>>
>> _
>> *Multiple Language*
>>
>> XSLT is a programming language in the same sense that C++ is a
>> programming language.
>>
>> The SWORD Project C++ engine is written in C++.  It is not a Python
>> engine; it is not a Perl engine; it is not a Java engine; it is C++.
>>
>> One might say, "Well, you can use XSLT from C++.  Doesn't JSword do this
>> from Java?"  Well, yes, of course you can, and DM can comment, if he
>> feels the desire to recommend his decision to encorporate an XSLT engine
>> into the JSword logic flow.  But simply because one CAN doesn't mean one
>> SHOULD.  We COULD encorporate a Perl text processing engine in our C++
>> code, or an Awk processing engine...  that doesn't mean we SHOULD.  I'm
>> sure some would say we SHOULD.  And obviously DM has thought he SHOULD
>> encorporate XSLT processing for JSword, so I'm not intending to say it
>> is a BAD decision, just that it is not a decision I would make; in the
>> same way as our projects each chose C++ vs. Java to implement our objective.
> 
> If a developer is going to develop OSIS -> HTML filters, for instance,
> we are already assuming they know OSIS and HTML.  OSIS is XML and HTML
> is SGML (though most of our work is probably targetting a more
> XML-dialect of HTML).  XSLT is also XML.  Formally, it is not even a
> programming language, but just a set of formatting/processing
> instructions in XML.
> 
> Any developer using XML who is worth their salt should at least be
> familiar with the basics of XSL - they may not be a guru of XPath
> expressions or have every attribute of XSL memorized - and would
> probably expect a library which handles XML as its preferred input
> method to utilize one of the standard XML processing methods.  I know
> I'm not the only person who was surprised to look in the library
> filters and see neither DOM, SAX nor XSLT techno

Re: [sword-devel] Converting Formats (was Re: Config file for thml module)

[David Haslam]

Chris,

Just a thought 

While you are using mod2imp on a large set of modules, it would be useful to
keep a list of any module features that seem to be lost by this process.

Such a list could eventually be addressed by future enhancements of mod2imp.


David


-- 
View this message in context: 
http://sword-dev.350566.n4.nabble.com/Converting-Formats-was-Re-Config-file-for-thml-module-tp3066373p3066991.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page