This has evolved a bit from the original question: should the engine
provide direct support for n="X" footnote markers.
The answer to that was yes and it was implemented as an optional
change.
We've digressed into several distinct discussions. Here are my comments
on them:
1) What is the importance of what the desires of the publisher and
whether that can be known.
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.
2) Separation of structure and presentation.
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.
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.
I really don't like when a publisher works toward a single frontend as
it may use features that only work for that frontend.
3) Needs/weaknesses of the frontends. E.g. font.
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.
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.
In Him,
DM
On Feb 12, 2012, at 7:34 AM, Jonathan Morgan wrote:
Hi,
On Sun, Feb 12, 2012 at 10:16 PM, Peter von Kaehne<ref...@gmx.net>
wrote:
On 12/02/12 04:27, Greg Hellings wrote:
Still more of it was very
important for display - selection of different fonts for Greek vs
Hebrew vs Aramaic displays.
I do not follow the general discussion very much - but this really
got
my notice.
I think the current Font item in the configuration file is a bit of a
cludge - it does not work when a font is not actually present, it can
not deal with font families, alternatives etc and it certainly can
not
provide a selection for multiscripture texts.
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.
Jon
So, Greg is right here. And you Troy are wrong. Said with the same
love
present in your last email :-)
Whether the solution is style sheets or something else, I do not
care,
but to my mind, given that we moved all to immensely capable
rendering
engines and use only a single digit percentage of their ability, I
think
a move to support per module CSS would not be exactly a big thing.
Certainly not if we restrict its use to something which can be
expected
to have universal support across all our frontends (leaving BibleCS
and
its RTF rendering out of the equation.
I personally would find it hard to have pink headlines and turquoise
coloured backgrounds because a girly module maker thought this would
be
nice, but structural stuff - fonts particularly - need to improve and
could easily be improved.
Peter
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
