Add code and documentation for Znamenny Notation

[typiconman]

@pgmmpk Please review.

1. I merged in your code for \cuKruk and \cuKrukPara

2. I added documentation for the two functions in en and ru.

3. I'm not sure we actually need the \<> syntax, so I propose we get rid of it.

4. For some reason I cannot have a blank syllable in \cuKrukPara, e.g.: \cuKrukPara{ a b c \\ la--la } gives me ! Too many kruk groups. I would expect to have a kruk above an empty line, e.g., as in \cuKruk{b}{}.

[pgmmpk]

1. Agree, we get rid of \<> syntax
2. To create an empty syllable one have to use ~ (tilda), if I remember correctly.

[typiconman]

OK, I removed the <> syntax.

Regarding the use of empty syllables, this is not the case. Compare: \cuKruk{kruk}{} (creates a kruk over an underline \cuKrukPara{kruk \\ ~ } (creates a kruk over a blank space)

[pgmmpk]

Indeed, there is a problem. Tilda is not being seen as tilda, but is expanded into some control sequence (kern), hence empty text.

I will research how to fix it.

[typiconman]

I wonder also if it would be possible to automate coloring the marks. Right now we have this syntax: \cuKruk{kruk\textcolor{kinovar}{mark}}{text}. But there are two problems:

1. The code is difficult to read.
2. If we run the package in "grey" mode, we still have to manually change the code \textcolor{kinovar-gray}.

[pgmmpk]

Regarding the coloring of marks, this should work:

\cuKuk{kruk\cuKinovar{mark}}{text}

This will honor "grey" and "bw" modes.

If mark comes always after the kruk, we can invent some syntax sugar like this:

\cuKruk[mark}{kruk}{text}

Not sure how to translate this to \cuKrukPara though...

[pgmmpk]

@typiconman la--la can also be supported as an empty kruk. Let me know if this is desirable

[typiconman]

I think that you are correct that we can just use \cuKinovar. So there is no need for additional syntax.

[typiconman]

I updated the documentation. @pgmmpk please review.

[pgmmpk]

I think we should publish Znamenny font before publishing this on CTAN.

[typiconman]

Yes, I agree. But I think we can merge this branch in. I am working on the fonts right now, and I hope to have them "beta-stage" soon. (You can see the progress here: https://github.com/slavonic/fonts-znam).

[pgmmpk]

Yes, agree. Merging branch is fine. Just wanted to know the status of font work :)

Many thanks for your work.

[typiconman]

However, even once the fonts are ready, we still have to get the encoding model approved by UTC. Right now everything is encoded in PUA. Realistically, we could probably submit a proposal to UTC in the summer.

[pgmmpk]

I see. We should prepare the path how we move from interim product (PUA) to UTC-approved encoding. To avoid users trying to use PUA fonts with UTC version of churchslavonic and vv. At the minimum we should detect this and issue a clear error message... Ideas how to detect this?

Another problem is the need for re-encoding of texts typeset with PUA. Ideally, we should not require any re-encoding of texts... How this is going to work?

[typiconman]

Regarding the encoding: the PUA codepoints are specified in the PUA Policy (see here: http://www.ponomar.net/files/pua_policy.pdf). Per the PUA Policy, we guarantee stability, that is:

1. The PUA codepoints provided in our fonts will never change.
2. The PUA codepoints will still be available even when UTC accepts our encoding proposal. (They will be deprecated, but will not be removed).

In practice, once UTC accepts the proposal, we can check if any codepoints U+EE00 to U+EEFF are used in \cuKruk and \cuKrukPara commands, and issue a message: ! Warning: PUA codepoints for Znamenny detected; standard codepoints are now at U+1XXXX.

Since the mapping from the PUA codepoints to the standard codepoints accepted by UTC will be one-to-one, it is fairly straightforward to write a converter. However, the new versions of the font will still support the PUA codepoints forever. This is a courtesy we provide to our users so that they don't have to re-encode any documents.

Unfortunately, we don't know where UTC will place the characters in our proposal, so there is not much we can do right now.

[typiconman]

@pgmmpk Will you write code to colorize the marks or shall I just merge this as is?

[pgmmpk]

@typiconman lets merge this and I will open a separate PR to automatically colorize the marks. Thanks!

[typiconman]

Merged.