Конвертеры BMP изображений для программ навигации

Конвертеры BMP изображений для программ навигации.Предистория ----------------- Став недавно обладателем навигатора, меня, как любого обладателя

Оффлайн

Автор темы

Leserg

Звание: Ветеран

Команда сайта

Сообщений: 933

Создано тем: 79

Рейтинг: 8

Репа: (131|131|0)

Баллы: 1616

Был: 2024-05-09 15:29

Лайков: 148

Конвертеры BMP изображений для программ навигации.

Предистория
-----------------
Став недавно обладателем навигатора, меня, как любого обладателя подобных электронных устройств, посетила мысль о небольшой переделке данного девайса под себя, т.е. расширения функциональных особенностей аппарата и изменения графической части (кнопочек, значков, фоновых изображений и .т.п.) интерфейса самой программы навигации. С первой частью я справился довольно легко, превратив свой навигатор в мультимедийный комбайн. А вот со второй частью возникла проблема: графическая часть интерфейса программы навигации (iGO) состояла на 95% из изображений в специальном формате BMP (RLE Bitmap). Этот формат оказалось не поддерживает ни одна программа обработки изображений Windows. Перепробовал множество различных вьюверов, конвертеров, редакторов, но ответ получал один: "Невозможно открыть данный файл. Возможно он поврежден или имеет неверный формат." В принципе, можно было бы использовать обычный BMP формат для графической части, но, во-первых, файлов было более 1000 и найти среди них тот, который я решил изменить (или заменить), не видя при этом самих изображений, оказалось непосильной задачей; во-вторых, этот RLE Bitmap формат изображений был очень компактным, по сравнению с обычным BMP, который мы все знаем. Например, в обычном BMP формате размер одного из файлов составляет 73,8 Кб, а в формате RLE Bitmap всего лишь 4,41 Кб. Как видите, разница очень существенная.

На русскоязычных форумах, посвященных навигаторам и программам навигации, скиноваятели поступали следующим образом, сжимали изображение в формат JPG, а затем меняли расширение файла на BMP. С программой навигации такой фокус проходил, но для меня оставалась загадка нахождения нужного файла среди тысячи (не перебирать же все подряд вручную). В конце концов, после недельного перелопачивания форумов, промелькнул один инструмент MioMap & IGO BMP TOOL, 2006 года выпуска, автор VBLocalize.0.html v1.1.0.0, но после пробного перевода и компиляции программа отказалась запускаться. Но все же со счетов его сбрасывать нельзя, им можно сделать доводку окончательного перевода (она позволяет немного удлинить строки за счет сокращения имени элемента управления).

Кто ищет, тот всегда найдет!

25 августа 2012 - 15:09 / #1
Оффлайн

Автор темы

Leserg

Звание: Ветеран

Команда сайта

Сообщений: 933

Создано тем: 79

Рейтинг: 8

Репа: (131|131|0)

Баллы: 1616

Был: 2024-05-09 15:29

Лайков: 148
Немного теории и практики.
-------------------------------------
Опишу немного ход работы и свои рассуждения.

Показать / Скрыть текст
Программа "MioMap & IGO BMP TOOL". После перевода языкового файла (Russian.lng), запуска программы и выбора русского языка, в интерфейсе вместо символов кириллицы появились .0.htmlтемы форума. Но я иду по этому пути только в самом крайнем случае, когда действительно ничего нельзя сделать и остается только одно: хирургическое вмешательство в систему.

Итак, если вы собрались переводить приложение на языке Visual Basic 5.0/6.0, то вам необходимо знать, что строки в этих программах представлены двумя кодировками: ANSI - для строк элементов формы и Unicode - для жестко-закодированных строк. Эта информация поможет при поиске необходимой строки для перевода в HEX-редакторе. Если вы не нашли какую-либо строку в кодировке ANSI, значит нужно выполнить её поиск в кодировке Unicode или наоборот.

Еще, по поводу Unicode в библиотеке MSDN написано: "В Visual Basic 6.0 строки во внутреннем представлении являются знаками Юникода, но отображаются с помощью кодовых страниц Windows." Таким образом, если разработчик приложения явно не указал используемый набор символов для отображения текстовых строк, то по умолчанию компилятором используется локаль OC Windows, в которой запущена среда разработки и в которой создается программа (обычно с кодовой страницей 1252).

