Hi Troy,<br><br><div class="gmail_quote">On Mon, Feb 13, 2012 at 3:19 AM, <a href="mailto:scribe777@gmail.com">scribe777@gmail.com</a> <span dir="ltr"><<a href="mailto:scribe@crosswire.org">scribe@crosswire.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for delineating the discussion, DM.<br>
<br>
I would certainly be in favor of discussing the possible enhancement to our filters (or import tools) for providing language span tags around segments of language text not included in the default module language unicode plane, per the BPBible team's suggestion and possibly their code :)<br>

</blockquote><div><br>The code is Python, so it might not be so easy for you to use.  And all it's doing is regular expression replacement for ranges of characters, along the lines of:<br>greek = u'\u0370-\u03e1\u03f0-\u03ff\u1f00-\u1fff'<br>

hebrew = u'\u0590-\u05ff\ufb1d-\ufb4f'<br><br>Jon<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
And I know you guys enjoy proclaiming me wrong (Peter), but I can't remember recently defending the font= property in the .conf files. This was useful 20 years ago when it was added, before our non-English Bibles became unicode encoded. :)  But certainly isn't ideal now. It's still a fine convention if a user or module author wishes to specify a preferred default module font, so I'm not suggesting we remove it, but it certainly doesn't handle per-language font suggestions in its current incarnation.<br>


<br>
Troy<br>
<br>
<br>
<br>
DM Smith <<a href="mailto:dmsmith@crosswire.org">dmsmith@crosswire.org</a>> wrote:<br>
<br>
>This has evolved a bit from the original question: should the engine<br>
>provide direct support for n="X" footnote markers.<br>
>The answer to that was yes and it was implemented as an optional<br>
>change.<br>
><br>
>We've digressed into several distinct discussions. Here are my comments<br>
>on them:<br>
>1) What is the importance of what the desires of the publisher and<br>
>whether that can be known.<br>
>Regarding footnote markers, JSword's frontends use the value of the n<br>
>attribute when present because the footnotes are rendered on the screen<br>
>as margin notes. If the n attribute is not present we generate a unique<br>
>value for each one on the page. It fits well with desktop applications,<br>
>but not perhaps when the notes are not present in the user's view such<br>
>as on a phone.<br>
><br>
>2) Separation of structure and presentation.<br>
>I think we have agreed in the past that these should continue be<br>
>separate. What we have not come to agreement on is how to allow for a<br>
>"publisher" to provide for rich presentation. We have noted that using<br>
>class attributes in the render filters would enable such a future, but<br>
>no one has stepped up to doing it.<br>
><br>
>But the landscape of the device (size, dimension and resolution of the<br>
>viewport/screen/window/frame) is a crucial part of any presentation and<br>
>it precludes a one size fits all presentation style.<br>
><br>
>I really don't like when a publisher works toward a single frontend as<br>
>it may use features that only work for that frontend.<br>
><br>
>3) Needs/weaknesses of the frontends. E.g. font.<br>
>I'm wondering whether it makes sense for CrossWire to host the fonts<br>
>that are specified in the modules it hosts and SWORD be modified to<br>
>download such a font on demand. That is it'd be a feature of a<br>
>repository.<br>
><br>
>Regarding lang="XX" it (the two letter code) works well for languages<br>
>that only have one script, such as English, Greek and Hebrew. But not<br>
>for those that have multiple scripts. It needs to be extended to<br>
>include script. I think that the multi-language modules should<br>
>copiously specify the language/script of the elements. Osis2mod should<br>
>be modified to push these down into the verse entries if needed.<br>
>Likewise for gen books and dictionary module makers.<br>
><br>
>In Him,<br>
>       DM<br>
><br>
>On Feb 12, 2012, at 7:34 AM, Jonathan Morgan wrote:<br>
><br>
>> Hi,<br>
>><br>
>> On Sun, Feb 12, 2012 at 10:16 PM, Peter von Kaehne <<a href="mailto:refdoc@gmx.net">refdoc@gmx.net</a>><br>
>wrote:<br>
>> On 12/02/12 04:27, Greg Hellings wrote:<br>
>> > Still more of it was very<br>
>> > important for display - selection of different fonts for Greek vs<br>
>> > Hebrew vs Aramaic displays.<br>
>> I do not follow the general discussion very much - but this really<br>
>got<br>
>> my notice.<br>
>><br>
>> I think the current Font item in the configuration file is a bit of a<br>
>> cludge - it does not work when a font is not actually present, it can<br>
>> not deal with font families, alternatives etc and it certainly can<br>
>not<br>
>> provide a selection for multiscripture texts.<br>
>><br>
>> FWIW, the way BPBible does it is to scan through a text, identify all<br>
>Hebrew/Greek text, and wrap them in additional spans like <span<br>
>lang="he">.  It will then use the font specified by the user for that<br>
>particular language.  Due to the implementation, this would probably<br>
>end up with a more specific rule than anything in the CSS, which may be<br>
>a drawback (especially since the default will probably be the default<br>
>font for the entire application).  However, it does mean that the user<br>
>is (at least in theory) in control of which font is used for which<br>
>language, rather than the module, so if module creator explicitly picks<br>
>font X because it has good Hebrew support but user prefers font Y for<br>
>Hebrew they get font Y.  And it does mean even in a principally English<br>
>book Hebrew/Greek text in it can be displayed in a different font<br>
>without any work from the module creator.<br>
>><br>
>> Jon<br>
>><br>
>> So, Greg is right here. And you Troy are wrong. Said with the same<br>
>love<br>
>> present in your last email :-)<br>
>><br>
>> Whether the solution is style sheets or something else, I do not<br>
>care,<br>
>> but to my mind, given that we moved all to immensely capable<br>
>rendering<br>
>> engines and use only a single digit percentage of their ability, I<br>
>think<br>
>> a move to support per module CSS would not be exactly a big thing.<br>
>><br>
>> Certainly not if we restrict its use to something which can be<br>
>expected<br>
>> to have universal support across all our frontends (leaving BibleCS<br>
>and<br>
>> its RTF rendering out of the equation.<br>
>><br>
>> I personally would find it hard to have pink headlines and turquoise<br>
>> coloured backgrounds because a girly module maker thought this would<br>
>be<br>
>> nice, but structural stuff - fonts particularly - need to improve and<br>
>> could easily be improved.<br>
>><br>
>> Peter<br>
>><br>
>><br>
>> _______________________________________________<br>
>> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
>> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
>> Instructions to unsubscribe/change your settings at above page<br>
>><br>
>> _______________________________________________<br>
>> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
>> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
>> Instructions to unsubscribe/change your settings at above page<br>
><br>
>_______________________________________________<br>
>sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
><a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
>Instructions to unsubscribe/change your settings at above page<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Sent from my Android phone with K-9 Mail. Please excuse my brevity.<br>
<br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</font></span></blockquote></div><br>