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

[John Austin]

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
>> translation is not a web-page or an app which might need a new look
>> someday, or a new skin. CSS and content abstraction etc. are great
>> ideas, but they should not be artificially forced onto Bible publishers.
>> Yes, they should be offered, and even encouraged- fine. But publishers
>> should be able to say: "This is exactly how I want the formatting,
>> everywhere, any time. Period." I don't understand why this expectation
>> is so abhorrent. Offering a handful of content abstractions and
>> extensions, all of whose definitions are arguable (see below) and likely
>> in flux, is neither simple, nor satisfying to content providers who
>> desire control over the presentation of their texts.
>
> No one is ever going to get any kind of reliable control over how
> formatted texts appear. Period. If you have a problem with that, go use
> LaTeX or Word and generate PDFs.
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.

>
> If you want to use Sword, rendering of your documents will always be
> subject to variations between platforms, front ends, and rendering
> engines. If you want to use Sword, you'll have to encode documents
> semantically, not with imaginary indentation objects.
Sword is owned by "we the people" since it's Open Source. But that's one 
of its strengths, and I'm very grateful that it's been available and 
that there are many who work hard at making it better. IBT is using 
milestone indents right now which work excellent. Milestone indents 
render with good fidelity even with complex formatted text: compare 
http://ibt.org.ru/en/text.htm?m=UZVL&l=Mark&g=0 and 
http://ibt.org.ru/russian/bible/uzb/ntcyr/41%20Mrk%20-%20Uzbek%20Cyrillic.pdf. 
To demonstrate how well this exact same passage renders with parallel 
texts on a small screen, visit this link on a smart phone: 
ibt.org.ru/en/text.htm?m1=UZVL&m2=KJV&l=Mark&g=0.

>
>> 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 may in the
>> the pudding. Simple is sometimes better in the real world. Sure, IBT
>> could recreate their modules using container elements, but that still
>> would not provide the reliability or control enjoyed by the existing
>> modules. I still don't see (beyond theory and arguable semantics) a good
>> reason to deny "customers" a sound and working solution.
>
> As a rule, we don't do things incorrectly when we know that they are
> wrong beforehand. Indent milestones are arbitrary, ad hoc, bad
> engineering practice, and bad markup practice. Generating  s as
> pretend paragraph indentation is bad (X)HTML and completely inflexible.
> (What happens when a content provider wants a half indent? A hanging
> indent?) The proposal is a big kludge. We should instead implement the
> correct method of generating indented and other paragraph types.
They work perfectly well. They validate against the OSIS schema. They 
are good engineering practice because they solve a difficult problem 
without negative effects of any kind. We can argue about bad markup etc. 
but some grace should be given to an approach that is proven and 
perfectly valid, which already exists in practice, and which has solved 
a nagging real life problem.

>
>> Something like "     Бўаз Рутга:" is not clearly a <p> even though that
>> is how at appears in SFM, and that is how it would appear in the module
>> according to your argument. For instance, if some front-end designer
>> thinks it is really neat for his front-end's paragraphs to have
>> drop-caps and so he modifies his CSS to add them to "paragraphs"- Then
>> my text is completely broke because, in fact the above is NOT a
>> paragraph, in any language. It is, in fact, an indented line.
>
> Well, it's not an indented line, it's an indented multi-line block
> element--aka a paragraph. Not all paragraphs need necessarily be treated
> identically. I've never heard of using drop caps on every paragraph, but
> if someone hypothetically desired to render most paragraphs with
> drop-caps but desired to render paragraphs that begin sentence-medially
> without drop-caps, they could in theory give them different
> types/classes and treat the two varieties differently.
Actually, the line I copied above is the whole "paragraph"- it is not a 
multi-line anything. See 
http://ibt.org.ru/en/text.htm?m=UZVL&l=Ruth.1.15&g=0 for the real 
location of this example. These two words are not a paragraph in 
anyone's book, and to call this a paragraph, as you insist that I must 
do to use Sword, is in my book: "arbitrary, ad hoc, bad engineering 
practice, and bad markup practice", and just wrong. Let publishers 
decide what it is and what it will look like- users of Sword will all be 
glad!

>
>> There is a demonstrated need for an indent, and a good implementation.
>> Where is the serious argument for why Sword should deny support for that?
>
> I would say that is begs the question. I don't think anyone who didn't
> already believe that indented paragraphs should be an option to encoders
> will have been convinced by this discussion. It certainly has not been
> demonstrated that indentation objects are a reasonable solution to the
> problem.
I have posted some links above on this page to demonstrate how well this 
works in reality.

>
>>> I presume you're already happy with the handling of <lb/>.
>> Assuming they always render (when formatting is desired of course) as
>> basic line breaks, and NOT as blank lines (similar to <br> in html) then
>> yes.
>
> The OSIS to XHTML filter generates one <br/> from one <lb/>.
>
>> Again, they are not paragraphs as most would understand them. Because if
>> they inherited any typical "paragraph" formatting, other than the
>> indent, they would render completely wrong. The fact that there is
>> serious discussion about whether they are paragraphs or not makes the
>> importance of point #1 clear as day: The content provider needs a simple
>> way to have control over their formatting. Now, forever, period.
>
> In the PDF and the HTML versions of the text you linked, they look
> exactly like paragraphs to me. As far as I can see, you use exactly the
> same HTML markup for paragraphs and the purported non-paragraphs. I'm
> unclear what "typical 'paragraph' formatting' they are failing to inherit.
They were just showing how well the PDF and the milestone indented Sword 
texts do correlate, that's all. I should mention that this scheme is 
currently being used in xulsword and phpsword to display interlinear 
layouts, parallel text layouts, un-formatted text popups, verse lists, 
you name it, all of Sword's good stuff... It always works. Xulsword's 
filter is essentially the base osisxhtml.cpp filter of Sword, with a 
single extra line of code to handle milestone indents! It's not some 
kind of fancy integrated system. It just works.

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