Теперь посмотрим информацию о программе (это можно сделать в VBLocalize.0.html v1.1.0.0, то учтите, что он не меняет указатель длины строк и, в последствии, вам вручную все равно придется это делать в НЕХ-редакторе (в большинстве случаев). Именно по этой причине, я предпочитаю сразу делать перевод НЕХ-редактором, чтобы контролировать каждую строку, а не искать потом иголку в стоге сена. Также, работа с НЕХ-редактором требует от вас внимательности, терпения и усидчивости. Если вы не обладаете этими качествами, то можете даже не браться за это дело.

Строка Unicode. В указанном выше примере я привел строку " Pixel(s)". Она является жестко-закодированной и языковом файле отсутствует, поэтому её необходимо перевести в файле программы. Обратите внимание, в строке Unicode один символ занимает два байта. Т.к. символы латиницы находятся в начале этой кодовой страницы, то в текстовой части Нех-редактора они отображаются без изменений, т.е. их можно вводить с клавиатуры (не забывая, что один символ - два байта). А вот с символами кириллицы (и другими языками) такой фокус не пройдет. Необходимо вводить код символа в шестнадцатеричном виде в правой части НЕХ-редактора. Конвертировать русский текст в шестнадц. символы Unicode вам поможет замечательный инструмент 1251.0.html to HEX. Здесь, также не забывайте про длину строки и указатель. Оригинальная строка имеет длину 9 символов (включая символ пробела перед словом). Так как на один символ в юникоде задействовано 2 байта, то 9*2=18 байт. В шестнадцатиричной системе счисления - 12. Что мы и видим в редакторе. Я перевел это выражение так: " пикс.". Его длина 6 символов. Для юникода потребуется 6*2=12 байт. В шестнадцатиричной системе счисления - 0С. Оставшуюся часть строки я заполнил нулями. Учтите, что в текстовой части НЕХ-редактора вместо выражения " пикс." будет " ?8:А", но в программе отображение будет верное.

Итак, со строками разобрались. А как же быть с кодировкой и отображением кириллицы, о чем было сказано в начале моего повествования? Здесь снова придеться сделать небольшое отступление. Если вы занимаетесь программированием, то наверняка знаете, что для каждого элемента управления (Label, Button, CheckBox и т.д.), в его свойствах, можно выбрать параметры шрифта: размер, начертание, название шрифта и, самое главное, установить набор символов. По умолчанию, при создании программы в среде Visual Basic 5.0/6.0, для всех будущих элементов интерфейса установлен шрифт MS Sans Serif с набором символов, который в ОС Windows является основным.

Те, кто не занимается программированием, теперь тоже это знаете . И скорее всего вам знакомо это окошко выбора свойств шрифта, не правда ли? Так вот, нас интересует именно свойство "Набор символов". Чтобы переводимая нами программа правильно отображала символы кириллицы, для каждого элемента управления необходимо установить кириллический набор символов. Если мы создаем программу, то сделать это на этапе программирования не составит труда, а как быть с уже готовой программой?

Для этого нам понадобится:

1) НЕХ-редактор (куда же без него).

2) Стандартные названия шрифтов, которые могут применяться при программировании. Один мы уже знаем точно - это MS Sans Serif. Еще могут быть:Arial, Tahoma, Verdana, Courier (Courier New). Я перечислил основные, могут быть и другие. Все зависит от фантазии разработчика.

3) Знание того, каким образом в коде программе обозначается признак кириллического набора символов и, где он прописан. Ему, согласно спецификациям шрифта, соответствует десятичное число 204. Тем, кто занимается переводом, оно очень хорошо знакомо. В шестнадцатиричном виде оно занимает один байт и записывается как СС. Это не то, что вы подумали, а мнемоническое отображение слова CyrilliC.

Теперь, наша задача найти в коде программы все места, где указано название шрифта и в его свойствах изменить указатель набора символов на кириллический, т.е. на СС. На примере программы "MioMap & IGO BMP TOOL" я поиске НЕХ-редактора ввел название шрифта MS Sans Serif и нажал ОК (поиск необходимо осуществлять в ANSI кодировке). Для данной программы нашлось одно совпадение:

Чуть ниже, в текстовой части редактора видно слово Tahoma. Это нам намек на то, какой шрифт нужно искать далее. Конечно же нужно перебрать все стандартные шрифты. Сейчас будем менять набор символов для этого шрифта. Для начала познакомимся с шестнадцатиричным форматом записи свойств шрифта. Посмотрите на следующий рисунок:

