[sword-devel] New Accented Greek NT with Morph

DM Smith dmsmith555 at yahoo.com
Sat Apr 23 08:25:28 MST 2005


With regard to fonts, my comments are with regard to how they render in 
Java. The quality of Latin in Gentium is not on par with other fonts. 
And certainly not of the same quality as Greek glyphs. Anti-aliasing 
does not help significantly, but makes the Greek look gorgeous. The font 
may be good for Latin outside of Java.

The problem with Galatia SIL is that it simply does not work in Java. 
Nothing is rendered. I have not looked into it any further. It might be 
how we use fonts in Java.

With regard to directionality, I have a specific problem in mind. When 
displaying WLC the Hebrew text should be from right to left and right 
justified. Any embedded left to right should display from left to right 
and in the flow of Hebrew should be right justified. However, if an 
English note is displayed outside of that flow (say in a separate cell 
of a table, which is where JSword places notes) then that flow should be 
left to right and right justified. The bidi algorithm in and of itself 
only allows for a dominate flow. If we had either xml:lang or script on 
the note elements then that would work well. It is this that renders 
should use to determine directionality.

The problem of using ICU at runtime for script detection is that it 
would create a need to analyze every element and its content. (One could 
limit it to notes, but this is not the ideal.) This would be better to 
handle offline while building a module. Also, if a single English note 
consists of very little English and mostly Hebrew, would ICU correctly 
identify the script? (probably not). I think that English notes in a 
Hebrew Bible are a feature of that Bible and should be noted (pun 
intended) as such.

Personally, I think that <milestone> with x- types should generally be 
avoided, unless they are standardized by Sword or OSIS. Also, OSIS is 
removing milestone begin and milestone end. I don't think we should use 
them for that purpose. Using them for a state change is using them as 
implicit begin/end markers. My selfish perspective is that milestones 
that represent a state change in the flow of a document are difficult to 
handle in XSLT. (Milestones that are truly point in document events, 
that don't mark the beginning or end, implicitly or explicitly, are not 
a problem.)


Chris Little wrote:

> DM Smith wrote:
>
>> Martin Gruner wrote:
>>
>>>>     If you have a chance, could you please spend some time trying this
>>>> link with your browser and report your results and configuration AND
>>>> ANYTHING YOU DO (with fonts or otherwise) that improves your 
>>>> viewing of
>>>> the accented Bibles.
>>>>   
>>>
>>> Hi,
>>>
>>> I tried this in Kate (based on QT 3, as Konqueror) and OpenOffice 
>>> (based on libfreetype2). Both give similar results: Precomposed is 
>>> perfect, decomposed displays ok (no boxes), but some accents are not 
>>> visible or moved (such as the iota subscriptum, which is no real 
>>> accent).
>>>
>>> So I’d suggest to stay with the recommendation to use precomposed, 
>>> and perhaps offer a filter to decompose (ICU) for people needing it, 
>>> that could also be activated on the website.
>>>
>>> Most important is using the right font. My recommendations: Gentium 
>>> is good, but FreeFont (FreeSerif) is best.
>>>
>> I agree that Gentium is good if only Greek is being shown. If notes 
>> are added to the module (e.g. for the variants) then Gentium is not a 
>> good choice for displaying the notes. We cannot simply use a 
>> different font for notes because some notes may contain more than one 
>> language, e.g. English with Greek.
>
> What's wrong with Gentium? I think it has a very attractive set of 
> Latin glyphs. There's also Galatia SIL (which has full Greek support 
> and an attractive, Times-style Latin range).
>
>> I'm not sure if OSIS has a mechanism to mark the "lang" for elements 
>> and whether the language of individual words/phrases can be marked, 
>> without changing the flow (i.e. need a span like element such as w). 
>> If we had this then it would be possible to use fonts on a per 
>> language basis in a module.
>
> Almost all elements permit xml:lang. There is also <foreign>, intended 
> for short strings of foreign language text (relative to the rest of 
> the text).
>
> Perhaps more appropriate would be the script attribute (which has the 
> same distribution as xml:lang). Valid script codes come from ISO 15924 
> (see http://www.unicode.org/iso15924/iso15924-codes.html).
>
> Something we could do is mark each change in script with a tag like 
> <milestone type="x-scriptChange" script="Latn"/>. We can even 
> (potentially) do something like this at runtime since ICU has script 
> detection.
>
>> On a related note, in WLC the module is rtl but the notes should be 
>> ltr, since they are in English. However, the notes do not indicate 
>> their directionality. I don't think it is fair to assume that all 
>> notes will be in English. They could have been in Hebrew.
>
> Directionality is something that DEFINITELY should be handled in the 
> renderer. It is a property of each codepoint that needs to be handled 
> correctly by any reasonable renderer. As such, no attempt to mark 
> directionality should be made (and I don't think any facility has been 
> provided in OSIS to do so).
>
> We do still mark LtR/RtL in module .conf files, but only for the 
> purpose of signaling to the front-end that it needs to render verse 
> numbers to the right of the verse rather than the left and things like 
> that.



More information about the sword-devel mailing list