date:20110419

On 19/04/11 09:02, David Haslam wrote:
So what should front-end applications use for presentational rendering in
such modules when the Bible translation features added words?
i.e. In USFM as marked using \add_...\add*

And in OSIS the markup is in a similar way semantic, not presentational.

It only becomes presentational in our output filters where it is
replaced in the osis2htmlhref filter to a i for italics IIRC. Not all
frontends of course use the engine supplied filters.

I am wondering what more modern rendering engines do with this markup
with appropriate fonts in scripts like Arabic, Hindic or Chinese. Maybe
this is something already taken care of there?

Alternatively, the more semantic HTML markup of em might be useful?

However I turn it though I do think this is/should/could be a rendering
issue at the very last moment - i.e. at screen output time, probably
steered by module or locale supplied CSS sheets. The alternative, if
there is a serious issue - and I would only see this if the translators
complain - then it might be something addressed by an additional output
filter, but this would be hard work as it would require some work in the
engine and potentially some more in the frontends.

Has there been any previous discussion on this topic?

I do not think so.

Peter

David

--
View this message in context:
http://sword-dev.350566.n4.nabble.com/Rendering-added-words-for-languages-that-don-t-use-italics-tp3459750p3459750.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] MDF/SFM Dictionary Import into Sword Format

On 18/04/11 19:51, David Haslam wrote:
 Probably something that could be easily implemented by making a bespoke
 TextPipe filter.

usfm2osis.pl should be relatively easy to adapt to this. I remember
thinking about it once when I saw a website aiming to create
multilingual Strong dictionaries/

Peter

___
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] KJV vs Russian Synodal versification comparison

2011-04-19 Thread Konstantin Maslyuk

Hi, Andy.

You  haven't answered on this list. And i just would like to know, was
content i have sent to you useful for you? Whether you have understood
how that data was organized?

God bless.

 Hi all,
  
 I  am working on preparing text for 2 Central Asian languages and as
 we  test  different  applications we are trying to make sure that we
 cover  as  many areas of possible error as possible. I was wondering
 if  as you, the app developers, have developed support for different
 versifications  if  you have a document or some info on what exactly
 is different between the KJV and Russian Synodal versification. Some
 kind  of  documented  info  on this would be of great help as at the
 moment  we  just  have some pointers which some people have given us
 but not a complete list.
  
 Many thanks,
 Andy



___
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] Rendering added words for languages that don't use italics?

2011-04-19 Thread David Haslam

The question was prompted by encountering a translation in which the
translators are currently using MS Word (i.e. rather than Bibledit or
Paratext), and for which they were marking added words in a shade of grey.

As it happens, they could have [also] used italics in MS Word, and had even
made some attempt in this direction, albeit inconsistently.  It's a small
outfit, not part of a member agency that qualifies for using Paratext. You
will readily appreciate that I am trying to steer them to use Bibledit. 

This question also brings to the fore a corollary one 

When a different font colour is used to render \add_...\add* ( the OSIS
equivalent), what should happen to the added words within Words of Jesus in
a red letter edition?

The topic is more complex than at first sight. I'm glad that I thought of
asking it.

David

--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/Rendering-added-words-for-languages-that-don-t-use-italics-tp3459750p3460274.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] Rendering added words for languages that don't use italics?

On Tue, Apr 19, 2011 at 3:24 AM, Peter von Kaehne ref...@gmx.net wrote:
 Alternatively, the more semantic HTML markup of em might be useful?

There has been a move away from pushing em and strong in the HTML
world, since it has been recognized that italics do not always
semantically mean emphasis and bold does not always semantically
mean strong.  This situation is a perfect example.


 However I turn it though I do think this is/should/could be a rendering
 issue at the very last moment - i.e. at screen output time, probably
 steered by module or locale supplied CSS sheets. The alternative, if
 there is a serious issue - and I would only see this if the translators
 complain - then it might be something addressed by an additional output
 filter, but this would be hard work as it would require some work in the
 engine and potentially some more in the frontends.

Great idea. Only one problem - everyone who has authority and power
over such on these mailing lists thinks that module supplied CSS
sheets is an abomination. Even though translators already have
complained about the lack of the ability to create and use them.



 Has there been any previous discussion on this topic?

 I do not think so.

There has within the context of module-supplied rendering mechanisms.
Not in my house was the mostly unanimous reply.