Эта последовательность байт и их позиция, относительно названия шрифта, постоянна для всех элементов управления в коде программы. Это не значит, что в вашей программе, которую вы будете переводить, будут именно эти значения байт. Все зависит от выбранных разработчиком свойств шрифта. Но позиция байта, отвечающего за набор символов, всегда будет постоянной относительно названия шрифта - 10 байт от первой буквы.

Наконец, можно смело вместо ноликов записать СС. Такую операцию необходимо выполнить для всех найденных шрифтов в коде программы. В данной программе автор использовал три шрифта: MS Sans Serif, Arial и Tahoma.

Затем сохраните изменения, сделанные в файле. На этом этапе будьте очень внимательны. Малейшая оплошность и программа станет неработоспособной. Смотрим, что у нас получилось, запустив программу на выполнение.

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

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

Но теперь осталось сделать самую малость, внести в реестр следующую запись:
```
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionFontSubstitutes] 
 "Arial,0"="Arial,204"
```
Это так называемая подмена наборов символов. При изменении набора символов в НЕХ-редакторе, мы видели, что в программе используется нулевой набор символов (00 нех), т.е. нейтральный (а в нем нет символов кириллицы). После перезагрузки ОС, получим корректный вариант:

Пожалуй, неплохо. А вы как думаете?

После прочтения этого материала, у вас, дорогой читатель, может возникнуть вопрос: "А зачем было столько страдать, если можно было с самого начала применить патч, выполняющий подмену кодовых страниц Windows?" Я отвечу так: "Мне было очень интересно найти решение этого вопроса." Именно поэтому я и занимаюсь русификацией. Да, вопрос не решен полностью, только частично, но может своими исследованиями, я подтолкну вас на решение очередной головоломки.

P.S. Теперь осталось найти место в коде программ, написанных на Visual Basic, где указываются языковые параметры, установленные по умолчанию для всего приложения. Тогда, я думаю, можно окончательно закрыть этот вопрос.
Кто ищет, тот всегда найдет!
27 августа 2012 - 03:41 / #2
Оффлайн

pp0312

Звание: Бывалый

Мастер

Сообщений: 172

Создано тем: 24

Рейтинг: 4

Репа: (30|30|0)

Баллы: 51

Страна: не указана!

Был: 2024-05-15 17:39

Лайков: 25

Сама прога мне без надобности в виду отсутствия навигатора ,а вот урок по HEX супер .Хотя для меня пока

27 августа 2012 - 04:57 / #3
Оффлайн

Автор темы

Leserg

Звание: Ветеран

Команда сайта

Сообщений: 933

Создано тем: 79

Рейтинг: 8

Репа: (131|131|0)

Баллы: 1616

Был: 2024-05-09 15:29

Лайков: 148

Немного теории и практики.
------------------------------------

Продолжу тему русификации программ на Visual Basic 5.0/6.0.

Показать / Скрыть текст

Была задумка найти в коде приложений место, отвечающее за используемый по умолчанию набор символов для всей программы, если он явно не был указан при её создании.
Мои изыскания привели к следующему: в программах на Visual Basic 5.0/6.0 за языковые свойства (шрифт, кодовая страница, набор символов) отвечает ран-тайм (RunTime) библиотека MSVBVM60.DLL. Этот файл по умолчанию устанавливается автоматически при установке самой ОС (Windows XP, Vista, 7), т.е. является системным. Если по каким-то причинам этого файла в системе нет (или он не зарегистрирован), то VB программа работать не будет. Так вот, в этом файле и заданы языковые установки по умолчанию - язык LANG_NEUTRAL (идентификатор 0х0С00) и локаль LOCALE_NEUTRAL (идентификатор 0x0000). Параметру LOCALE_NEUTRAL соответствует кодовая страница СР1252 (десятичный код - 0), а в ней, как известно, символов кириллицы не наблюдается. Нам же необходимо, чтобы программа использовала кодовую страницу СР1251 (десятичный код - 204) с кириллическим набором символов. Как быть? Ответ уже был дан мною ранее. Необходимо использовать так называемую подмену (или замену) шрифтов. Для этого в реестре Windows добавляется значение (Кстати эта ветка реестре как раз для этого и предназначена. В переводе на русский "Font Substitutes" означает - Замена шрифтов.):

HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionFontSubstitutes
"Arial,0"="Arial,204"

Arial - это название шрифта, для которого мы хотим выполнить замену набора символов.

При этом происходит следующее: при обращении программы к латинской кодовой странице шрифта (Arial,0) вместо нее выдается кириллическая кодовая страница (Arial,204) - чего мы и хотели добиться. На сегодняшний день этот способ представляется самым корректным и надежным. Таким способом можно назначить замену любому шрифту, который использует программа. После правки реестра обязательно необходимо сделать перезагрузку системы, чтобы изменения вступили в силу.

Вывод: если в при переводе программы нет возможности задать русский набор символов (204 Dec = CC Нех) или не для всех элементов управления явно заданы параметры шрифта, чтобы выполнить такую операцию, то можно завершить дело правкой реестра.

Вы можете возразить и ограничиться только правкой реестра, а в самой программе сделать только перевод. Можно и так, криминала в этом нет. Но предлагаемый мною вариант является наиболее правильным. Подойдите к этому вопросу не с позиций переводчика, а с позиции программиста. Вы проектируете приложение, добавляете на форму различные элементы и вводите для них надписи. Вы же не будете давать русские названия латинскими буквами?! Нет, вы выберете шрифт и укажете набор символов - Кириллица. Вот и при переводе получается такая картина - вы перевели название элемента на русский, а шрифт не исправили. Вот программа вам и показывает кракозябры. Поэтому, если есть возможность исправить шрифт, то нужно ею воспользоваться. Тем более, что после такого корректного перевода, программа будет правильно отображать кириллицу на системах, где русский язык не является языком по умолчанию.

--------------------------

При переводе второй программы "iPAQ 31x Image Explorer" я сначала в НЕХ-редакторе выполнил замену набора символов на кириллицу, а затем занялся переводом. Это дало мне возможность тестировать перевод на своей немецкой системе, а также показало, где и для каких элементов отсутствуют параметры шрифта и для каких из них нужно будет делать замену в реестре Windows (это оказался вездесущий шрифт Arial).

Наибольшую сложность при переводе программ Visual Basic 5.0/6.0 создают меню и заголовки таблиц. Их почти невозможно удлинить для русского текста. Например, меню "Save as..." имеет длину в 10 знаков (с учетом символов пробела). На русском надо написать "Сохранить как..." - 16 знаков. Что делать? Можно написать без троеточия в конце, т.е. "Сохранить как" - 13 знаков. Или так "Сохранить..." - 12 знаков. А вот ещё к примеру другие пункты меню "Help" - 4 (на русском "Справка" - 7), "About" - 5 (О программе - 11) - и т.д. В любом случае, как лучше сделать перевод необходимо смотреть исходя из местных условий кода программы.

Немного упростить эту задачу позволяет инструмент "VBLocalize v1.1", но здесь важно понимать, как он это делает. Иначе, после перевода в нём, вы получите неработоспособную программу. Я не знаю, чем руководствовался создатель VBLocalize, но количество доступных символов в строке его творение показывает с учетом названия элемента управления. Когда смотришь на строку, в которой всего 5 символов (к примеру строка меню &Help), а редактор тебе сообщает, что в ней доступно аж 10 знаков, то можно подумать, что с переводом проблем не будет. Да, с переводом не будет, но будут проблемы с программой.

Давайте разберемся (в примере показана строка "&Help"):

Хорошо видно, что текущая строка занимает 5 байт. Редактор нам показывает, что максимальная длина строки может быть 10 байт. Откуда взялись еще 5 байт? Эта строка формата ANSI, а вы уже знаете, что в ней 1 символ (знак) занимает 1 байт. Допустим в строке может быть 10 знаков. Перевод желательно делать без клавиш доступа (&), так мы экономим один символ, что крайне важно при переводе программ Visual Basic 5.0/6.0. Итак, на русском языке этот пункт меню будет называться "Справка". В этой строке 7 знаков, т.е. она будет длиной в 7 байт, а это меньше 10 максимальных. Но прежде, чем писать перевод, давайте посмотрим в НЕХ-редакторе, действительно ли в коде программы есть место для 10 байт вместо 5. Адрес этой строки вы можете взять прямо из редактора VBLocalize, первая колонка - 0001В359:

