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

[Chris Little]

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.

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.

> 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.

> 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.

> 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 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.

--Chris