--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] Rendering added words for languages that don't use italics?


On 04/19/2011 09:27 AM, Greg Hellings wrote:

On Tue, Apr 19, 2011 at 3:24 AM, Peter von Kaehneref...@gmx.net  wrote:

Alternatively, the more semantic HTML markup ofem  might be useful?

There has been a move away from pushingem  andstrong  in the HTML
world, since it has been recognized that italics do not always
semantically mean emphasis and bold does not always semantically
mean strong.  This situation is a perfect example.


However I turn it though I do think this is/should/could be a rendering
issue at the very last moment - i.e. at screen output time, probably
steered by module or locale supplied CSS sheets. The alternative, if
there is a serious issue - and I would only see this if the translators
complain - then it might be something addressed by an additional output
filter, but this would be hard work as it would require some work in the
engine and potentially some more in the frontends.

Great idea. Only one problem - everyone who has authority and power
over such on these mailing lists thinks that module supplied CSS
sheets is an abomination. Even though translators already have
complained about the lack of the ability to create and use them.


Has there been any previous discussion on this topic?

I do not think so.

There has within the context of module-supplied rendering mechanisms.
Not in my house was the mostly unanimous reply.


In principle, I like the idea of CSS, but I think there are difficulties 
with CSS. It presumes the elements and structure of what is being styled 
and that the display can handle it.


CSS is a container model, but osis2mod unwinds the 
Book/Section/Paragraph structure of a OSIS input into marker elements. 
How would CSS be written to address this? Would it be written for the 
authored OSIS or the transformed OSIS?


SWORD has several renderers, HTML, RTF, plain text, How would CSS 
apply in the delivery context of RTF?


For example, JSword transforms ThML, GBF, TEI and Plaintext into OSIS 
(augmented with SWORD's usage of TEI). Even OSIS and TEI undergo minor 
transformations. Then OSIS is converted into HTML. To what would the CSS 
apply?


The ability of a frontend to use CSS might be a problem. If I remember 
correctly, Xiphos was unable to use CSS. JSword/BD cannot at this time 
use an external stylesheet. Also JSword uses Java's built in HTML 
renderer and it is severely crippled and the HTML it requires is ancient.


I think that if someone had the initiative to write generalized code 
that would apply CSS to an OSIS module, use it successfully in a 
front-end, and submit it for inclusion into SWORD that it might happen. 
There are a lot of us that are quite willing to discuss an idea, but 
there are very few that will actually implement. Those that do implement 
prioritize what is important to them.


In Him,
DM




___
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] Rendering added words for languages that don't use italics?

On 04/19/2011 04:24 AM, Peter von Kaehne wrote:

On 19/04/11 09:02, David Haslam wrote:

So what should front-end applications use for presentational rendering in
such modules when the Bible translation features added words?
i.e. In USFM as marked using \add_...\add*

And in OSIS the markup is in a similar way semantic, not presentational.

It only becomes presentational in our output filters where it is
replaced in the osis2htmlhref filter to ai for italics IIRC. Not all
frontends of course use the engine supplied filters.

I'm wondering whether it'd be possible to add language filters.

Basic idea:
If the front-end requests an OSIS2XXX render and there is a
corresponding OSIS2XXX-lang renderer based on the modules language, it
will be automatically added in front of OSIS2XXX.

It would grab the elements that produced italics in the OSIS2XXX
renderer and transform them appropriately (e.g. hi, transChange). It
could deal with other elements as well.

From what I remember of the osis2xxx renderers they pass what they
don't expect.

Alternatively to pre-processing, the language filter could be a
post-process, merely changing i.../i to something else. Granted, the
semantic content of what produced the i isn't present, but it's not
present for the reader in any other language either.

I am wondering what more modern rendering engines do with this markup
with appropriate fonts in scripts like Arabic, Hindic or Chinese. Maybe
this is something already taken care of there?

Alternatively, the more semantic HTML markup ofem might be useful?

Has there been any previous discussion on this topic?

I do not think so.

Peter

David

___
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] Rendering added words for languages that don't use italics?

Another problematic markup for other languages is
divineName.../divineName
The SWORD engine tries to apply small caps to the content by simulation.
The first letter is converted to uppercase if it isn't already. Then the
remainder of the word is converted to upper case and wrapped in code
that reduces the font size.

