[sword-devel] Sword support of indents and line breaks
gpl.programs.info at gmail.com
Fri Apr 12 11:18:48 MST 2013
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
To demonstrate how well this exact same passage renders with parallel
texts on a small screen, visit this link on a smart phone:
>> 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
>> 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
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
> 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.
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel