Список форумов textualheritage.org textualheritage.org
Сообщество "Письменное наследие"
 
 FAQFAQ   ПоискПоиск   ПользователиПользователи   ГруппыГруппы   РегистрацияРегистрация 
 ПрофильПрофиль   Войти и проверить личные сообщенияВойти и проверить личные сообщения   ВходВход 

If you have some trouble reading text and forms in Russian,
please use Google Translate to translate the texts and form titles to your language.
Please, use Google Translate only for titles and texts translating, not for forms filling.

After Unicode 5.1
На страницу 1, 2  След.
 
Начать новую тему   Эта тема закрыта, вы не можете писать ответы и редактировать сообщения.    Список форумов textualheritage.org -> Кириллица: кодировка, состав
Предыдущая тема :: Следующая тема  
Автор Сообщение
Victor Baranov



Зарегистрирован: 18.05.2007
Сообщения: 96
Откуда: Ижевск

СообщениеДобавлено: Сб Окт 04, 2008 5:55 pm    Заголовок сообщения: After Unicode 5.1 Ответить с цитатой

Эта тема для обсуждения принципов совершенствования кириллицы после выхода вер. 5.1 Unicode и после представления Белградских предложений на съезде славистов в Охриде.
Предыдущая тема http://forum.textualheritage.org/viewtopic.php?t=13&postdays=0&postorder=asc&start=15 закрыта в связи с тем, что основная задача, для которой она создавалась, - выполнена: предложения Белградской группы были представлены на съезде.

_________________
В.А.Баранов


Последний раз редактировалось: Victor Baranov (Сб Окт 04, 2008 6:08 pm), всего редактировалось 2 раз(а)
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail Посетить сайт автора
Victor Baranov



Зарегистрирован: 18.05.2007
Сообщения: 96
Откуда: Ижевск

СообщениеДобавлено: Сб Окт 04, 2008 6:01 pm    Заголовок сообщения: Договоренности в Охриде Ответить с цитатой

На съезде Охриде, на котором были представлены предложения по совершенствованию Unicode 5.1 и предложения Белградской группы, прошло рабочее совещание, на котором присутствовали представители обеих групп: с одной стороны, Ральф Клеминсон, Девид Бирнбаум, с другой - Хайнц Миклас, Виктор Баранов.
Результаты совещания:
1. Договорились о том, что необходимо еще раз внимательно просмотреть инвентарь знаков кирилловской части Юникода 5.1 с целью _обоснованного_ добавления необходимых символов. Подготовить обоснования для Юникода. Сроки назовет Ральф Клеминсон.
2. Понятно, что не все символы, которые необходимы для транскрипционной передачи текста, войдут в Юникод. Поэтому договирились о том, что необходимо обсудить - уже в рамках комиссии при Международой комитете славистов, которую сейчас возглавляет Ральф Клеминсон (предыдущие годы - Девид Бирнбаум), - перечень таких знаков, которые все же нужно иметь. Их договорились поместить в Private Use Area (PUA).
Важно! - И предложить всем, кто занимается славянскими текстами использовать и эту часть таблицы _согласованно_.
По возможности поместить эти знаки в то место PUA, которое еще не занято группами, работающими в PUA с другими языками.
3. Комитет под руководством Ральфа Клеминсона возьмет на себе функцию инициатора единообразного использования символов в PUA.
4. Сам отбор символов в PUA тоже не должен быть бесконтрольным и должен опираться на какие-то понятные правила. Их нужно сформулировать.
5. Если через какое-то время окажется достаточно оснований для "перемещения" символа из PUA в стандартный диапазон Юникода, это можно будет сделать.

_________________
В.А.Баранов


Последний раз редактировалось: Victor Baranov (Чт Окт 09, 2008 4:42 pm), всего редактировалось 1 раз
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail Посетить сайт автора
Victor Baranov



Зарегистрирован: 18.05.2007
Сообщения: 96
Откуда: Ижевск

СообщениеДобавлено: Чт Окт 09, 2008 4:35 pm    Заголовок сообщения: Два обсуждаемых предложения Ответить с цитатой

Предложения находятся по адресам:
http://kodeks.uni-bamberg.de/slavling/downloads/2008-07-26_white-paper.pdf
и
http://manuscripts.ru/mns/docs/standard_ocs.pdf

_________________
В.А.Баранов
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail Посетить сайт автора
Victor Baranov



Зарегистрирован: 18.05.2007
Сообщения: 96
Откуда: Ижевск

СообщениеДобавлено: Ср Ноя 12, 2008 8:03 pm    Заголовок сообщения: Addendum Ответить с цитатой

