Отображение происходит в виде крякозяблев, увидеть можно в бутылке rt/11054, способ воспроизведения: 2) зайти в каталог /ADM 3) запустить LCS_RUN.exe 4) выбрать запускаемый модуль, например "Склад (учет товаров)" - запустить В программе в меню выбрать "Учет товаров" -> "Реестр накладных" -> в низу справа нажать "ОК" Сформируется список накладных (окно не отрисовывается) Можно зайти в любую позицию - документ формируется в кодировке DOS - шрифты подставить самостоятельно не смог
Нужно найти мои баги по БЕСТ, я, вроде бы, проводил какое-то исследование данного вопроса для БЕСТ+ 4. Там то ли двойная перекодировка, то ли ещё какая-то фигня. Совсем не помню :( Помню что что-то такое было :)))
> Нужно найти мои баги по БЕСТ Что-то не нашёл ничего
Про консоль - здесь http://bugs.etersoft.ru/show_bug.cgi?id=768 Вообще, я думаю, что запускать программу надо командой wineconsole.
> Вообще, я думаю, что запускать программу > надо командой wineconsole. В данном баге речь не о консольной программе
(In reply to comment #4) > > Вообще, я думаю, что запускать программу > > надо командой wineconsole. > В данном баге речь не о консольной > программе Ах, ну надо разбираться с используемым шрифтом тогда.
Небольшой тест: wine-etersoft-devel/fonts/oemtext Программа выводит символы от 0 до 255, используя OEM_CHARSET. Вывод различается в Windows и в WINE. Используется шрифт Terminal, но с другим шрифтом вывод также различается.
> Используется шрифт Terminal Имеется ввиду, что шрифт используется в тесте. Какой конкретно шрифт использует LCS_RUN.exe, я не разбирался.
Если сделать, чтобы функция GdiGetCodePage всегда возвращала CP_OEMCP, то тест работает как в Windows. В LCS_RUN.exe там, где до этого были кракозябры, выводится нормальный текст. Правда, разумеется, в некоторых других местах, где раньше был нормальный текст, появляются кракозябры.
Выложил патч. Добиться его принятия на winehq не удалось. Проблема в том, что при создании логического шрифта поле lfCharSet структуры LOGFONT вообще игнорируется. Вместо этого wine считает, что используется ansi charset. Патч добавляет проверку на OEM_CHARSET, и в случае если он указан в LOGFONT, использует это поле структуры.
Разве тот тест, что ты отправил показывает это: " Проблема в том, что при создании логического шрифта поле lfCharSet структуры LOGFONT вообще игнорируется. Вместо этого wine считает, что используется ansi charset. " наверное твой патч и не приняли из-за того, что он немного расходится с тестом по семантике...
Посмотрел ещё пару раз, дошло. Да, тест всё показывает, только надо было где-нибудь в + lf.lfCharSet = OEM_CHARSET; написать коммент, что wine, такой нехороший, всё равно ANSI выставит. А то как-то странно - ты в тесте заполняешь 4 поля, а проверяешь только 1. Может там и не Terminal и 12 вообще получается. А если так, то там проблема намного серьёзнее чем просто oem - не oem.
Ещё несколько замечаний: Если говоришь так: " The fsCsb is bitfield that is used as boolean value. If this is false the DEFAULT_CHARSET is using and the real charset is choosen through the current ANSI codepage. But this is mistake in case of the OEM charset. " то ты должен дать ссылку на msdn где так будет написано, либо сделать пачку тестов, которые подтверждают твои слова. Из того, что при создании, OEM_CHARSER заменяется на что-то другое, не следует что это произошло только из-за флага, выставленного в false. В этой баге нужно действительно много дополнительных тестов и не только на OEM. Одного теста с использованием Тахомы, где ты тоже проверяешь только поле charset явно не достаточно.
Принято. WINE@Etersoft 1.0.12 eter5/eter4
Отписался по заявке.
