[sword-devel] lang processing

Sun Feb 12 11:41:59 MST 2012

Some form of font instructions is beneficial for certain languages to 
make life easier for non-power users and other situations. The first 
scenario is obvious—most people would like Hebrew or Greek or whatever 
to display correctly right out of the box. Incidentally, I had a 
colleague email me the other day about disabling Hebrew vowel pointing 
in BibleTime. The way to do that is easy, but he just didn't think to 
click on the proper icon. Font settings are usually slightly more 
buried, so it would be great if modules could specify and install a font 
with the module.

I can also envision another scenario, that is, when a front-end does not 
give the option of configuring fonts. I was getting used to AndBible 
recently and discovered that the SBLGNT module specified a font and 
included it somehow. I hacked the OSMHB conf file to specify SBL Hebrew, 
and it displays more reasonably now (minus vowel pointing, unfortunately).

This is one way a module creator can encourage a positive reception of a 
module and the SWORD front-end. It is an enhancement for the sake of the 
user experience.

Daniel

On 02/12/2012 10:19 AM, scribe777 at gmail.com wrote:
> Thanks for delineating the discussion, DM.
>
> 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 :)
>
> 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.
>
> Troy
>
>
>
> DM Smith<dmsmith at crosswire.org>  wrote:
>
>> 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<refdoc at 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 at 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 at 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 at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page