After Ohrid, the situation is 1) stay by themselves, each with their own views and positions and work separately in different bands, or 2) try to find a way to combine the two standards and really start to work together.
The second decision we found more productively.
It is a simple arrangement:
- to put into PUA all the characters of BS except those that there are already in Unicode.
We understand that for the recruitment of texts we have to avoid even the potential to transfer "a-s" which have different codes. This is a mandatory requirement for electronic texts in relation to their further automated processing, which would not be possible with ambiguity typing.
What are the significant benefits of this solution:
- The Unicode standard-range will be expanding at the expense and on the base of PUA; at the same time the BS in the PUA will be recognized by the special commission of the international committee of Slavists as a special standard for all who work in this area.
- With the support of the national committees we will be able to officially appeal to all to recognize this complement of the standard range, and the combined Unicode and BS-PUA as one standard, belonging together.
- Everyone will have a clear and consistent coding of Slavic texts that provides for the migration of documents.
The coordinated BS characters will be retained in the unified list of characters.
We also understand that a particular place mark does not matter, neither for its recruitment from the keyboard, nor for sorting characters or creating a user-friendly interface, in which all "and" would have been a number - it is not code table, and other software.
There are still two problems that need to be solved:
1) How to support the system of a text which contains both modern "a" and ancient "a"?
2) How to position the characters exactly (in PUA).
We already know the answers:
1) Using different fonts, allowing for modern "a" and ancient "a" if they have the same code.
2) Using OTF, or have combined characters in the PUA.
OTF, as I have stated before, is supported both by Adobe’s software, and TEX.
There is a substantial question we have to agree on:
- Whether or not to place in the PUA also palaeographic options (glyphs).
My and Heinz' opinion is – no! Various tracing should be referred to different fonts.
Thus, we will have a division of characters into three groups:
- the main options (now - the main ranges of Unicode),
- the functional options (needed for the unique automated text) (now - in PUA) and
- palaeographic options, as I said in Belgrade. The palaeographic options should be represented by different font - headsets.
We all understand that a combination of standards on the basis of this will be most productive and a lasting solution for our common and private concerns.

_________________
В.А.Баранов
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail Посетить сайт автора
Zoran Kostic



Зарегистрирован: 09.10.2008
Сообщения: 7
Откуда: Serbia

СообщениеДобавлено: Чт Ноя 13, 2008 12:34 am    Заголовок сообщения: Standard and Proposals Ответить с цитатой

Стандарт старославянского кириллического письма и предложения по его регистрации в Юникоде

Мне кажется, что мы увязли в вопросе, что было раньше: курица или яйцо? Или в нашем случае: предложения по регистрации в Юникоде или Стандарт? В настоящий момент имеются две группы авторов с различными подходами к решению проблемы. Это Белградская конференция (наиболее активные участники: Хайнц Миклас, Виктор Баранов, Виктор Савич и Зоран Костич) и вторая группа: Ральф Клеминсон, Девид Бирнбаум, Себастьян Кемпген и др.

Исходным пунктом в любой науке является определение задачи (цели). Мы с 2003 года пытаемся создать в Белграде шрифт, который бы полностью охватил старославянскую кириллицу. Данный шрифт должен обеспечить наиболее адекватное воспроизведение графической системы. Чтобы достичь этого, нам необходимо точно знать, какие буквы, диакритические знаки и символы веками использовались в старославянском языке, или, другими словами, знать стандарт старославянского кириллического письма. Однако мы осознали, что такой Стандарт никогда не был установлен и что его регистрация в Юникоде отличается неполнотой. Логичным и рациональным шагом (в соответствии с научным подходом) было бы сначала установить Стандарт, чтобы мы знали, что можно предложить Юникоду для регистрации.

Вторая группа выдвинула Юникоду собственное предложение (как будто они обладали авторскими правами) без предварительной проверки данного предложения в широких научных кругах, на какой-либо конференции. Почему – мы не знаем. У них никогда не было представления о том, что установление Стандарта языка необходимо и логически предшествует регистрации в Юникоде. Они вели себя, как вольные стрелки, по отношению к вещам, где это недопустимо. К сожалению, Техническая комиссия Юникода приняла это предложение для версии 5.1, хотя оно также неполное, а потому мы снова имеем неполную регистрацию старославянского письма.