The two problems:
It presumes a byte oriented character set. I.e. Windows latin-1
(cp1252). It does not work if it contains UTF-8.
Second, it presumes that upper case applies to the language. (Which
isn't true of Arabic, Farsi, ...)

In Him,
DM

On 04/19/2011 04:02 AM, David Haslam wrote:

Not all languages have fonts that include italics as a text style.

Italics are generally unavailable except for the scripts that use Latin,
Greek and Cyrillic alphabets.
[probably a gross over-simplification, but you get the gist of what I'm
saying]

So what should front-end applications use for presentational rendering in
such modules when the Bible translation features added words?
i.e. In USFM as marked using \add_...\add*

Has there been any previous discussion on this topic?

David

___
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] Rendering added words for languages that don't use italics?


  Alternatively, the more semantic HTML markup ofem  might be useful?
  There has been a move away from pushingem  andstrong  in the HTML
  world, since it has been recognized that italics do not always
  semantically mean emphasis and bold does not always semantically
  mean strong.  This situation is a perfect example.

Actually, yes, but reverse to what you want to state.

The i interpretation happens very late in our chain - at rendering filter 
level. And I would think it is probably a wrong decision. It would be trivial 
to change that to em which in turn might be rendered more likely in an 
appropriate emphasis of whatever sort in scripts which do not do italics.

My comments to not refer to JSWORD, of which I have no real clue of.

Wrt CSS - I do not want to reopen the debate. But at the core of this 
particular problem is a fairly arbitrary set of conventions which presumably 
vary wildly across cultures - and even in our own language. The KJV and some 
related Bibles tag translation additions by packing them into []. Others use 
italics. We do not know what Chinese, Mongolians, Arabs use. Maybe they ignore 
the issue, maybe they use pink colouring for the fonts.

