On 04/13/2013 09:24 AM, Chris Little wrote:
On 4/12/2013 11:18 AM, John Austin wrote:
On 04/12/2013 07:45 PM, Chris Little wrote:
I've worked with many, many SFM texts, and they often do not follow SFM
rules or play nice in a variety of ways. All of this greatly
complicates
an already se
On 04/13/2013 09:24 AM, Chris Little wrote:
On 4/12/2013 3:31 AM, Peter von Kaehne wrote:
Having said this, I think if there is a large number of existing modules
which get insufficiently rendered and if the patch required is small,
then I would suggest a two pronged approach:
1) accept the pa
On 04/13/2013 09:24 AM, Chris Little wrote:
On 4/12/2013 6:58 AM, Greg Hellings wrote:
On Fri, Apr 12, 2013 at 6:57 AM, John Austin
mailto:gpl.programs.i...@gmail.com>> wrote:
You didn't address my main point: Content providers should be given
a way to have final control over how t
On 4/12/2013 12:12 PM, DM Smith wrote:
Regarding paragraph formats, the element does not define any.
There is no notion of "justified", "indented", "line-spacing",
"centering", that most word processors provide. These have to
use the type/subType attribute extension. And as you noted, SWORD
On 04/13/2013 07:34 AM, Greg Hellings wrote:
On Fri, Apr 12, 2013 at 4:37 PM, Matěj Cepl mailto:mc...@redhat.com>> wrote:
My point was that documents are more valuable and more difficult to
change than programs. So we should orient on perfecting documents
and change programs if
On 4/12/2013 11:18 AM, John Austin wrote:
On 04/12/2013 07:45 PM, Chris Little wrote:
I've worked with many, many SFM texts, and they often do not follow SFM
rules or play nice in a variety of ways. All of this greatly complicates
an already serious conversion from SFM to Sword. The proof m
On 4/12/2013 6:58 AM, Greg Hellings wrote:
On Fri, Apr 12, 2013 at 6:57 AM, John Austin
mailto:gpl.programs.i...@gmail.com>> wrote:
You didn't address my main point: Content providers should be given
a way to have final control over how their formatted texts appear,
and one which
On 4/12/2013 3:31 AM, Peter von Kaehne wrote:
Having said this, I think if there is a large number of existing modules
which get insufficiently rendered and if the patch required is small,
then I would suggest a two pronged approach:
1) accept the patch (us)
2) Do not accept anymore modules requi
On 04/13/2013 02:35 AM, Matěj Cepl wrote:
I am sorry, if I am too harsh, but it seems that the SWORD project is
already slipping on this dangerous slippery path towards making its
products useless for its intended purpose (long time record of the
Biblical texts for any possible purpose), so I wan
On Fri, Apr 12, 2013 at 4:37 PM, Matěj Cepl wrote:
> My point was that documents are more valuable and more difficult to change
> than programs. So we should orient on perfecting documents and change
> programs if necessary. And yes, possibility of using stylesheets would be
> awesome, but that i
Hi Mike,
Thanks for the link and the info.
On Apr 12, 2013, at 5:44:59PM, Mike Hart wrote:
> The KJV1611 needs to be experienced as it was originally laid out to be fully
> understood how different it is from the "King George" version of the "King
> James Bible" It included Paragraphs ( marke
The KJV1611 needs to be experienced as it was originally laid out to be fully
understood how different it is from the "King George" version of the "King
James Bible" It included Paragraphs ( marked with capitulums ¢), Sections
(listed at the start of each Chapter), and Topical page headers, as w
On 12/04/13 22:18, Greg Hellings wrote:
This is a (debate-ably) good theory.
Sword applications don't allow a module creator to specify a stylesheet,
and those which allow users to specify stylesheets are a world of hurt
because the older code in the Sword filters is not very stylesheet
friendly
On 12/04/13 20:18, John Austin wrote:
All the control that was asked for is a reliable and easy milestone
indent and a line break. That is totally doable by Sword. These alone
would offer many publishers, including IBT, all the control they need.
Yes, it is completely doable by Sword, and I abs
On 12/04/13 16:03, Chris Little wrote:
So... assuming we do not immediately and broadly implement my suggestion
of indenting all paragraphs, we could copy the x-indent attribute that
David notes is used in the ESV.
I would argue just opposite ... ESV text is broken, and we should
immediately r
On 12/04/13 13:57, John Austin wrote:
You didn't address my main point: Content providers should be given
a way to have final control over how their formatted texts appear,
and one which is simple and reliable.
If they want to do so, they should use different format than OSIS or any
other hones
On Fri, Apr 12, 2013 at 3:14 PM, Matěj Cepl wrote:
> On 12/04/13 08:04, John Austin wrote:
>
>> Sword should support basic indents and line breaks. Content providers
>> should be able to control the formatting of their texts and should not
>> be required to assign their content to artificial ...
On 12/04/13 08:04, John Austin wrote:
Sword should support basic indents and line breaks. Content providers
should be able to control the formatting of their texts and should not
be required to assign their content to artificial ... or other
containers to do so. Although these containers might be
I think there are bigger problems to solve first. I think Troy alluded to this
in his response that there is a need to fix the whitespace problem. I think
this causes most of the differences you see when rendering in most SWORD
frontends.
The whitespace problem is exacerbated in that osis2mod t
On 04/12/2013 07:45 PM, Chris Little wrote:
On 4/12/2013 4:57 AM, John Austin wrote:
You didn't address my main point: Content providers should be given a
way to have final control over how their formatted texts appear, and one
which is simple and reliable. I'll comment below, but a Bible
tran
The ESV encoding into OSIS tried to retain the markup of the source. In the
case of x-indent and x-indent-2, these are attributes on the element. These
should have been level="2" and level="3". In the next release of the ESV SWORD
module, it is corrected.
I have a little bit more before it is
On 4/12/2013 6:01 AM, Troy A. Griffitts wrote:
Can the people involved in this discussion suggest the desired OSIS
encoding for your example, and the desired XHTML output from this OSIS
through the osisxhtml filters, and I will place this into our testsuite
OSIS document and add a test to be sure
On Fri, Apr 12, 2013 at 6:57 AM, John Austin wrote:
> You didn't address my main point: Content providers should be given a way
> to have final control over how their formatted texts appear, and one which
> is simple and reliable. I'll comment below, but a Bible translation is not
> a web-page or
On 4/12/2013 4:57 AM, John Austin wrote:
You didn't address my main point: Content providers should be given a
way to have final control over how their formatted texts appear, and one
which is simple and reliable. I'll comment below, but a Bible
translation is not a web-page or an app which might
Dear John,
I certainly want to provide what is necessary to satisfy ministry needs.
Having said this, I want to be sure you understand why the push-back.
This statement is not well defined or reasonable:
"This is exactly how I want the formatting, everywhere, any time. Period."
Really? You re
It's notable that the ESV module includes these OSIS tags for indentation:
11334 x-indent
00021 x-indent-2
The question arises therefore, do we support these two eXtensions?
If not, then we are falling short of satisfying the publishers of the ESV.
If yes, then there should be no objection t
You didn't address my main point: Content providers should be given a
way to have final control over how their formatted texts appear, and one
which is simple and reliable. I'll comment below, but a Bible
translation is not a web-page or an app which might need a new look
someday, or a new skin
I'd forgotten about \m
*\m(_text...)*
· Flush left (margin) paragraph.
· No first line indent.
· Followed immediately by a space and paragraph text, or by a new line and a
verse marker.
· Usually used to resume prose at the margin (without indent) after poetry
or OT quotation (i.e. continuatio
Having said this, I think if there is a large number of existing modules which get insufficiently rendered and if the patch required is small, then I would suggest a two pronged approach:
1) accept the patch (us)
2) Do not accept anymore modules requiring this patch (IBT)
3) Once the last m
On 4/12/2013 3:13 AM, Peter von Kaehne wrote:
My only disagreement with Chris is around this sentence:
>(Again, I would argue that all paragraphs should be indented
I think this is an Americanism. Here paragraphs are usually skipped.
It can vary by genre, but I think if we limit ourselves to p
My only disagreement with Chris is around this sentence:
>(Again, I would argue that all paragraphs should be indented
I think this is an Americanism. Here paragraphs are usually skipped.
Gesendet: Freitag, 12. April 2013 um 11:26 Uhr
Von: "Chris Little"
An: "SWORD Developers' Collabor
Executive summary:
I don't have a problem with making it clear how to encode indented
paragraphs and line breaks and improving support for diverse paragraph
types.
I do have problems with the specific syntax and the rationale described
below.
On 4/11/2013 11:04 PM, John Austin wrote:
Sword sh
I agree with all the points that John makes; these things do require adequate
support in SWORD.
I wish to make one additional observation from my reading of the USFM
Reference and email discussions with Studge,
as well as seeing how things are in the real world of USFM files for many
projects.
Fo
33 matches
Mail list logo