Чтобы оправдать свои действия, совершенные при отсутствии концепции, эти авторы написали „Белую книгу“, где показали непонимание многих проблем; намеренно или случайно – судите сами. Позвольте объяснить лишь самое важное.
а) Печатная и электронная версии конечной версии Стандарта старославянского кириллического письма представляет собой стандарт языка и НЕ ЯВЛЯЕТСЯ предложением по регистрации в Юникоде. Поэтому все замечания (а их имеется много), относящиеся к данному Стандарту как предложению по регистрации в Юникоде, не имеют никакого смысла. Более того, эти авторы включают замечания в предложение Стандарта на Белградской конференции (октябрь 2007), т.е. в рабочие материалы конференции, хотя данный Стандарт был изменен на самой конференции и еще 9 месяцев после этого дорабатывался для оформления в окончательное предложение Стандарта. Зачем они это сделали, мы не знаем, ведь им было хорошо известно и это конечное предложение.
б) Когда данный Стандарт будет принят большинством заинтересованных ученых и учреждений, тогда мы направим предложение Юникоду. Это предложение будет базироваться на Стандарте языка, а не на случайно найденных незарегистрированных буквах. Например, из пяти различных выносных букв для „иже“ не нашли (и соответственно не зарегистрировали) ни одной. Как это возможно? Если этим авторам известно правило о том, что всякая буква могла быть выносной, почему же они включили в предложение только то, что увидели лично? Если бы они попросили о помощи других ученых, их предложения по регистрации и сама регистрация не выглядели бы любительскими. Или когда через несколько месяцев они „найдут“ новую букву, последует новое предложение Юникоду и так до бесконечности? Только для того, чтобы они представили себя спасителями старославянского письма? Вероятно, они считают, что мы, славяне, сами неспособны оформить свой язык, что нам необходима их помощь, давали мы на это согласие или нет.
в) Авторы много объясняли принципы Юникода, однако не объяснили, что же является „обычным текстом“ (plain text), когда речь идет о старославянском письме. Если китайский, японский, корейский и арабский языки можно воспроизвести без ущерба для традиции письма – а ведь эта графика зарегистрирована и, как я надеюсь, именно на таких условиях, – в чем тогда проблема с регистрацией старославянского письма? Мы что, являемся особым случаем? Или проблема в знаниях „специалистов“, которые объясняли Юникоду природу старославянского письма? Мы ожидаем, что „обычный текст“, наконец, можно будет легко набирать, без типографических экзибиций, даже в специальных программах. При сегодняшней регистрации и правилах Юникода это просто невозможно.
г) Все сказанное, возможно, выглядит как теоретическая дискуссия, однако, к сожалению, принятие того или иного метода (стандарта) будет иметь и практические последствия. Более подробное объяснение вы найдете в приложении Differences.pdf



Differences.pdf
 Описание:

Скачивание
 Название файла:  Differences.pdf
 Размер файла:  72.14 KB
 Скачено:  8892 раз(а)

Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail Посетить сайт автора
А.В.Коваленин



Зарегистрирован: 03.06.2007
Сообщения: 16
Откуда: Новосибирск

СообщениеДобавлено: Чт Ноя 13, 2008 6:00 pm    Заголовок сообщения: Ответить с цитатой

Примеры, которые приводит Зоран Костич, показывают, что он думает скорее о шрифте, чем о стандарте представления plain text, но при этом: (а) не видит разницы между этими проблемами; (б) не знает возможностей шрифтовых технологий.

1. Важно уже (а) - даже если бы современных шрифтовых технологий не было, то всё же стоило бы заметить, что назначение стандарта - не в том, чтобы зафиксировать средство создания близкого к оригиналу типографского отображения текста, а в том, чтобы обеспечить содержательную сравнимость текстов, разных по времени и по почерку. То есть именно "Plain text must contain enough information (to permit the text to be rendered legibly), and nothing more". Какая машина будет render этот text - для стандарта не важно.

2. Но современные технологии - OpenType, Graphite - позволяют поручить функции этой машины самому шрифту, что почти решает проблемы хорошей типографики, если у вас есть требуемая enough information. Шрифт сегодня содержит внутри себя машину, которая может не просто ставить друг за другом глифы, однозначно соответствующие символу, но и выбирать сдвиг одного глифа относительно соседнего или выбирать вариант глифа в зависимости от соседних. В Казани А.Зобнин продемонстрировал мне, как с помощью бесплатной программы MS Volt оказалось возможным быстро подправить славянский шрифт так, что титло после "аз" ставилось под буквой, а не над ней.
Иначе говоря, качественная отрисовка примеров Зорана, которые в стандарте HIP выглядят как #а~ и и\а~ (и это тоже вариант стандарта!) - вопрос качественного изготовления шрифта. Если только шрифтовик не знает других шрифтовых технологий, кроме метода "символов нулевой ширины", то он может не справиться с задачей и пожелать пользователю "good luck". Но грамотный шрифтовик может заложить в шрифт запасные глифы и описывать (внутри шрифта) выбор нужного глифа, а может описывать точное позиционирование пар символов друг относительно друга.

