[sword-devel] Sword support of indents and line breaks

DM Smith dmsmith at crosswire.org
Sat Apr 13 06:09:38 MST 2013


I would add that the new HTML filter is a work in progress. It is moving to class attributes as a way to abstract presentation out of the filter.

This is goodness. I'd recommend that we take the OSIS spec and create a mapping of each element to the corresponding HTML element and class variables (i.e. a design doc, fancy that ;)

A full implementation would represent all OSIS in HTML and move presentation to the front-end, where it belongs.

In Him,
	DM

On Apr 13, 2013, at 7:35 AM, Peter von Kaehne <refdoc at gmx.net> wrote:

> Can I try and summarise what I think is going on here?
> 
> Basis of problem:
> 
> 1) CrossWire has a whitespace/title/poetry problem which has been
> discussed at nauseam for many years. But it has neither been thoroughly
> resolved nor even isolated. Various parties have blamed each other -
> module makers, osis2mod maintainer, filter maintainer, frontend
> developers (and maybe others, including bystanders) DOI - module maker
> and happy to blame anyone, including myself as long as it finally
> improves.
> 
> 2) IBT had a specific need and had someone in their midst willing to
> cater to that need, using our CrossWire's efforts but was miffed by
> problem (1)
> 
> 3) IBT - outside of the Wycliffe/UBS "tradition" of using Paratext - has
> developed it own use of USFM with specific rules about markup, sometimes
> breaking semantic rules.
> 
> The problem grows:
> 
> 4) IBT's lead programmer decides to solve IBT's immediate problem by
> applying his own patches to sword and maintain his own version of
> libsword and OSIS with little or no communication with Sword people and
> no attempt to isolate and solve the underlying problem (1) either.
> 
> The problem becomes apparent:
> 
> 5) People in IBT's area start to use smartphones and Mac's and
> subsequently IBT's offer of xulsword is not sufficient anymore - making
> (1) obvious to everyone and letting (4) fail.
> 
> The problem becomes a bunfight:
> 
> 6) Instead of looking at (1), (2) and (3) respectively and finding both
> the remaining whitespace bugs + fix IBT's "dodgy" USFM encoding we are
> fighting for two positions which are actually both not particularly
> good.
> 
> I note John's recent email which says that translators do not understand
> and/or care about semantic markup, just how it looks like and that it is
> understandable. I think this is fair enough - only the "understandable"
> varies from platform to platform. What is understandable on paper will
> not work on gobible and will create a mess in other places too. So, as
> computer people it is our job to find the patterns and encode the
> patters correctly, semantically, including on occasion feeding back to
> the translaters - "yes, I know what you want to achieve, but _this_ is
> the way you should encode it, we will fix the presentation afterwards."
> 
> The <milestone/> element is indeed intended to encode translater intent
> for the odd and bizarre. But IBT's desire is not odd and bizarre. Only
> its solutions are. A lot of times when the <milestone> is used there are
> perfectly adequate structural OSIS elements available - q, p, div,
> poetry markup and a few more. A few milestones will subsequently maybe
> still remain. But not even 10% by my reckoning. 
> 
> On CrossWire's side though we need 
> 
> a) the ability to add per language or per module the means (maybe CSS?_
> to ensure that certain language conventions which are necessary for
> readability do not fall foul of our (mis)understanding how certain
> structures should look like. If a language requires that e.g. a <q/>
> element is not just encoded with a ", but will include a linebreak, an
> indent, a longdash and a few more things at the beginning and some
> others at the end, then this should be acceptable and reproducible.
> Routinely and easily.
> 
> b) a final push to get the USFM/OSIS/module witespace/interverse
> content/intraverse extra content/title etc mess sorted. 
> 
> Peter
> _______________________________________________
> 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