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.

_______________________________________________ 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

Reply via email to