Например, в стандарте может быть обозначение "лигатура" (в HIP - &, например, а&б). Один шрифт (для технического отображения текста) может реализовать все лигатуры сразу, используя для "&" один глиф в виде обнимающей оба символа дужки"нулевой ширины". Другой шрифт (для хорошей типографики, вроде шрифтов Зорана) предусмотрит запасные глифы для каждой лигатурной комбинации - с&т, т&р... и обеспечит подстановку нужного глифа по ситуации.
При этом состав и кодировку этих запасных глифов стандартизировать не нужно и даже вредно, так как а) они не влияют на plain-text и б) это значит сокращать для шрифтовика пространство для творчества.
Цитата:
Например, из пяти различных выносных букв для „иже“ не нашли (и соответственно не зарегистрировали) ни одной. Как это возможно? Если этим авторам известно правило о том, что всякая буква могла быть выносной, почему же они включили в предложение только то, что увидели лично?
Во-первых, точнее, наверное, всё-таки говорить о пяти вариантах одной буквы - выносного "иже"?
Во-вторых, я могу объяснить, что случилось с новыми выносными. Авторы этого предложения делали заявку для регистрации в Unicode, а не "стандарт языка". А Unicode не собирается считать символом то, что может быть сделано средствами разметки. Поэтому стратегия авторов была в том, чтобы доказать, что выносные буквы заслуживают трактовки себя как самостоятельных символов. Те буквы, для которых это удалось, были поданы в качестве заявки.
Конечно, на мой взгляд, правильнее было бы зарегистрировать в качестве символа невидимые знаки-конструкторы "выносная:" и "лигатура" (в стандарте HIP - \ и &). Тогда все проблемы с выносными буквами и лигатурами можно было бы перенести из области разработки стандарта в область искусства шрифта - проще говоря, свалить на шрифтовиков. Но Unicode регистрирует "characters", то есть видимые сущности, и убедить комитет зарегистрировать невидимую сущность было бы столь же полезно, сколь и проблематично.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail Посетить сайт автора
Zoran Kostic



Зарегистрирован: 09.10.2008
Сообщения: 7
Откуда: Serbia

СообщениеДобавлено: Пн Ноя 17, 2008 8:24 pm    Заголовок сообщения: Internal OCS Standard in PUA Ответить с цитатой

Dear colleagues,
I am not going to comment Kovalenin, partly because I don't know Russian but mostly because he tries to discuss things about font technology where he is total amateur. With two my OTF fonts (with use of OTF features) of 6.400 characters, which cover at least three centuries and not only Serbian redaction, I show my knowledge. Everybody can download older version of this fonts (Hilandarski ustav and Monah), with more than 4.000 characters, for free from: http://www.cirilica.net/staroslovenska_pisma.php

Also I don't understand why we have to use special programs and to suffer when we can define all characters in PUA and normally use Word which is a common for majority of scholars. For me, if we cannot type text in Word, it is not simple or plain text. That's why we must define all characters which will enable typing in the Word. Of course it is bigger effort for typographer who made a font, but users will have possibility to type and reproduce traditional way of writing. If typographer gives big effort he will produce a font for fine typography. If not, it will be typographically incorrect positions of some characters, but again with ability to type a full Standard of OCS.

In the attachments you may find a proposal for Internal standard of OCS in PUA. First file "PUA-Codes-BS-full with glyphs.pdf" represent a full table of codes for those who need glyphs and ligatures and second file "PUA-Codes-BS-short.pdf" represent only Belgrade standard without glyphs and ligatures. In both files the codes are the same for the same characters. All explanations are on the first page. Please read it carefully.



PUA-Codes-BS-short.pdf
 Описание:

Скачивание
 Название файла:  PUA-Codes-BS-short.pdf
 Размер файла:  292.28 KB
 Скачено:  7674 раз(а)


PUA-Codes-BS-full with glyphs.pdf
 Описание:

Скачивание
 Название файла:  PUA-Codes-BS-full with glyphs.pdf
 Размер файла:  804.36 KB
 Скачено:  8568 раз(а)

Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail Посетить сайт автора
Victor Baranov



Зарегистрирован: 18.05.2007
Сообщения: 96
Откуда: Ижевск

СообщениеДобавлено: Ср Ноя 19, 2008 1:30 pm    Заголовок сообщения: Ответить с цитатой

I have a suggestion:
(1) Move to PUA _all list_ of characters of the the Belgrade team.
(2) Move to another place in the PUA all list of characters, with the exception of characters of the standard range Unicode and except palaeographic glyphs.
This would solve two problems, the one we are discussing, and the one we have overlooked: to have a script full set of characters in at least two forms - in the modern and ancient.
Creation of tables of identical glyphs between the two ranges is not difficult.
I hope your consent.

