<html><head/><body><html><head></head><body>John,<br>
<br>
I&#39;m trying to sympathize with you, but I&#39;m having a hard time. I still have no clue WHAT the translator is trying to convey to the reader with the indent. Can you explain?<br>
<br>
<br><br><div class="gmail_quote">John Austin &lt;<a href="http://gpl.programs.info">gpl.programs.info</a>@gmail.com&gt; wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif; margin-top: 0px"><br /><br />On 04/13/2013 09:24 AM, Chris Little wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">On 4/12/2013 11:18 AM, John Austin wrote:<br /><br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">On 04/12/2013 07:45 PM, Chris Little wrote:<br /><br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;">I've worked with many, many SFM texts, and they often do not follow SFM<br />rules or play nice in a variety of ways. All of this greatly<br />complicates<br />an already serious conversion from SFM to Sword. The proof may in the<br />the pudding. Simple is sometimes better in the real world. Sure, IBT<br />could recreate their modules using container elements, but that still<br />would not provide the reliability or control enjoyed by the existing<br />modules. I still don't see (beyond theory and arguable semantics) a<br />good<br />reason to deny "customers" a sound and working solution.</blockquote><br />As a rule, we don't do things incorrectly when we know that they are<br />wrong beforehand. Indent milestones are arbitrary, ad hoc, bad<br />engineering practice, and bad markup practice. Generating &amp;nbsp;s as<br />pretend paragraph indentation is bad (X)HTML and completely inflexible.<br />(What happens when a content provider wants a half indent? A hanging<br />indent?) The proposal is a big kludge. We should instead implement the<br />correct method of generating indented and other paragraph types.<br /></blockquote>They work perfectly well. They validate against the OSIS schema. They<br />are good engineering practice because they solve a difficult problem<br />without negative effects of any kind. We can argue about bad markup etc.<br />but some grace should be given to an approach that is proven and<br />perfectly valid, which already exists in practice, and which has solved<br />a nagging real life problem.</blockquote><br />They don't work perfectly well.<br /><br />In terms of representation, the milestones represent something that<br />isn't there and should instead be a property of something that actually<br />is there.<br /><br />In terms of the formatted output (the (X)HTML), you're emitting<br />something extremely bad. You want indentation, which is a formatting<br />matter. To achieve your intended formatting you are corrupting the<br />character data stream by inserting NBSPs to cause a side effect:<br />horizontal spacing. If you want to change horizontal position, you<br />should do so through one of the established methods, not as a side<br />effect of inserting characters that have different semantics.<br /><br />Consider this: When you copy &amp; paste text from a front end or webpage,<br />should the indentation be copied as a bunch of NBSPs? Hopefully you<br />agree it should not. The NBSPs are noise that has been inserted into the<br />character stream. (If you try this on the PDF you linked and the<br />rendering by phpsword, you can see that they behave differently when you<br />copy text and paste it into a word processor or text editor. That's<br />because the PDF does formatting correctly using PDF layout methods, but<br />phpsword relies on a side effect.)</blockquote><br />The issue is not how the indent is implemented by the engine. It is the <br />acceptance of these translator dictated elements as valid milestone <br />content in the OSIS file, and Sword recognizing and implementing these <br />indents as indents.<br /><br /><br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">Actually, the line I copied above is the whole "paragraph"- it is not a<br />multi-line anything. See<br /><a href="http://ibt.org.ru/en/text.htm?m=UZVL&amp;l=Ruth.1.15&amp;g=0">http://ibt.org.ru/en/text.htm?m=UZVL&amp;l=Ruth.1.15&amp;g=0</a> for the real<br />location of this example. These two words are not a paragraph in<br />anyone's book, and to call this a paragraph, as you insist that I must<br />do to use Sword, is in my book: "arbitrary, ad hoc, bad engineering<br />practice, and bad markup practice", and just wrong. Let publishers<br />decide what it is and what it will look like- users of Sword will all be<br />glad!</blockquote><br />Abstractly, it's multi-line. Some (most?) of these paragraphs are<br />multi-line. Even your two word example would be multi-line with a<br />sufficiently narrow column. These paragraphs break in exactly the same<br />way as other paragraphs.<br /><br />I still can't see the argument for these not being paragraphs. I would<br />accept that they could be a different type of paragraph from the type<br />that starts at the start of a sentence, but they are clearly paragraphs.<br />Paragraphs with hanging indents are markedly more different than these,<br />but they're still paragraphs.</blockquote><br />I still can't see the argument for requiring that everyone call these <br />questionable instances paragraphs, and require that they must always be <br />marked up as such. Why not give the publisher the option of calling it a <br />paragraph if they consider it a paragraph, or else calling it an indent <br />if they think it will be more correctly understood as an indent? For <br />instance, many people consider that a paragraph should be followed by a <br />blank line (between paragraphs). What if I desire that this indented <br />line in my translation should never have a blank line after it, and that <br />it is an actual indent which is the content I intend to add- in order to <br />make my text more understandable? Then I should be able to call it an <br />indent. I would be very correct in doing so. Future readers of my OSIS <br />file would also unambiguously understand my intentions as well.<br /><br /><br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">--Chris<br /><br /><br /><br /><hr /><br />sword-devel mailing list: sword-devel@crosswire.org<br /><a href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br />Instructions to unsubscribe/change your settings at above page</blockquote><br /><hr /><br />sword-devel mailing list: sword-devel@crosswire.org<br /><a href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br />Instructions to unsubscribe/change your settings at above page<br /></pre></blockquote></div><br>
-- <br>
Sent from my Android phone with K-9 Mail. Please excuse my brevity.</body></html></body></html>