Имхо это полный бред.
Особенно:
"..Нужна ли обычному пользователю консоль? Правильно, практически не нужна!.."
"..в koi8-r без проблем работает куча старых програм, но мы должны понимать, что с этим балластом нужно порвать как можно скорее, ..".
Статья явно флеймообзразующая, но во многом я с автором согласен.
Насчет обычных полнхователей - нафиг нужна консоль, когда можно кучу терминалов под иксами открыть. ИМХО, так намного удобнее.
Обычная рядовая статья.Кому-то может оказаться полезной.
Только вот знаменем размахивать с криками " УРЯЯЯЯ ГНОМУ !!!" было совсем необязательно.Или без этого уже никак ?
Я сижу на Мандрейке 9.0. Я там не нашел ни fonfdesc, ни mkfontscale. А директории /etc/font/font.conf вообще нет.
Это из каких пакетов? Как это установить?
Ну вот.Только что по ссылке из статьи рпмку скачал,поставил.
Установил в мандряке из дистра эволюцию.
Зашибись.Все на русском.
А теперь (блин,вы смеятся будете) буду думать как убрать весь хлам из зависисмостей который она мне поставила.
Не понравилась она мне чего-то.Кмайл и мозилла - больше ничего ненадо
(МНЕ !!! А кто и поэтому поводу флеймить начнет тот пусть идет ....)
an-ha
PS это я к тому что мужик хоть что-то написал дельное,а...(мысль закончите сами,а я 3.143доблить нехочу).
>>Я сижу на Мандрейке 9.0. Я там не нашел ни fonfdesc, ни mkfontscale. А директории /etc/font/font.conf вообще нет. Это из каких пакетов? Как это установить?
Я конечно могу быть неправ,но редхат 8 отличается от остальных дистров - так что к мандряку все это может и неподойти.В мдк фонты прописаны
в /etc/X11/XftConfig (правда в примере видимо ХМЛ какой-то ?).
И вобще.В мандрейке можно без плясок с бубном в DracConf'e установить шрифты.(из ХР достаточно взять мссансериф,ну или вроде того :)).
Тоеть все ТТФ так поставить можно.
Вдогонку к предыдущему.
mkfontdesk - ненадо искать,эти программы должны стоять в системе.
В консоли набираешь первые несколько символов и нажимааешь <TAB> .
Если в системе эти проги стоят,то баш заокнчит фрау.
К слову сказать все эти манипуляции из-под рута надо делать.Хотя я тут
дня два назад слышал авторитетное мнение что все и всегда должны сидеть под рутом. :)
an-ha
1) В Redhat используется fontconfig и поэтому необязательно добавлять шрифты
root'ом, достаточно класть из в каталог $HOME/.fonts (можно создавать там
директории). Для тех программ которые ещё его не используют нужно в $HOME/.xsession добавить
xset +fp $HOME/.fonts/ms,$HOME/.fonts/adobe
xset fp rehash
2) Консольные приложения которые неправильно работают с русским интерфейсом
можно попробывать запускать с англиским интерфейсом, для этого в .bashrc
добавляем
alias mc='LC_ALL=C mc'
3) В Xfree-4.3 раскладка клавиатуры переключается немного иначе
Section "InputDevice"
Identifier "Keyboard1"
Driver "Keyboard"
# Option "XkbModel" "logiinetnav"
Option "XkbLayout" "us,ru,de"
Option "XkbVariant" "winkeys"
Option "XkbOptions" "grp:ctrl_shift_toggle"
EndSection
У меня раньше с 4.2 было Option "XkbLayout" "ru" но в XFree86-4.2.99.3-1.20021223.1mdk перестало на англиский переключатся. Вообшем читаем README.XKB-Config README.XKB-Enhancing
4) Исходники gcc написаны на latin-1 а в utf-8 он занимает 1 байт, вот для русских документов это действительно проблема
/etc/font/font.conf - это надо fontconfig ставить из fcpackage, а первые 2 - тоже откуда-то беруться - смотри на freshmeat или sourceforge.net - там есть где-то раздельчик оп шрифтам.
/etc/font/font.conf - это надо fontconfig ставить из fcpackage, а первые 2 - тоже откуда-то беруться - смотри на freshmeat или sourceforge.net - там есть где-то раздельчик оп шрифтам. да и вообще это к TTF относится.
После копирования ttf шрифтов куда полагается (кстати, лучше копировать их в /usr/share/fonts/ttf ? тогда не нужно будет править /etc/fonts/fonts.conf), нужно запустить fc-cache для обновления кэша шрифтов во всех директориях. Если этого не сделать то можно не увидеть свой долгожданный шрифт в списке доступных. Для просмотра списка шрифтов доступных fontconfig можно воспользоваться fc-list.
дык это ж вопрос программ, которые это понимают или нет.
а так почти все функции WinAPI имеют два вида:
MessageBoxA - для обычных строк
MessageBoxW - для unicode
на уровне исходников все прописывается #define'ами
т.е. хочешь unicode - пиши в коде #define UNICODE и будет тебе счастье. жалко, что в юнисках с этим туго...
Ну вот, совсем другое дело (вот правильно отмодерировали ;) ).
И вообще по моему мнению ананимусам надо запретить посты оставлять, так как те кому надо, зарегистрируются, а для тех кто просто покричать пришел это будет слишком сложно ;)
дык туго-то не с программами. написать поддержку юникода в своей программе я тоже могу. а хотелось бы это видеть на более низком уровне. ведь strcpy ты не заставишь юникод копировать...
и про i18n в виндах я не слышал :) если тебе там надо локализацию - делаешь себе resource dll и подгружаешь динамически.
>а хотелось бы это видеть на более низком уровне. ведь strcpy ты не заставишь юникод копировать...
Под НТ - легко. Читай MSDN на предмет использования TCHAR. Там для всех строковых функций определены макросы, которые зависят от того, определен ли UNICODE. В принципе, копирование должно работать и в Win9x (извини, не проверял) - там проблемы взникнут при вызове функций API - надо будет перекодировать.
Что же касается топика - в меру интересная инфа. Редхатовцы может быть оценят. Я же пошел по другому пути: написал для "проблемных" софтин короткие скрипты, которые выставляют нужные LANG (ru_RU.KOI8-R например) и запускают соответствующую программу. Локаль же по-умолчанию стоит de_DE.UTF-8.
>дык туго-то не с программами. написать поддержку юникода в своей
>программе я тоже могу. а хотелось бы это видеть на более низком
>уровне. ведь strcpy ты не заставишь юникод копировать...
Что значит "написать поддержку юникода в своей программе я тоже могу"??? Как такая поддержка работала бы если библиотеки кот. программа использует не поддерживали бы юникод? Или может в gnome2 для копирования строк используют какой-то особенный очень сложный способ? По-моему для того чтобы "это видеть на более низком уровне" следует познакомиться с тем что уже сделали, а потом говорить что в юниксах есть а чего нет. В X'ах имхо проблемм с юникодом уже давно нету. Осталось только избавиться от старых библиотек.
Где проблеммы ещё есть - так это в консоли. Да и их полное решение уже не за горами. А про то какая юникодная консоль в виндах лучше вообще молчать.
>и про i18n в виндах я не слышал :) если тебе там надо локализацию -
>?делаешь себе resource dll и подгружаешь динамически.
Можно i18n-строки запихать в ресурсы программы. Тогда никаких "resource dll" не нужно. Но всё равно этот способ нтернационализации - просто настоящий геморрой. ИМХО в Линуксе всё это устроено *гораздо* лучше.
> Почему в Линукс UTF-8. Это, как я понял, не совсем полная версия
> юникода. Почему не сразу UCS-16? Какие для этого препятствия
> Разъясните пожалуйста.
Вот как раз UTF-8 это полная "версия юникода", в отличие от UCS-16 которая не позволяет отобразить *все* символы юникода. С UCS-16 просто гораздо легче работать т.к. каждому символу соответствует строго два байта, в то время как в UTF-8 - 1, 2 или 3 в зависимости от символа.
>Вот как раз UTF-8 это полная "версия юникода", в отличие от UCS-16
Вот даже в таком, казалось бы безобидном топике, и то: Наш линуксовый UTF-8 лучше и полнее этого масдайного UCS-16. И ведь не объяснили главную причину: UTF-8 обратно совместим с 7-битным ASCII. Поэтому в традиционно англоязычном линухе - это просто спасение. Да и для многих европейских языков использование УТФ позволяет существенно сократить объем текстовых файлов. Тогда как в с ног до головы интернационализированном Windows такая совместимость невостребована, и МС пошла по пути повышения производительности и упрощения введя UCS-16. Тигровый мех лучше смотрится на тиграх а не на коровах (c)Бернгард Гржимек.
>Вот даже в таком, казалось бы безобидном топике, и то: Наш линуксовый
> UTF-8 лучше и полнее этого масдайного UCS-16. И ведь не объяснили
> главную причину: UTF-8 обратно совместим с 7-битным ASCII. Поэтому в
> традиционно англоязычном линухе - это просто спасение. Да и для
> многих европейских языков использование УТФ позволяет существенно
> сократить объем текстовых файлов. Тогда как в с ног до головы
> интернационализированном Windows такая совместимость невостребована,
> и МС пошла по пути повышения производительности и упрощения введя
> UCS-16. Тигровый мех лучше смотрится на тиграх а не на коровах
> (c)Бернгард Гржимек.
Я кому-то яйца прищемил? Я про микрософт с виндовозом ни слова не сказал. А микрософтовские фаны уже тут как тут со своим придавленным самомнением. Если уж на то пошло то M$ решила не поддерживать юникод полностью только в обмен на возможность вычислять длину строк и т.п. как <число символов> * 2. Конечно, существенное упрощение! Почему-бы тогда не сделать сразу 32 бита на символ?
А говорить не обязательно. Важно то, что ты имел этим в виду. А имел ты в виду то, что написал во втором посте. Так что я был прав.
>А микрософтовские фаны уже тут как тут со своим придавленным самомнением.
Кто бы говорил. Своего нет, так хоть чужое обосрем. В этом все красноглазые скоты.
>Если уж на то пошло то M$ решила не поддерживать юникод полностью только в обмен на возможность вычислять длину строк и т.п. как <число символов> * 2. Конечно, существенное упрощение!
asaw, иксы это не только гном и кде. то, что сделали вторую надстройку над операционной системой (первая - сами иксы), которая поддерживает юникод, это очень круто. а я вот сижу под ion или под wmaker, не особо пользуюсь гномовыми прогами и совсем не пользуюсь кде-шными. зато пользуюсь консольными.
насчет нижнего уровня я уже сказал: когда я смогу написать tcscpy() и в зависимости от #define UNICODE у меня будет вызываться strcpy() или wstrcpy(), вот тогда будет круто.
еще раз повторю, что наличие высокоуровневых библиотек проблемы не решает. файл я по-китайски назвать не смогу ведь из консоли. а были б имена файлов внутри в utf-16 - мне бы не пришлось смотреть как у меня midc сортирует по алфавиту русские имена файлов.
высокоуровневое решение - это половинчатое решение. если админ по ssh не сможет просмотреть названия файлов, созданные юзверями из второго гнома, то это бардак а не ось.
utf-8 потому, что для английского языка по-прежнему получается 1 байт на символ. вроде бы это ограничение модели posix. хотя точно не уверен...
Я чего-то вас совсем не понимаю. Вы что, пишите на ассемблере в обход glibc? Или вам не нравится что в стандартной библиотке C нет поддержки UTF-8 (или utf-16 или чего там вам нужно)? Что такое высокоуровневая библиотека? glibc высокоуровневая? glib высокоуровневая? Где должна быть поддержка юникода? В glibc? В ядре (уверяю вас, она там есть!)?
Чем вас не устраивает использование лёгкой, переносимой и совсем не связанной с GUI glib2?
Почему у меня нет никаких проблемм с написанием программ работающих в Линуксе с UTF-8? Почему я сейчас сижу в mc в UTF-8-консоле и без особых проблемм просматриваю файлы с русскими названиями закодированными в UTF-8, что я не так делаю :-)? И почему вы считаете что поддержка юникода в библиотеке должна включаться с помощью "#define UNICODE"(почему она вообще должна там включаться, а не быть по умолчанию)???
>сижу в mc в UTF-8-консоле
все по поводу этого долго ругались, делали даже откат в koi8,
расскажи, пожалуйста, как все это делать. Можно ввиде статьи, как это сделал McMcc
Если в текстовом режиме всё равно все 65 тысяч символов показать нельзя?
Опять надо будет кодовые страницы переключать? Тогда в чём смысл?
Если такого смысла нет, то почему бы не юникодизировать только графические надстройки и программы, работающие под ними? А консоль не оставить бы в покое? Как оставила в покое MS досовские программы под cp866? Чтобы старые программы продолжали работать и новым не мешали?
Нет. Найдут шаловливые ручонки себе забаву. Не дадут покоя ни себе,ни окружающим. Блин.
> Если в текстовом режиме всё равно все 65 тысяч символов показать
> нельзя? Опять надо будет кодовые страницы переключать? Тогда в чём
> смысл?
Смысл в том, что можно одновременно показать _любые_ 512 (к примеру). Т.е. вы не обязаны иметь фиксированный набор из 512 символов. Это означает что можно свободно использовать несколько языков одновременно. Правда, при таком подходе в стандартном текстовом режиме теряются яркие цвета, но это исправляется если включить кадровый буфер (за одно можно и частоту обновления поднять), да и в виртуальных терминалах всё в порядке.
> Как оставила в покое MS досовские программы под cp866?
М$ это вообще оффтопик. И разве в этой конторе не попрощались с консолью навсегда?
> Нет. Найдут шаловливые ручонки себе забаву. Не дадут покоя ни
> себе,ни окружающим. Блин.
Не делайте скорых выводов, а то вас и вправду ламмером считать будут.