This could therefore be seen as a style issue, as all these issues could be 
rendered successfully (as long as the render engines understand the directives) 
at that level - adding a [ via before directive, changing font colour or 
indeed shifting to italics. 

Alternatively - and we have discussed this in another place - there is also a 
need for some locale dependent rendering of references, and this matter would 
be somewhat related. Instead of css styling the one before last step in the 
filters could presumably read and apply loalised rendering info ([..], span 
style=font-color:pink or i tags) for any of these issues - i.e. by using 
the relevant set of alternatives in any of the issues where we want a localised 
output. This would then work across the board of libsword derived frontends (or 
not).

Wrt implementation, if the em tag would do the job across scripts - and this 
would be a worthwhile project for someone not too skilled - then this woudl be 
all we wanted. And it would be a simple implementation.

If we need something more profound we got indeed a problem.

Peter

 

Peter

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

___
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] CSS Again... (was Re: Rendering added words for languages that don't use italics?)

On Tue, Apr 19, 2011 at 9:35 AM, DM Smith dmsm...@crosswire.org wrote:
 In principle, I like the idea of CSS, but I think there are difficulties
 with CSS. It presumes the elements and structure of what is being styled and
 that the display can handle it.

Are these problems greater than our current solution of Sorry, nope,
you can't style _anything_ because there are some niche cases where
styling might be bad?


 CSS is a container model, but osis2mod unwinds the Book/Section/Paragraph
 structure of a OSIS input into marker elements. How would CSS be written to
 address this? Would it be written for the authored OSIS or the transformed
 OSIS?

Since CSS is a display technology and SWORD does not uses OSIS for
display, clearly this question does not even apply.


 SWORD has several renderers, HTML, RTF, plain text, How would CSS apply
 in the delivery context of RTF?

Can we stop even bringing up RTF? BibleCS's choice to use RTF means
that it will always be limited to the problems inherent in that
technology, just as every other front end has chosen HTML and is
limited by that.  This is one of the niche cases I referred to above.
Well, BibleCS wouldn't be able to employ this SGML-based technology,
so let's just ignore it and keep pooh-pooh-ing it.


 For example, JSword transforms ThML, GBF, TEI and Plaintext into OSIS
 (augmented with SWORD's usage of TEI). Even OSIS and TEI undergo minor
 transformations. Then OSIS is converted into HTML. To what would the CSS
 apply?

To the HTML, of course. CSS can be applied directly to OSIS, but that
would require JSword to write a massive amount of CSS to give styling
to every OSIS element (just like it currently has an XSL file that
transforms every OSIS element). So long as the application is using
HTML, then the stylesheet would be applied directly to the HTML.


 The ability of a frontend to use CSS might be a problem. If I remember
 correctly, Xiphos was unable to use CSS. JSword/BD cannot at this time use
 an external stylesheet. Also JSword uses Java's built in HTML renderer and
 it is severely crippled and the HTML it requires is ancient.

Xiphos currently uses two different display technologies: gtkmozembed,
which is the Mozilla/Firefox/Gecko rendering engine. Where that is not
available (Windows) it uses gtkhtml. This makes the Windows build in
the same boat as JSword/BD at present. I am working with Karl, Terry
and Matthew to update to gtkwebkit for all platforms - both because
Mozilla is dropping support for embedding and because I want to see
proper support on Windows for Xiphos.

Of course, this line of argument is the same as digging up RTF.
Because the widget I have does not understand this 14 year old,
fundamental web technology, clearly we should not support it.  BD is
limited by its choice of display technologies just like Xiphos is.
Xiphos has chosen to update its display technologies. BD would
probably benefit from opting to do so as well. Additionally, with the
CSS file on-disk, BD could simply insert the file directly into the
rendered output, removing the need for the stylesheet to be external.
I believe BPBible up until recently has used the wxHtml widget which
is also limited. Correct me if I'm wrong, but I believe they are
opting to update to a more functional widget. BibleCS, well.


 I think that if someone had the initiative to write generalized code that
 would apply CSS to an OSIS module, use it successfully in a front-end, and
 submit it for inclusion into SWORD that it might happen. There are a lot of
 us that are quite willing to discuss an idea, but there are very few that
 will actually implement. Those that do implement prioritize what is
 important to them.

I had support in BibleTime for this already in place when I brought it
up last time. All that was needed was an agreement on a conf-file
entry name by SWORD.  But the idea of using CSS was summarily rejected
by the list. Similarly, Jaak gave a Not on my watch response to
enabling the technology in BibleTime should SWORD reach an agreement
on it. After all, then BibleTime would not be able to maintain
absolute dominance over every pixel of display. Never mind that it
already does not maintain this by virtue of allowing ThML-sourced
documents to have CSS styling tags on them and allowing external CSS
could actually reduce the impact of this loss of control.

So I went to Xiphos and Karl was not impressed with the idea. Digging
further turned up the fact that gtkhtml has about as good support for
CSS as Java does. So I offered to help with the gtkwebkit move for a
multiplicity of reasons, one being that hopefully Karl will consider
adding support for external CSS files to Xiphos after the rendering
engine supports them.  But if SWORD simply shoots them down again, for
virtue of That's very nice but MY rendering widget can't handle CSS
like happened before...

Part of having a choice of front-ends is the fact that some are
limited by their choices in technology.

Re: [sword-devel] CSS Again... (was Re: Rendering added words for languages that don't use italics?)

Leaving aside the cencerns of implementation the identified issues where the we 
currently systematically fail non Latin scripts (and many non english languages 
with latin script) are, by applying English standards 

1) references
2) divineName
3) emphasis/highlighting
4) quotations (partially addressed)

Any other?

Peter
-- 
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit 
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

___
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] Rendering added words for languages that don't use italics?

On Tue, Apr 19, 2011 at 10:24 AM, Peter von Kaehne ref...@gmx.net wrote:
 The i interpretation happens very late in our chain - at rendering filter 
 level. And I would think it is probably a wrong
 decision. It would be trivial to change that to em which in turn might be 
 rendered more likely in an appropriate emphasis of
 whatever sort in scripts which do not do italics.


i is supposed to be back and in full force with HTML5, no longer
carrying the emphasis idea.  em is still present to mean emphasis.
 Use of em by us for this indication would be incorrect, as we are
not trying to emphasize the words, but rather indicate they are a
translation change. A more appropriate method would be span
class=transChangeword/span and then let the translation choose
how it wants this represented in an HTML-based display. Which pretty
much sums up everywhere except BibleCS.

 Wrt CSS - I do not want to reopen the debate. But at the core of this 
 particular problem is a fairly arbitrary set of conventions
 which presumably vary wildly across cultures - and even in our own language. 
 The KJV and some related Bibles tag
 translation additions by packing them into []. Others use italics. We do not 
 know what Chinese, Mongolians, Arabs use.
 Maybe they ignore the issue, maybe they use pink colouring for the fonts.


