<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">This has evolved a bit from the original question: should the engine provide direct support for n="X" footnote markers.<div>The answer to that was yes and it was implemented as an optional change.</div><div><br></div><div>We've digressed into several distinct discussions. Here are my comments on them:</div><div>1) What is the importance of what the desires of the publisher and whether that can be known.</div><div>Regarding footnote markers, JSword's frontends use the value of the n attribute when present because the footnotes are rendered on the screen as margin notes. If the n attribute is not present we generate a unique value for each one on the page. It fits well with desktop applications, but not perhaps when the notes are not present in the user's view such as on a phone.</div><div><br></div><div>2) Separation of structure and presentation.</div><div>I think we have agreed in the past that these should continue be separate. What we have not come to agreement on is how to allow for a "publisher" to provide for rich presentation. We have noted that using class attributes in the render filters would enable such a future, but no one has stepped up to doing it.</div><div><br></div><div>But the landscape of the device (size, dimension and resolution of the viewport/screen/window/frame) is a crucial part of any presentation and it precludes a one size fits all presentation style.</div><div><br></div><div>I really don't like when a publisher works toward a single frontend as it may use features that only work for that frontend.</div><div><br></div><div>3) Needs/weaknesses of the frontends. E.g. font.</div><div>I'm wondering whether it makes sense for CrossWire to host the fonts that are specified in the modules it hosts and SWORD be modified to download such a font on demand. That is it'd be a feature of a repository.</div><div><br></div><div>Regarding lang="XX" it (the two letter code) works well for languages that only have one script, such as English, Greek and Hebrew. But not for those that have multiple scripts. It needs to be extended to include script. I think that the multi-language modules should copiously specify the language/script of the elements. Osis2mod should be modified to push these down into the verse entries if needed. Likewise for gen books and dictionary module makers.</div><div><br></div><div>In Him,</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>DM</div><div><br><div><div>On Feb 12, 2012, at 7:34 AM, Jonathan Morgan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi,<br><br><div class="gmail_quote">On Sun, Feb 12, 2012 at 10:16 PM, Peter von Kaehne <span dir="ltr"><<a href="mailto:refdoc@gmx.net">refdoc@gmx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">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>
</div>I do not follow the general discussion very much - but this really 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 not<br>
provide a selection for multiscripture texts.<br></blockquote><div><br>FWIW, the way BPBible does it is to scan through a text, identify all Hebrew/Greek text, and wrap them in additional spans like <span lang="he">. It will then use the font specified by the user for that particular language. Due to the implementation, this would probably end up with a more specific rule than anything in the CSS, which may be a drawback (especially since the default will probably be the default font for the entire application). However, it does mean that the user is (at least in theory) in control of which font is used for which language, rather than the module, so if module creator explicitly picks font X because it has good Hebrew support but user prefers font Y for Hebrew they get font Y. And it does mean even in a principally English book Hebrew/Greek text in it can be displayed in a different font without any work from the module creator.<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">
So, Greg is right here. And you Troy are wrong. Said with the same love<br>
present in your last email :-)<br>
<br>
Whether the solution is style sheets or something else, I do not care,<br>
but to my mind, given that we moved all to immensely capable rendering<br>
engines and use only a single digit percentage of their ability, I 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 expected<br>
to have universal support across all our frontends (leaving BibleCS 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 be<br>
nice, but structural stuff - fonts particularly - need to improve and<br>
could easily be improved.<br>
<span class="HOEnZb"><font color="#888888"><br>
Peter<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><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">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>Instructions to unsubscribe/change your settings at above page</blockquote></div><br></div></body></html>