Т.е. необходимо разделить изображения (это назовем знаками?) и ассоциации в которые они отображаются (именно это называется алфавитом).
В вашей терминологии, в современном IT это решается следующим образом: Unicode задает соответствие между числовыми кодами и
семантическими значениями символов алфавитов (т.е. грубо говоря числовой код "65" - это заглавная латинская буква "A"), а конкретное
графическое изображение символов одного или более алфавита задается шрифтами. При этом, существуют объектно-ориентированные библиотеки работы как собственно с символами алфавитов (оперирующие понятиями "буква", "цифра", "знак препинания" и т.п.), так и со шрифтами. Что кардинально нового предлагаете Вы?
А еще, почитайте, пожалуйста, вот эту статью - мне кажется, там изложена точно такая же идея, как и у вас, вернее, ее реализация в Unicode:
⚠ Тільки зареєстровані користувачі бачать весь контент та не бачать рекламу.
И нет русской буквы "Р" и английской буквы "Р". смысле разницы в кодировании. Когда говорят русская "Р" это касается именно уточнение изображения в случае устной речи.
Вот здесь непонятно. Да, русская "Р" и латинская "P" имеют одинаковое, или по крайней мере очень похожее
графическое изображение. Но семантически - это совершенно два разных символа двух разных алфавитов. Если закодировать их одним и тем же числом (или последовательностью чисел - неважно), то как
машина их вообще различит в тексте?
На письме этот вопрос не возникает вообще. Очень четко можно это понять представляя алфавит. Там же нет ни шрифтов, ни размеров и даже больших и маленьких букв нет!
Секундочку. А как насчет хотя бы прописных/строчных букв в европейских алфавитах, и это уже не говоря о более экзотических национальных особенностях, например, слоговом письме? Опять-таки, настоятельно отсылаю к
⚠ Тільки зареєстровані користувачі бачать весь контент та не бачать рекламу.
Алфавит это чисто нумерация соответствия со знаками.
Иными словами, однозначное соответствие набора символов некоего алфавита некоему множеству числовых кодов. Причем, Unicode придумали, чтобы эти множества для разных алфавитов не пересекались.
Т.е. с какой-то характеристикой (пусть это будет номер знака) собственно изображения этого знака.
А вот это уже называется шрифт, т.е. однозначное соответствие числового кода символа некоему растровому или графическому изображению.
Вот отсюда такая беда с понятиями. У меня знак это одно, а буква это совершенно другое. Даже другой класс.
Да не только у вас, это и сейчас так как минимум в двух распространенных операционных системах. Другое дело, что и сейчас нередко с кодами символов алфавитов "по старинке" работают как с числами, а не как с объектами.
Ну, отсюда легко понять что имея набор знаков, для того что бы написать новый (пользовательский) алфавит, необходимо просто перечислить знаки в каком-то порядке. Этот порядок.. Дальше, надеюсь понятно. Если не хватает знаков, что ж прийдется добавить. Вот и вся проблема.
Ну так эта проблема тоже давно решена как с точки зрения кодирования в Unicode, в котором выделено специальное подмножество числовых кодов для знаков пользовательских алфавитов, так и с точки зрения поддержки операционной системы в плане их графического изображения. Например, для Windows:
⚠ Тільки зареєстровані користувачі бачать весь контент та не бачать рекламу.
Да.. И стандарт надо иметь не на алфавиты, а на знаки.
Простите, но зачем? Чем плох существующий подход, в котором определены
- Все национальные алфавиты
- Набор знаков препинания
- Набор математических символов
- и т.п. плюс возможность задания пользовательских алфавитов?
А все ли в современном кодировании является знаками? Как насчет перевода строки? Если стоит вопрос хранения объектов таких как буквы (имеется ввиду алфавит), то они представляют собой объекты как то расположеные в другом объекте (странице). Каждая на какой-то позиции обычно следуя друг за другом и этой последовательностью (имеется ввиду последовательность хранения) определяя собственную позицию. А это уже правило!
Разделение логической и графической разметки (форматирования/верстки) текста тоже уже давно придумали. Тот же Microsoft Word 2007 именно так и делает - расковыряйте ради интереса "внутренности" .docx файла, и вы увидите, что собственно текст хранится в виде логической структуры, а на правила форматирования идут ссылки. Или тот же HTML/CSS - в современном HTML все тэги, которые описывают именно форматирование, считаются "устаревшими" и их использование настоятельно не рекомендуется.
Нужность символа перевода строки как именно символа алфавита - вопрос действительно философский. В идеальном мире, скорее, символом был бы знак переноса, а уже он бы транслировался в правило отображения оставшейся части абзаца с новой строки. Но поскольку в реальном мире есть богатое наследие, в котором именно символы перевода строки и возврата каретки широко использовались, вряд ли от них откажутся в ближайшем будущем полностью.
А пробел это знак или правило? Поразмышляй.. Интересно.. И не ссылайся на то как сейчас .. А думай как оно должно быть, что бы было правильно.. Если интересно думать на эту тему..
От пробела как знака
теоретически можно отказаться, если как-то по другому обозначать границы слов (или оставить его как знак только для совместимости с существующими форматами данных). Но. Знак пробела - это максимум два байта, маркеры начала и конца слова займут как минимум в два раза больше. К тому же, с пробелом в плане наследия точно такая же история, как и с переводом строки.
другое дело, что OLE поддерживается большинством популярных языков программирования, а Художественному Руководителю надо обязательно принудить весь мир писать на его паскаленедобейсике.
Здесь другое. Насколько я начал понимать, идея batu - гораздо больше, чем просто новый язык, от синтаксиса которого я, кстати, тоже отнюдь не в восторге. Здесь и концепция "все - объект", и разделение уровней семантики и представления... - вероятно, именно поэтому и название "
система Лада"
Причем, не то чтобы эти идеи были плохи сами по себе. Просто "по науке" полагалось бы изучить уже существующие реализации, объективно оценить их достоинства и недостатки, а только затем уже предлагать свое решение, четко понимая,
чем конкретно оно лучше существующих. Но именно этого мы от автора не можем добиться уже на протяжении 15 страниц.
хотя, а как тебя по другому называть?
