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: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
