Lithuanian localization

Tofu Type Foundry · October 2

Whilst admiring John’s Brill fonts the other day, I noticed it has Lithuanian localization. The Lithuanian alphabet doesn’t include Ì ì (igrave) so is this feature used to support “accentuation”?

John Savard · October 2

I followed your link, and I saw that when Lithuanian localization is turned on, "igrave" becomes a lowercase "i" with the grave accent appearing over the dot.

Although originally I didn't understand your question, this caused me to suspect that the answer is "yes".

EDIT: After reading the Wikipedia article on Lithuanian accentuation, which notes that the grave accent, along with the acute accent and some others, is used to mark tone and stress, I am more confident that this is indeed the purpose.

Tofu Type Foundry · October 2

Sorry, I forgot to include this screenshot showcasing the feature!

Image: https://us.v-cdn.net/5019405/uploads/editor/87/iwgtwci9t1sv.png

John Savard · October 2

On further reflection, since you knew what accentuation in Lithuanian was, in order to suspect that this is what the feature was for, it is clear my response was not helpful to you. I presume you're looking for an employee of Brill, or at least a native speaker of Lithuanian, to give you a hard, definitive answer to what this localization feature is for.

For the benefit of naïve readers of this thread, though, I will make some comments.

Lithuanian just has an ordinary I which has a dot when lowercase; it isn't like Turkish in this respect. And pinyin uses popular accent marks to indicate tone, but when they're used in this way, they replace the dot over the lowercase i just as they do when those marks are used as accents in other languages.

So why would users of Lithuanian feel the need to keep the dot above the lowercase i when adding a grave accent to indicate tone and/or stress?

For two reasons. Although Lithuanian doesn't use the grave accent as an accent, it does use other accented letters. And one mark it uses as an accent - but under the letter, rather than above - is a dot.

So it is at least reasonable to think that keeping the dot above the lowercase i when accentuation takes place is considered useful for avoiding confusion in printed Lithuanian texts.

Thomas Phinney · October 2

@John Savard in this case I think we can assume that “John” was intended to be a request to @John Hudson, the designer of the Brill types.

John Savard · October 2

I saw the reference to "John's Brill fonts", and I did not assume that it had anything to do with me.

However, I am able to provide a hard "yes" answer to the original poster's question. In "An Introduction to Modern Lithuanian", published in 1993, I found the phenomenon in question actually occurring in the wild:

So, yes, Lithuanians do feel the need to keep the dot on the i under accentuation.

Tofu Type Foundry · October 2

Correct, Thomas! I was hoping @John Hudson would confirm his intentions, as the main designer behind Brill, but also wanted the question to have a public forum. I always appreciate the insight and comments from others—such as @John Savard’s notes! Plus, designers with the same question can now reference this thread.

John Hudson · October 3

So this is a little complicated.

There is indeed a convention in Lithuanian typography that when accents are applied to the lowercase i, e.g. to mark stress in a dictionary, the dot is retained, unlike in most other languages. So this is indeed a behaviour that can be implemented at the glyph level using the Lithuanian langsys tag in an OpenType font and simply not including the contextual lookup used in the dflt and other langsys entries to remove the dot when followed by an above combining mark character. After discussing this with the editing and typesetting advisor at Brill, we decided to implement it in this way.

HOWEVER...

Someone (@Denis Moyogo Jacquerye? or maybe Roozbeh Pournader?) pointed out to me a while ago that Unicode advises a different approach, in which the retained dot should be hard encoded as U+0307 COMBINING DOT ABOVE. So, the example Lithuanian i with grave would actually be encoded as i (soft-dotted, with the dot supressed as in other languages) followed by a combining dot followed by a combining grave.

Frankly, that seems to me a terrible idea, not least because it means the Lithuanian diacritic cannot be searched for simply as a i+grave, which is what it is, semantically speaking.

Implementing this as in the Brill fonts seems to me a better idea, and well within the scope of the sort of language-specific glyph behaviour variation that the OpenType Layout langsys architecture was designed to enable. If someone were working in an environment without support for language-specific shaping, then hacking the encoding to achieve the desired appearance would be possible, but it doesn’t make sense to me that it should be the ‘correct’ approach.

Tofu Type Foundry · October 6