_________________
В.А.Баранов


Последний раз редактировалось: Victor Baranov (Сб Ноя 22, 2008 9:55 am), всего редактировалось 1 раз
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail Посетить сайт автора
Zoran Kostic



Зарегистрирован: 09.10.2008
Сообщения: 7
Откуда: Serbia

СообщениеДобавлено: Ср Ноя 19, 2008 11:00 pm    Заголовок сообщения: Explanation Ответить с цитатой

My friend Baranov did not understand the use of PUA table with codes. In this table we define places for full Belgrade Standard plus glyphs and ligatures. Column with codes of already registered characters in Unicode is for informational purposes and/or conversion purposes. There is no need to put BS two times in this table. Let me explain.

1. If, for example, someone need to make font with contemporary Cyrillic, Greek and OSC, he will take Unicode codes for contemporary Cyrillic and Greek, but for OCS he will take all codes from PUA code table (with or without glyphs and ligatures) not anyone from Unicode even some of them are registered. In such way we avoid conflict with, for example, "a" and "az" which share the same place in Unicode. And that's the only way to have in one font contemporary Cyrillic, Greek and OSC. In this font we can also add Glagolitic script, Latin script etc.

2. If, for example, someone need to make fully Unicode font with Greek and OSC (but not with contemporary Cyrillic) he will take Unicode codes for Greek and OCS and nothing from PUA.

3. If, for example, someone need to make font with Greek and OSC (but not with contemporary Cyrillic) he will take Unicode codes for Greek and OCS and he will add codes from PUA table for the characters which are not already registered in Unicode (with or without glyphs and ligatures).

You may see all three examples in file Examples.pdf. These examples show how you build font codes for different purposes.

I will repeat that this PUA codes table is universal and each character has unique code. Do not make objections that something is too much. Trust me, it is not. If nothing is missing from the table, than we should accept this table.



Examples.pdf
 Описание:

Скачивание
 Название файла:  Examples.pdf
 Размер файла:  60.44 KB
 Скачено:  8821 раз(а)

Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail Посетить сайт автора
al_zobnin



Зарегистрирован: 25.08.2007
Сообщения: 5
Откуда: Москва

СообщениеДобавлено: Вс Ноя 23, 2008 3:47 am    Заголовок сообщения: Ответить с цитатой

Уважаемые коллеги!

Извините, но я буду писать по-русски.

Я прочитал сообщения на этом форуме и внимательно посмотрел документы Differences.pdf и Internal Registration of Standard of UCS (далее я буду цитировать фразы из них). Могу сказать следующие соображения .

1. Хорошо, что авторы предлагаемого стандарта уже не ставят перед собой цель полностью зарегистрировать весь набор символов в Unicode. Это неосуществимая и совершенно неправильная задача, о чем замечательно написано в White Paper.

2. Фраза "Unicode rules do not enable us to write even simple text" не выдерживает никакой критики. Это неправда. Особенно удивляет последующий вывод: "we must move WHOLE Standard in PUA". В файле Differences.pdf Зоран Костич приводит такие аргументы: "Я желаю удачи всем тем, кто попробует это написать". Что ж, я готов, как только у меня появиться время, продемонстрировать ему как это делается с помощью технологии OpenType. Конечно, о работе в Word'е здесь говорить не приходится, но этот редактор для такого пока и не предназначен. Вообще, складывается впечатление, что мы должны принять стандарт только потому, что работаем в Word'e. Тут все поставлено с ног на голову. Далее Зоран Костич приводит примеры, набранные его собственными шрифтами, и их транскрипцию. Он утверждает, что plain text позволяет закодировать только эту транскрипцию. Это не так!!! Если Word не умеет "красиво" отображать последовательность символов (например, н + а выносное + титло), то это не значит, что такую последовательность не сможет красиво отобразить какая-нибудь другая программа. Ну неужели не понятна та самая цитата из стандарта Unicode? "The relationship between appearance and content of plain text may be summarized as follows: Plain text must contain enough information to permit the text to be rendered legibly, and nothing more." Повторю еще раз: последовательность символов U+043D, U+2DF6, U+0483 (н + а выносное + титло) ОДНОЗНАЧНО определяет то, как этот символ должен выглядеть, и хороший текстовый редактор вместе с хорошим шрифтом должен отобразить эту последовательность символов именно так, как ожидается. Введение для этой цели отдельного символа - это уже избыточная информация, которой, согласно приведенной выше цитате, быть не должно.