KJVs used italics. Some English translations use [word]. Some use
⌊word⌋. Some ignore the issue completely.  I think we're not dealing
with a language-level problem here but a translation-level problem.
Some translators recognize that they are required to provide multiple
words in some cases for the target language and combine multiple
source words. And they realize that the average reader will only be
confused by Well the word 'is' does not really appear in the
original, so maybe this meaning is completely wrong, because the
average reader doesn't know that it was common in the source language
to omit the word 'is' and other equivalent scenarios.

This issue is really a per-module issue and not a per-language or
per-frontend issue.

 This could therefore be seen as a style issue, as all these issues could be 
 rendered successfully (as long as the render
 engines understand the directives) at that level - adding a [ via before 
 directive, changing font colour or indeed shifting to
 italics.

 Alternatively - and we have discussed this in another place - there is also a 
 need for some locale dependent rendering of
 references, and this matter would be somewhat related. Instead of css styling 
 the one before last step in the filters could
 presumably read and apply loalised rendering info ([..], span 
 style=font-color:pink or i tags) for any of these issues -
 i.e. by using the relevant set of alternatives in any of the issues where we 
 want a localised output. This would then work
 across the board of libsword derived frontends (or not).

 Wrt implementation, if the em tag would do the job across scripts - and 
 this would be a worthwhile project for someone not
 too skilled - then this woudl be all we wanted. And it would be a simple 
 implementation.

I think choosing a presentation markup, like em, is a terrible idea.
It completely leaves out your own hypothetical What if they choose to
use light pink scenario and forces everyone to go with whatever em
might do to their script, including not appear at all, cause those
words to be read more loudly or forcefully or cause extra markers for
emphasis to be added or cause new words in a language to be added,
etc. Generally the purpose of denoting transChange is to actually do
the exact opposite - deemphasize the word as, This was not in the
original language, so treat it with caution.

--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] CSS Again... (was Re: Rendering added words for languages that don't use italics?)

2011-04-19 Thread Troy A. Griffitts

Again, to be rude and top-post, not having a specific line in the
message to which I wish to comment...

I don't believe anyone is against HTML rendering frontends supplying
stylesheets to their output.

I believe Bibletime does this for their user selectable themes.

I have often lamented the fact that we have at least 3 HTML rendering
filter sets and have stated that I would love for us all to agree on a
common, more class-ified HTML output if everyone would concede to share
the same filter set and help improve the commonly used code.

I believe frontend developers were in general agreement that
module-specific style sheets would be a bad idea because they already
currently allow custom styles for their users and there would most
certainly be a conflict between what the module writer desires and for
what the user asks.

I believe I was against the proposal to replace the current filtering
mechanism with an xslt engine.

I think this sums up where we all stood the last time we discussed
this.  Have I misrepresented anyone, please speak up.

Troy



On 04/19/2011 04:41 PM, Greg Hellings wrote:
 On Tue, Apr 19, 2011 at 9:35 AM, DM Smith dmsm...@crosswire.org wrote:
 In principle, I like the idea of CSS, but I think there are difficulties
 with CSS. It presumes the elements and structure of what is being styled and
 that the display can handle it.
 Are these problems greater than our current solution of Sorry, nope,
 you can't style _anything_ because there are some niche cases where
 styling might be bad?

 CSS is a container model, but osis2mod unwinds the Book/Section/Paragraph
 structure of a OSIS input into marker elements. How would CSS be written to
 address this? Would it be written for the authored OSIS or the transformed
 OSIS?
 Since CSS is a display technology and SWORD does not uses OSIS for
 display, clearly this question does not even apply.

 SWORD has several renderers, HTML, RTF, plain text, How would CSS apply
 in the delivery context of RTF?
 Can we stop even bringing up RTF? BibleCS's choice to use RTF means
 that it will always be limited to the problems inherent in that
 technology, just as every other front end has chosen HTML and is
 limited by that.  This is one of the niche cases I referred to above.
 Well, BibleCS wouldn't be able to employ this SGML-based technology,
 so let's just ignore it and keep pooh-pooh-ing it.

 For example, JSword transforms ThML, GBF, TEI and Plaintext into OSIS
 (augmented with SWORD's usage of TEI). Even OSIS and TEI undergo minor
 transformations. Then OSIS is converted into HTML. To what would the CSS
 apply?
 To the HTML, of course. CSS can be applied directly to OSIS, but that
 would require JSword to write a massive amount of CSS to give styling
 to every OSIS element (just like it currently has an XSL file that
 transforms every OSIS element). So long as the application is using
 HTML, then the stylesheet would be applied directly to the HTML.

 The ability of a frontend to use CSS might be a problem. If I remember
 correctly, Xiphos was unable to use CSS. JSword/BD cannot at this time use
 an external stylesheet. Also JSword uses Java's built in HTML renderer and
 it is severely crippled and the HTML it requires is ancient.
 Xiphos currently uses two different display technologies: gtkmozembed,
 which is the Mozilla/Firefox/Gecko rendering engine. Where that is not
 available (Windows) it uses gtkhtml. This makes the Windows build in
 the same boat as JSword/BD at present. I am working with Karl, Terry
 and Matthew to update to gtkwebkit for all platforms - both because
 Mozilla is dropping support for embedding and because I want to see
 proper support on Windows for Xiphos.

 Of course, this line of argument is the same as digging up RTF.
 Because the widget I have does not understand this 14 year old,
 fundamental web technology, clearly we should not support it.  BD is
 limited by its choice of display technologies just like Xiphos is.
 Xiphos has chosen to update its display technologies. BD would
 probably benefit from opting to do so as well. Additionally, with the
 CSS file on-disk, BD could simply insert the file directly into the
 rendered output, removing the need for the stylesheet to be external.
 I believe BPBible up until recently has used the wxHtml widget which
 is also limited. Correct me if I'm wrong, but I believe they are
 opting to update to a more functional widget. BibleCS, well.

 I think that if someone had the initiative to write generalized code that
 would apply CSS to an OSIS module, use it successfully in a front-end, and
 submit it for inclusion into SWORD that it might happen. There are a lot of
 us that are quite willing to discuss an idea, but there are very few that
 will actually implement. Those that do implement prioritize what is
 important to them.
 I had support in BibleTime for this already in place when I brought it
 up last time. All that was needed was an agreement on a conf-file
 entry

Re: [sword-devel] CSS Again... (was Re: Rendering added words for languages that don't use italics?)

On Tue, Apr 19, 2011 at 11:13 AM, Troy A. Griffitts
scr...@crosswire.org wrote:
 Again, to be rude and top-post, not having a specific line in the
 message to which I wish to comment...

 I don't believe anyone is against HTML rendering frontends supplying
 stylesheets to their output.

 I believe Bibletime does this for their user selectable themes.

This is correct. As part of my changes to BibleTime I migrated themes
out of being HTML templates where all the HTML structure was identical
and the included CSS was different to be a single HTML template with
an included CSS file which differed.

This, however, is nothing remotely like allowing a module to specify
its own rendering stylesheet.  Using CSS as a technology and using CSS
as a paradigm are far cries from one another.


 I have often lamented the fact that we have at least 3 HTML rendering
 filter sets and have stated that I would love for us all to agree on a
 common, more class-ified HTML output if everyone would concede to share
 the same filter set and help improve the commonly used code.

I think you might get a more robust agreement if the internal
technology were more akin to JSword's.  And I'm not talking about its
use of XSL because you have already stated your firm opposition to it.
 But if filters brought source material into OSIS and then the
HTML-rendering filters were a single implementation of SAX-style
processing out of OSIS (you have said that SWORD has a SAX-like
interface), you might find this goal easier.  BibleTime's extension of
the OSISHTMLHREF class seems to use a process similar to SAX.


 I believe frontend developers were in general agreement that
 module-specific style sheets would be a bad idea because they already
 currently allow custom styles for their users and there would most
 certainly be a conflict between what the module writer desires and for
 what the user asks.

An argument which really has no credibility. For 14 years the Web has
been working positively smashingly with the CSS technology. It is
specifically designed to allow this type of conflict to be resolved by
having a well-defined hierarchy of style resolution: user important 
author important  author normal  user normal  user agent. Author
stylesheets are resolved as such: style tag  inline  external.  If
you want to read more about it, it is one of the more lucid, brief and
straight-forward w3c statements:
http://www.w3.org/TR/CSS2/cascade.html#cascading-order.

Why this is able to work for tens of millions of websites and web
pages who have no control over their users' user-agents but can't be
used by us, who have extensive control over how the user can see the
data is beyond me.

--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] Rendering added words for languages that don't use italics?


On 04/19/2011 12:00 PM, Greg Hellings wrote:

KJVs used italics. Some English translations use [word]. Some use
⌊word⌋. Some ignore the issue completely.  I think we're not dealing
with a language-level problem here but a translation-level problem.
Some translators recognize that they are required to provide multiple
words in some cases for the target language and combine multiple
source words. And they realize that the average reader will only be
confused by Well the word 'is' does not really appear in the
original, so maybe this meaning is completely wrong, because the
average reader doesn't know that it was common in the source language
to omit the word 'is' and other equivalent scenarios.

This issue is really a per-module issue and not a per-language or
per-frontend issue.
I think it is a renderer issue. The proper way to markup the added 
text in OSIS is:

transChange type=addedthis is added text/transChange

This markup is the same whether regardless of the language of the module 
or the preference of the publisher/author/translator.


The various renderers convert this into something else. The SWORD OSIS 
- html renderers convert this into ithis is added text/i.


In Him,
DM

___
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] Rendering added words for languages that don't use italics?


On 04/19/2011 01:10 PM, DM Smith wrote:

On 04/19/2011 12:00 PM, Greg Hellings wrote:

KJVs used italics. Some English translations use [word]. Some use
⌊word⌋. Some ignore the issue completely.  I think we're not dealing
with a language-level problem here but a translation-level problem.
Some translators recognize that they are required to provide multiple
words in some cases for the target language and combine multiple
source words. And they realize that the average reader will only be
confused by Well the word 'is' does not really appear in the
original, so maybe this meaning is completely wrong, because the
average reader doesn't know that it was common in the source language
to omit the word 'is' and other equivalent scenarios.

This issue is really a per-module issue and not a per-language or
per-frontend issue.
I think it is a renderer issue. The proper way to markup the added 
text in OSIS is:

transChange type=addedthis is added text/transChange

This markup is the same whether regardless of the language of the 
module or the preference of the publisher/author/translator.


The various renderers convert this into something else. The SWORD OSIS 
- html renderers convert this into ithis is added text/i.


Troy's suggestion of changing this from iword/i to span 
class=addedword/span is a good one.


This removes the problem from the engine.

With a well-defined output with class attributes, then CSS can solve the 
problem on a per module basis.




In Him,
DM

___
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] KJV vs Russian Synodal versification comparison

2011-04-19 Thread Andy Harris

Hi Konstantin,

Sorry for now answering earlier - your file has been incredibly helpful in
trying to understand this and to chase down where this mapping should come
in!
However I am still trying to pick my way through this!
It seems that there are not only different versification formats (KJV and
Synodal) but that different Synodal versions have different (possibly
incorrect) mapping as well :-(
Additionally it seems that the versification is of course different between
the Protestant Synodal and the Synodal!

This has caused me a bit of a headache I'm afraid to say!

Let me explain... 
I now have your Synodal xml reference, 1 product's reference (and another
product that supports this versification to look at) and 1 cheat sheet to
explain the mappings.
It seems that neither reference matches exactly to what we have, although,
the products both work as expected?!
Eg: (and I appreciate that you said your file does contain errors but I'm
just trying to sort out where they might be - either on our side or in the
file you sent)
KJV Synodal
In your file:   Lev.14.55-Lev.14.56 Lev.14.55
Ref1:   Lev 14:56   Lev 14:55
Lev 14:57   Lev 14:56
Ref2:   Lev 14:55 - Lev 15:56   Lev 14:55
Lev 14:57   Lev 14:56
Kazakh text:Lev 14:56 - Lev 15:57   Lev 14:56

Now I'm not sure which it should be, but it seems that the Kazakh text is
totally different to everyone else :-( Which may mean a mistake in the
Kazakh text :-(
And to add to the situation this verse talks about clean and unclean ;-)

I guess what I really need is the ultimate reference to differences in
mapping between the KJV and the Protestant Synodal if someone has compiled
that?!

Until then I need to unpick a bit more of where these differences are
occurring.
Hopefully I can feed back to everyone once I have a clearer view.
Any further suggestions would be a great help!

Many thanks,
Andy//


___
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] Unicode normalisation and arabic vowel filter