[sword-devel] lang processing

[Peter von Kaehne]

Just for historical accuracy - the Font property is my doing - it came
in with the Persian Bibles about 7 years ago, via Xiphos or BibleDesktop

Mea culpa.

Peter


On 12/02/12 16:19, 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
>