3. Какие аргументы можно привести за включение всего стандарта целиком в PUA (несмотря на то, что основная часть уже есть в нынешнем Unicode)? Авторы пишут в пункте 5: чтобы можно было работать с базами данных, которые позволяют использовать только один шрифт в поле. Как разработчик баз данных для филологов могу сказать, что если у кого-то возникает такая проблема, то надо менять внутреннюю архитектуру базы, а не призывать всех переходить на другую кодировку. Есть масса решений этой проблемы: хранить в базе данных текст в формате RTF или XML со специальными тегами, разбить эти данные на несколько отдельных ячеек, использовать специальные программные оболочки для работы с базой данных, наконец, создать свой специфический шрифт для этой конкретной базы. Но не возводить это в ранг всеобщей проблемы. Я могу привести пример базы данных для диалектологического атласа русского языка, над которым я работал. Там в вопросах фонетической программы, которые хранились в таблицах, некоторые буквы необходимо было выделять жирным или курсивом. Согласитесь, для решения этой проблемы было бы глупо требовать от всех добавления курсивных и полужирных символов в стандарт, чтобы их можно было бы написать тем же шрифтом, что и обычные.

4. Для того, чтобы набирать текст в Word'е, совсем необязательно иметь в шрифте отдельные символы с титлами! Другое дело, когда требуется высокое типографическое качество. Но там, как правильно заметили авторы, вместо Word следует использовать другие программы. От себя могу порекомендовать систему XeLaTeX, которая полностью поддерживает возможности OpenType. Кстати, именно возможностями OpenType можно (и нужно!) правильно размещать титла и другие надстрочные знаки над буквами. Для этого нет необходимости кодировать их отдельно! Это специальная возможность формата OpenType, аналогичная кернингу. Я абсолютно уверен в том, что достаточно единого композитного символа "титло", который, кстати, есть в Unicode. То же самое относится и к лигатурам: если авторы предлагают пользоваться для их создания возможностями OpenType, то их не обязательно включать в стандарт кодировки.

Итак, я категорически против внесения в стандарт всевозможных композитных символов, включая лигатуры, символы с титлами и числа. Да, в технологии OpenType предусмотрена возможность замены определенной последовательности символов на другой глиф (например, на лигатуру). Но такой глиф вовсе не обязан иметь код в кодировке, он просто может жить внутри шрифта!

5. Идея с выносными буквами, расположенными не над основным символом, а между ними, кажется мне полезной. Но я подозреваю, что и здесь можно обойтись специальным знаком, обозначающим смещение надстрочного знака вправо. Кстати, если авторы убеждены, что в стандарт нужно отдельно включать все символы с титлами, то почему они тогда не включают и все пары с выносными буквами? Smile)

6. Я все больше убежден в необходимости мнемонического формата записи "нестандартных" символов (например, основанного на HIP). Я сам математик и могу привести такой пример. Математическую формулу тоже сложно записать как plain text. И даже не потому, что это невозможно: нет, в Unicode имеются все математические символы. А потому, что это неудобно. Если нужен обычный plain text, то гораздо быстрее и проще написать "\sum_{k=0}^n a_k x^k". Каждый математик поймет эту запись, так как это - язык разметки математических текстов TeX. Он позволяет разметить в таком виде и сверстать профессиональную публикацию, но его нотацией удобно пользоваться и напрямую.
Удобный и признанный всеми формат для записи нестандартных символов и описания разметки, использующий лишь основную кириллицу, латиницу и знаки препинания, был бы крайне полезен. Его мог бы и легко читать человек, и обрабатывать компьютер. Такой формат отличается от XML именно удобством чтения и набора человеком. Заметьте, его существование нисколько не противоречит принципам Unicode и, конечно, не отменяет необходимость разработки профессиональных шрифтов.

7. Если все-таки будет принято решение о размещении символов в Private Use Area, то хочу посоветовать две вещи:
а) разместить символы не в основной зоне (начиная с U+E000), а в дополнительной (плоскость F, коды от U+F0000 до U+FFFFD);
б) размещать основные символы не "подряд", а с опреденным шагом, оставляя зарезервированные места. Например, можно использовать для буквы Аз и ее вариантов коды от U+F4100 до U+F410F (чтобы первые цифры кода были похожи на Unicode, а последняя цифра соответствовала типу функционального варианта). Это, с одной стороны, позволит добавлять функциональные варианты символов в будущем, а с другой - упростит компьютерные вычисления при поиске, сравнении, упрощении и т.д. Те коды, которые предлагаются сейчас, в этом смысле очень неудобны.

Три месяца назад я уже высказывал здесь подобные соображения.

С уважением,

Алексей Зобнин.


Последний раз редактировалось: al_zobnin (Вс Ноя 23, 2008 11:15 am), всего редактировалось 2 раз(а)
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
al_zobnin