Ah, that’s very interesting John! I can see the Brill solution working well, especially since it removes the need for an additional combining mark. I wonder if most Lithuanians are used to using a standard /igrave (ì) now, due to most fonts not supporting Lithuanian localization, or if they still find the removal of the tittle jarring. Anyways, thanks for taking the time to explain your solution.

Denis Moyogo Jacquerye · October 6

We need to be extra careful with these kind of features.

This Lithuanian dictionary notation is used in linguistic works and hasn’t always been clear on what form (dotted or not) is preferred. @John Savard’s example actually doesn’t keep the dot in the rest of the book, plenty of 20th century works didn’t either.

Whether it’s "correct" or "better" or neither, the VLKK Lithuanian spelling rules (or the whole version) recommend the use of U+0307 just as Unicode does, for example entries of the LKŽ dictionary use U+0307. Additionally, when not respelled, foreign names are displayed without the dot, like Dalí in the VLE, but also in books and news articles. Last time I checked a Lithuanian news corpora, dictionary notation is rare and less frequent than foreign names with those accents on i, I’d expect the same in non linguistic books, although a larger analysis should be done.

Every implementation of this feature, that I am aware of, is broken. They never properly do what is being advertised and/or break the standard character representation.

For example the generic ìíĩ(į́į̃ j̃) are not changed as expected and the Lithuanian dictionary notation àáã (ą́ą̃) èéẽ (ę́ę̃ė́ė̃ i̇̀i̇́i̇̃į̇́į̇̃) ýỹ (j̇̃ l̃ m̃) ñ òóõ (r̃) ùúũ (ų́ų̃ū́ū̃) are changed inadequately in the Brill website tester (first line as is, second line hacked with the HTML lang="lt" attribute and locl feature, letters with non-spacing combining marks are between parentheses):

I had pointed the Unicode way to @John Hudson in the issue tracker of a UI font used to display any text. Luckily their implementation doesn’t break the standard way but doesn’t do anything on Lithuanian text either. After a couple of times I stopped pointing out it was broken as I recommended not doing it anyway.

If we’re going to implement this feature, at least let’s do it properly, give the user an easy in (or easy out if you need it to be on by default) and let’s not break the standard way of representing those letters.

John Hudson · October 6

Thanks for the link to the Unicode passage, Denis. I still find it problematic that the standard way of representing those diacritics effectively treats i + combining dot as equivalent to i in this context, when that is not the case anywhere else in Unicode.

[I always tell people not to assume that Brill is any kind of model implementation, because it is firstly a typeface made for a specific publisher who do things in a particular way (most other fonts don’t handle Dutch ij the way the Brill fonts do, for example, but that’s how Brill the company wanted it to function).]

Igor Freiberger · October 8

First question
In the proposal to add characters used in Lithuanian dialectology, from 2010, I can see both dotlessi+grave (page 9) and dotlessi+dotaccent+grave (page 12). But my attention was drawn to the presence of three other combinations, all with the dot appearing (page 13 onwards):

1. dotlessi + dotaccent + tilde
2. dotlessi + dotaccent + circumflex
3. dotlessi + dotaccent + acute

I marked these occurrencies with dark orange in the attached PDF. Aren't these situations suffering from the very same problems discussed here for dotlessi+dotaccent+grave?

Second question
Instead of using <calt>, isn't better to offer a <cv> with dotlessi+dotaccent+grave as an alternative to ì?

John Hudson · October 8

No one suggested using <calt>. There is standard contextual supression of soft dots, which is normally done in the <ccmp> feature. The <locl> implementation as in Brill simply omits this lookup for Lithuanian, but I would now probably classify this as a hack, with the caveats that Denis points out regarding foreign names.

dotlessi+dotaccent+grave as an alternative to ì?

The point of using the combining dotaccent is that it is a character level solution in the text encoding. It isn’t something that benefits from being treated as a glyph display variation. The idea is that it guarantees correct display for the Lithuanian dictionary convention without making a language-specific exception to the soft dotted property of the i.

Igor Freiberger · October 8

Sorry, I meant <locl>.

It isn’t something that benefits from being treated as a glyph display variation.

Well, I was thinking on an easy way to the user change the visibility/addition of dotaccent since keyboards don't provide enough entry ways to combinations beyond the usual ones. A font can provide <cv> so Adobe and Affinity apps can show the alternate composite on screen. It wouldn't interfere with <ccmp>, I guess, but I may be wrong.

Lithuanian localization

Comments

Categories