Посмотрите внимательно на код программы возле строки "&Help", вы там видите где-нибудь свободное место? Если ориентироваться на правую половину с текстовой информацией, то какие-то пустые места там вырисовываются. Но самое главное это левая половина, где представлен код программы в шестнадцатеричном виде. И вот здесь вы не найдете пустого места. Что мы имеем? Строка "&Help" действительно занимает 5 байт. Об этом говорит указатель длины, находящийся перед ней по адресу 0001В359. Если посмотреть в текстовую часть редактора, то перед словом "&Help" находится слово mHelp. Как ни странно, но в нем тоже 5 знаков и в правой части редактора видно, что оно также занимает 5 байт и перед ним, также находится указатель длины (адрес 0001В34F). Уж не это ли слово инструмент VBLocalize подсчитал за дополнительные байты? Что это вообще такое, и что обозначает?

Если вы программист, то сразу ответите на этот вопрос. Если нет, то я вам скажу. Любая программа состоит из множества различных элементов, у которых есть имена. Эти имена (обычно) даются таким образом, чтобы легче было ориентироваться в листинге программы, а при её отладке сразу было видно в каком модуле произошел сбой. Возвращаясь к нашей строке "mHelp" можно понять, что речь идет о пункте меню "Справка" (m - сокращение от menu, help - справка). Вот пример листинга программы с этим пунктом меню, где это хорошо видно:

Именно так это и записано в шестнадцатеричном коде программы:

Обратите внимание на пустые (00) байты разделители между указателями длины строк и между строками - они также важны. Если вы думаете, что длину строки можно увеличить за счет этих пустых байт, то вы глубоко заблуждаетесь. Это как пробелы между словами в предложении. (Еслинаписатьпредложениебезпробеловмеждусловами,вамудобнобудетчитать?)

Надеюсь, теперь вы поняли, что "mHelp" - это имя элемента меню. Естественно имя этого элемента можно переименовать. Именно так и поступает инструмент "VBLocalize v1.1", но делает это некорректно. Если не знать того, о чем только что я рассказал, то переводом можно полностью затереть имена элементов. В результате программа станет неработоспособной (так и произошло при моем пробном переводе - тогда я еще таких тонкостей не знал). Посмотрите как это происходит (анимационное изображение):

Как видите, надпись можно увеличить за счет изменения имени элемента меню, сдвигая указатель Caption влево, увеличивая тем самым длину строки с надписью. Вы видите, что этот пункт меню я перевел как "Справка". Если бы длина строки оказалась равна 10 байтам, то от имени элемента меню ничего бы не осталось. После перевода пункта меню, само имя элемента меню стало короче - mHe. Внимательно посмотрите на рисунок еще раз.

Так действует инструмент VBLocalize. Если же вы будете удлинять строки самостоятельно в НЕХ-редакторе, то не забывайте менять значение указателя длины для каждой строки (имени элемента и надписи). Напоминаю, что длина строки указывается в шестнадцатеричном формате, а не в десятичном. Для перевода значений из десятичного формата в шестнадцатеричный, воспользуйтесь Калькулятором Windows в режиме "Инженерный".

Еще важный момент, нельзя допускать совпадения имён элементов, если выполняете удлинение строк за счёт них. Неважно каким инструментом это делается, или VBLocalize, или вручную с помощью НЕХ-редактора. Иначе в работающем приложении возникнет конфликт из-за одинаковых идентификаторов (имен) и его работа завершится ошибкой. Особенно такой промах можно допустить при переводе большого приложения с многочисленными меню и подменю. Поэтому важно следить за этим или искать альтернативные варианты перевода.

Еще раз повторю, что инструмент VBLocalize показывает максимальную длину строки с учетом имени элемента, для которого она используется. Желательно переводить так, чтобы переведенная строка была меньше или равнялась длине исходной. Если это сделать невозможно, то рассмотрите вопрос её удлинения за счет имени элемента. Просто нужно быть очень внимательным и следить за адресным пространством, в рамках которого находится тот или иной элемент интерфейса программы.

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

Кто ищет, тот всегда найдет!

1 сентября 2012 - 19:42 / #4
Оффлайн

Автор темы

Leserg

Звание: Ветеран

Команда сайта

Сообщений: 933

Создано тем: 79

Рейтинг: 8

Репа: (131|131|0)

Баллы: 1616

Был: 2024-05-09 15:29

Лайков: 148

Работа по русификации завершена.

Спасибо всем за внимание!

Кто ищет, тот всегда найдет!

3 сентября 2012 - 23:11 / #5