Зарегистрирован: 25.08.2007
Сообщения: 5
Откуда: Москва

СообщениеДобавлено: Вс Ноя 23, 2008 11:04 am    Заголовок сообщения: Ответить с цитатой

Хочу сделать добавление к пункту 7 моего предыдущего сообщения.

В нем я лишь предостерегал от возможного неудачного решения. Это совершенно не означает, что я предлагаю продублировать основную кириллицу в Private Use Area. В любом случае коды следует присваивать обдуманно для удобной компьютерной обработки. Например, посмотрите, как присвоены коды в основной таблице ASCII с латиницей (коды от 20 до 7F). Скажем, цифры закодированы так, что их значение равно последней цифре кода. А код строчных букв получается из кода заглавных прибавлением фиксированного шестнадцатеричного числа 20. В этом смысле новые добавления в Unicode (прежде всего выносные символы, появившиеся в стандарте 5.1) сделаны очень неудачно. Не следует повторять ту же ошибку.

Еще раз хочу обратить внимание: не следует стремиться к тому, чтобы кодировка точно соответствовала порядку сортировки символов. Unicode этого не предусматривает.

Алексей Зобнин.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Victor Baranov



Зарегистрирован: 18.05.2007
Сообщения: 96
Откуда: Ижевск

СообщениеДобавлено: Вс Ноя 23, 2008 10:49 pm    Заголовок сообщения: Ответить с цитатой

Первое:
Согласен с Алексеем Зобниным.
Такой подход позволяет предложить следующий выход из создавшегося положения:
1) разместить все символы белградских предложений в PUA, кроме тех, которые есть в Unicode,
2) при размещении в PUA выделить для каждой группы основных и функциональных вариантов символов отдельные поддиапазоны - буквенные символы, надстрочные буквы, диакритику, титла, лигатуры, синтаксические знаки, буквы-цифры, комбинированные символы и др., при необходимости оставив между символами пустые коды,
3) в отдельном поддиапазоне разместить палеографические варианты всех этих групп, также с пустыми кодами между символами.
Это позволяет:
(1) использовать каждый из поддиапазонов отдельно:
или только Unicode,
или Unicode + основные и функциональные варианты,
или Unicode + основные и функциональные варианты + комбинированные символы,
или Unicode + основные и функциональные варианты + комбинированные символы + палеографические варианты и т.д.
Различия между современными и древними символами создавать с помощью фонтов.
Второе:
Только компромисс, найденный в Охриде, может дать удовлетворяющее всех решение. Только компромисс может сделать совместное решение внутренним стандартом славистов.
Третье:
По-моему, нужно уже приступать к подготовке предложений к следующей версии Unicode.

_________________
В.А.Баранов
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail Посетить сайт автора
al_zobnin



Зарегистрирован: 25.08.2007
Сообщения: 5
Откуда: Москва

СообщениеДобавлено: Вт Ноя 25, 2008 3:01 am    Заголовок сообщения: Ответить с цитатой

Уважаемые коллеги!

Я в моем большом сообщении пообещал, что продемонстрирую, как можно набрать фрагмент текста Зорана Костича с помощью OpenType-возможностей. Но буквально вчера на сайте Алексея Крюкова http://www.thessalonica.org.ru/ru/fonts-download.html появилась новая версия OpenType-шрифтов OldStandard 2.0.2. Шрифты полностью поддерживают стандарт 5.1 и созданы с применением технологии OpenType. Почитайте руководство, которое написал Алексей Крюков, особенно разделы про OpenType и про Old Slavonic (стр. 34). Само это руководство сверстано с помощью XeTeX и использует только Unicode 5.1 и OpenType. Нужны ли еще какие-то комментарии?

Я вот набрал этим новым шрифтом OldStandard 2.0.2 текст Зорана Костича. Прикладываю pdf-файл и исходный tex-файл, который прекрасно читается даже в обычном блокноте. Это самый что ни на есть plain text. Конечно, выносные буквы следует сдвинуть вправо, чтобы они были между символами, но сейчас речь вовсе не об этом. Обратите внимание на приятные типографские мелочи в PDF-файле, сделанные с помощью OpenType.


Я, к сожалению, не знаком с Алексеем Крюковым, но думаю, что было бы полезно привлечь его к нашей дискуссии.

Алексей Зобнин.



Example.zip
 Описание:
Исходный файл, из которого программой XeLaTeX был получен PDF. Можно смотреть хоть блокнотом (шрифт OldStandard 2.0.2).

Скачивание
 Название файла:  Example.zip
 Размер файла:  419 Байты
 Скачено:  6948 раз(а)


