CP1251 - латиница вместо кириллицы

Отпиши пожалуйста если найдешь ответ где нибудь в другом месте.

Уточнять надо детали, тут не все знают что такое LabView и где оно пишет тексты. Это вывод в терминал? Или это нативное X11-приложение? Или это скрипты для какого-то гуи интерпретатора? Или это запуск win32-проги через wine?

Это нативное графическое приложение.

Что тогда значит «переносимость на линукс» если оно и так нативное?

Где хранятся «тексты»? Может их сконвертировать?

метапрог приди, тут у тебя друг вендузятик =)

https://labviewwiki.org/wiki/LabVIEW_configuration_file/Fonts

оно?

Переносимость в данном контексте - из одного исходного кода (графических диаграмм, но это не важно) можно собрать приложение как для Windows, так и для Linux платформы. Тексты прошиты прямо вовнутрь диаграмм. Вопрос их загрузки через подгружаемые ресурсы отдельный и легко не реализуемый.

Чисто технически в Labview есть возможность экспортировать все текстовые ресурсы, а потом импортировать назад (через некое подобие xml), но (вот сюрприз!) импорт utf-8 толком не работает, выдавая ошибки формата на корректных, на мой взгляд, строках.

https://labviewwiki.org/wiki/LabVIEW_configuration_file/Fonts

Увы, не оно. Фонты я могу задавать любые, но все равно остаются умляунты. Разве что тащить (откуда-то) свой собственный фонт с подмененными буквами, но это как-то совсем уже странно будет…

ну тогда только много годичной давности советы, сконвертить все тексты

разбираться без самой вьювы лень

Кирилический шрифт пробовал? Не «шрифт с кирилицей в том числе» (юникодный), а именно кирилический с 8-битными кодами символов. Вроде бы в старых версиях винды были типа «Arial Cyr» - это именно отдельный шрифт, а не свойство к Arial.

Из-за проблем с кодировками у нас не получилось гонять и компилировать исходники Метапрога на линуксовой версии Лабвью. Мы решаем эту проблему, используя Wine.

А вообще хорошо б доделать Метапрог и перейти уже на него. Метапрог-прототип 42

Что у тебя за софт на лабвью?

Да, это тот путь по которому не хотелось идти, но в итоге попробовал и не работает. При установке Arial Cyr просто пустые квадратики вместо кириллицы.

Управление удаленным устройством по udp, получение данных, DSP-обработка, отображение всяких графиков и т.п.

Ну, раз так то видимо проблема и правда не в шрифте, а в неподхватываемой кодировке. Наверно где-то внутри, при определении кодировки в windows-стиле (т.к. ttf), он не умеет правильно интерпретировать строку вида «ru_RU.CP1251» и берёт latin-1 для всего непонятного.

Как вариант обойти проблему костыльным способом: берём Arial Cyr, патчим его чтобы софт считал его latin-1 шрифтом (видимо где-то в заголовках кодировка указана), а буквы оставляем русские.

А пакет ubuntu-restricted-extras доустановить не пробовал? Так, в порядке бреда, ибо там шрифты а-ля форточки с eula.

Может у тебя те же проблемы, что и у Eddy_Em - у него недавно в иксах поломался вывод кодировки в koi8-r при правильно выставленной локали Поломалась кодировка после обновления

Если так, попахивает, что тихо и незаметно в линуксе (в иксах) сломали локали, отличные от utf-8

У тебя только Labview так себя ведет или другие программы с cp1251 и вообще не utf8 тоже?

Изменения локали мало. Нужны шрифты в кодировке cp1251 для X11. Точно такая-же проблемма возникает с запуском старых программ в кодировке koi8-r. Пока не доставишь шрифтов с нужной кодировкой - показывает латиницей с умляутами. Xorg вполне понимает шрифты в кодировке cp1251

Оно ttf шрифты использует, рисует видимо само и в иксы шлёт готовую картинку. Там что xorg-шрифты ни при чём.

Нам идейка пришла. А что, если просто заменить в бинарных лабвьюшных файлах кириллицу транслитом? Для этого размеры структур менять не нужно. W&glqdetx, kone}no, budet stra{no, zato sober$tsq, a tam uve movno prawitx potihonxku ;)

тут не все знают что такое LabView

Громкий неприличный смех, переходящий в ржание

здесь можно что-то сделать?

Обратиться в поддержку LabView не вариант?

Зачем тогда вообще нужны форумы?

Странные товарищи пошли по своему пути что и получили то что хотели закопав свою стюардессу что была без этого бага , но не удобного и не выгодного им создателя сами на себя жалуются это ли не успех?

А как отделить простые байты от «текстовых»?

Только эвристикой, увы. Искать цепочки из 0x80–0xff, 0x20 и чего там ещё в идентификаторах встречается. Всё, что вокруг — игнорировать. Немногие ложные срабатывания фиксить руками.

Если есть хоть какие-то сведения о формате, то будет сильно проще ;)

Хм, а почему вот Мы поковыряли вікно чату.vi из 12-й версии и видим там вперемешку строки в CP1251 и UTF-8? Это metaprog к тому моменту уже попытались безуспешно что-то включить для совместимости с линуксовой версией, или так изначально было во всех файлах?

Ну и, в принципе, строки предваряются байтом с длиной. Этого уже достаточно для почти 100%-ного угадывания, только UTF-8 отфильтровывать не забывайте, раз он там есть ;)

Я находил что то для разбора формата, но вот незадача, оно на LabView %)

Я находил что то для разбора формата, но вот незадача, оно на LabView %)

а как же неоспоримое преимущество LabView над «примитивными текстовыми язычками» – «в графических диагармах все очевидно»

Я не собираюсь его изучать.

Логично.

Вот, кстати, обдумывание парсера натолкнуло Нас на интересную мысль.

Допустим, стоит задача использовать для n начальных символов более узкий диапазон символов (поскольку мы точно знаем, что в начале некоторых символов быть не может), а дальше диапазон пошире.

В императивных языках с переменными в подобных случаях заводится переменная-флаг: допустим, в начале она isPrefix=true, по достижению определённой точки — будь это третий символ, символ . или любое другое, более сложное условие — выставляем isPrefix=false. Ключевой момент тут в том, что условие может быть сложным и трудновычислимым, и выполнять его на каждой итерации — не комильфо, надо именно запомнить ;)

В функциональных языках для этого прибегают к лютым извращениям; в простейшем случае — так же гонять флаг по каждому вызову рекурсивной функции, обычно просто передавая его, но в некоторый момент поменяв. Либо же по достижению точки передать дальнейшую обработку в другую функцию, что может привести к дублированию кода и нарушению DRY.

Любопытно увидеть реализацию такого алгоритма на Метапроге ;) Для большей конкретики, вот точное условие: в префиксе ищем символы из 0x20|0x2e|0x80–0xff, по достижению 3-го символа или 0x2e — дополняем диапазон 0x41–0x7a, и больше не выполняем эти проверки, а проверяем только одно значение ;) Дерзайте, этот алгоритм в изменённом виде пригодится потом в парсере!

Он сам не знает,что такое labview.