Example.pdf
 Описание:

Скачивание
 Название файла:  Example.pdf
 Размер файла:  13.01 KB
 Скачено:  6788 раз(а)

Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Алексей Крюков



Зарегистрирован: 27.11.2008
Сообщения: 1

СообщениеДобавлено: Чт Ноя 27, 2008 3:35 am    Заголовок сообщения: Ответить с цитатой

As Victor Baranov has asked me to join this discussion, I would like to express some thoughts here.

First of all, I don't believe it is really possible to develop in a limited time such a perfect standard for such a complex script as Old Cyrillic, that no further additions are required. For this reason I don't understand Zoran Costic's irony regarding new characters being instantly found, proposed, encoded, etc. Indeed, that's the way by which the Unicode standard is normally developed. For example, encoding Latin combining letters has required several steps, and I would expect more additions in future, as still not the whole alphabet is encoded.

That's why I don't think it is possible to estimate the professionality level of someone's proposal just by looking at its completeness. There are much better criteria: I would actually call a proposal professional if it doesn't introduce any wrong concepts, which then would be difficult or impossible to abandon due to Unicode stability policy. From this point of view I find the proposal prepared by M. Everson and Co. really excellent: it has not introduced any never existent or spurious characters (compare the case of recently encoded LATIN CAPITAL LETTER R ROTUNDA, discussed
here). No characters have been misinterpreted (compare the Cyrillic "wide o", called "round omega" in Unicode, or "beautiful omega" erroneously interpreted as an omega with titlo).

I also don't like the idea of moving the whole standard into PUA. Of course it might seem reasonable to have modern and historical Cyrillic alphabets combined in the same font. However, a large part of already encoded historic letters was never used in any modern languages, so that there is no stable tradition of representing them in the modern ("civil") style. It would be really strange to double-encode such letters. Second, it might be not sufficient to have just one set of historic characters: for example, font faces designed for publishing old manuscripts are usually not suitable for modern Church Slavonic and vice versa. So one would need at least 3 separate fonts for a mixed document, written, say, in modern Russian, but containing citations in Old Russian and modern Church Slavonic. And finally a question arises, how the PUA-encoded characters should be accessed in users' documents? Composing a text entirely from directly typed PUA characters would make it completely unsearchable, not to mention that most applications don't apply kerning and other advanced typography rules to PUA codes. On the other hand, if OT features are supposed to be used to switch a text representation from modern to historic style, then there is absolutely no need to map historical forms to PUA slots: it would be sufficient just to put them into a font and keep unencoded.

And finally regarding the combining marks vs. precomposed characters question: that's true that most researchers do their ordinary work in word processors (not necessarily MS Word) and they would expect their documents to look correctly in their favorite applications. But for me this just means we should do our best to improve OT support in text editing applications instead of relying solely on their present capacities. MS Word (or rather MS Uniscribe -- the library responsibe for advanced text rendering in MS applications) already supports combining mark positioning. Unfortunately there are some problems with specifically Cyrillic marks which make it hardly possible to use MS Word for typing Unicode Old Cyrillic right now: for example, I couldn't get a breathing properly combined with an accent into a composite mark, although similar substitutions worked fine for Greek. There are no such problems with open source renderers, i. e. Pango and ICU. However, I should ask: why such bugs in Uniscribe could occur and exist for years? The answer is simple: because Unicode could not be used to represent Old Cyrillic texts, so nobody cared about proper font support for this task. Now, thanks to Unicode 5.1, we can start developing proper font support for Old Cyrillic, and thus can point Uniscribe developers to their flaws (that's actually what I am planning to do in the near future). I really hope the situation can be improved soon, and this will make obsolete any quasi-standards based on placing a huge amount of precomposed characters into PUA.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Victor Baranov



Зарегистрирован: 18.05.2007
Сообщения: 96
Откуда: Ижевск

СообщениеДобавлено: Чт Dec 04, 2008 8:00 pm    Заголовок сообщения: Расширение латинского диапазона Ответить с цитатой

Всем нам полезно познакомиться с опытом размещения латинских средневековых символов в PUA. См. http://www.mufi.info/specs/MUFI-CodeChart-3-0-a.pdf.
_________________
В.А.Баранов
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail Посетить сайт автора
Показать сообщения:   
Начать новую тему   Эта тема закрыта, вы не можете писать ответы и редактировать сообщения.    Список форумов textualheritage.org -> Кириллица: кодировка, состав Часовой пояс: GMT + 4
На страницу 1, 2  След.
Страница 1 из 2

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете добавлять вложения в этом форуме
Вы можете просматривать вложения в этом форуме


Powered by phpBB © 2001, 2005 phpBB Group