Проблемы с отображением
При открытии отображается окно "Ошибка помощи". Содержание помощи отображается не очень корректно, но информация присутствует вся. Панель инсрументов не работает и выглядит некорректно
Причём окно "Ошибка помощи" открывается только после того, как winhelp запустится, прочитает справку и выведет её на экран.
В бета-версии 1.0.9 окна с сообщением об ошибке не возникает.
Сейчас помощь открывается корректно, но появились проблемы со шрифтами, см. скрин. wine-etersoft-sql-1.0.9-alt0.M41.11 libwine-gl-1.0.9-alt0.M41.32 libwine-1.0.9-alt0.M41.32 wine-1.0.9-alt0.M41.32
Created attachment 861 [details] скрин
На данный момент баги, похоже две. Первая с запуском, собственно, помощи. Если запустить через ww со свежей склонированной копией репозитория, то возникает сообщение с окошком "Ошибка помощи". А в консоль пишется о падении с бэктрейсом =>0 0x7ef05128 WINHELP_GetCaption+0x27(wpage=0x33fda8) [/home/mibori/Projects/wine/programs/winhlp32/winhelp.c:547] in winhlp32 (0x0033fba8) 1 0x7ef05a7a WINHELP_CreateHelpWindow+0x74c(wpage=0x33fda8, nCmdShow=0, remember=1) [/home/mibori/Projects/wine/programs/winhlp32/winhelp.c:688] in winhlp32 (0x0033fd88) 2 0x7ef060b7 WINHELP_OpenHelpWindow+0x67(lookup=0x7eef61fe, hlpfile=(nil), val=0, wi=0x7ef1f860, nCmdShow=0) [/home/mibori/Projects/wine/programs/winhlp32/winhelp.c:772] in winhlp32 (0x0033fdb8) 3 0x7ef08e45 WinMain+0x2f9(hInstance=0x7eef0000, prev=(nil), cmdline="", show=0) [/home/mibori/Projects/wine/programs/winhlp32/winhelp.c:1710] in winhlp32 (0x0033fe38) 4 0x7ef0b7a6 main+0x10a() [/home/mibori/Projects/wine/dlls/winecrt0/exe_main.c:48] in winhlp32 (0x0033feb8) 5 0x7ef0b682 __wine_spec_exe_entry+0x6e(peb=0x7ffdf000) [/home/mibori/Projects/wine/dlls/winecrt0/exe_entry.c:36] in winhlp32 (0x0033fef8) 6 0x7b881a7c start_process+0xe4(arg=(nil)) [/home/mibori/Projects/wine/dlls/kernel32/process.c:915] in kernel32 (0x0033ffe8) 7 0xb7e6bcc7 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) в winhlp32 т. е. помощь посмотреть не удаётся Если запускать, через wine то окошко помощи выводится. И как раз там неверное отображение текста -- это вторая ошибка. Интересует, чем отличается wine от свежего ww.
по строчкам канала process: trace:process:CreateProcessW app (null) cmdline L"winhlp32.exe -x" trace:process:find_exe_file looking for L"winhlp32.exe" trace:process:find_exe_file Trying native exe L"C:\\windows\\system32\\winhlp32.exe" trace:process:CreateProcessW starting L"C:\\windows\\system32\\winhlp32.exe" as Win32 binary (0x10000000-0x10011000) понятно, что делается попытка запустить winhlp32.exe -x если мы запускаем ww winhlp32.exe -x, то получаем падение. если запускаем wine winhlp32.exe -x, то получаем: <wine@cellar bottle 1c77/1c7727-night>$ wine winhlp32 -x fixme:ntoskrnl:IoRegisterDeviceInterface 0x111770 {608225bc-766b-40a8-b8a4-d96bc999ae35} <null> 0x111970 fixme:ntoskrnl:IoRegisterDeviceInterface 0x1117e0 {10d60713-fb4c-4bb1-941b-44b79d25af8b} <null> 0x11113c fixme:ntoskrnl:IoSetDeviceInterfaceState (null) 1 и висим. Впрочем, падение проявляется и без параметра -x. Нормальное поведение без параметра -x -- это запустить диалоговое окно открытия файла .hlp (что и происходит в случае, если мы запускаем с wine)
c wwo падает, но немного по-другому. падение с ww поисходит в WINHELP_GetCaption: static char* WINHELP_GetCaption(WINHELP_WNDPAGE* wpage){ if (wpage->wininfo->caption[0]) return wpage->wininfo->caption; return wpage->page->file->lpszTitle; } из-за того, что wpage -> page == 0
я пришел к тому, что причина падения кроется в этом коде из WinMain winhlp32: if (*cmdline) { ... hlpfile = WINHELP_LookupHelpFile(cmdline); if (!hlpfile) return 0; } else hlpfile = NULL; в hlpfile хранится структура описывающая .hlp-файл если вместо hlpfile = NULL подставить hlpfile = WINHELP_LookupHelpFile(cmdline); то, winhlp32 не будет падать, а поругается на то, что .hlp-файл не найден, и откроет диалоговое окно Open file при этом файл открывается и можно решать проблему с некорректным отображением букв. Однако это изменение не работает в 1C. параметр -x "приказывает" winhlp32 запуститься скрыто. какая в этом логика я пока не понял. Кроме того 1С никак не передает в командной строке какой именно файл помощи открывать. И как оно на самом деле передается пока не выяснил.
Попытки вручную по коду проанализировать почему все-таки на самом деле происходит падение, не увенчались успехом. На данный момент, версия wine, запускаемая через "wine" -- это 1.0.9-eter42. Через git откатился до 1.0.9-eter34.1. Падение всё равно проявляется. Из этого следует думать, что проблема никак не решается на уровне исходников: т. е. нет ни одного коммита приводящего к падению winhlp32. Проблема, возможно, на уровне сборки. Далее буду решать проблему с неправильным отображением букв. Следующий патч -- способ заставить winhlp32 отображать .hlp-файл на собственных исходниках без падения...
Created attachment 1083 [details] патч
Изменение шрифтов через реестр ни как не помогает. И, скорее всего, не должно помогать: если взглянуть на приаттаченый скриншот, то искажение можно видеть также и в заголовках. Попробую проанализировать работу от DrawText.
(In reply to comment #12) > Изменение шрифтов через реестр ни как не > помогает. > > И, скорее всего, не должно помогать: если > взглянуть на приаттаченый скриншот, то > искажение можно видеть также и в > заголовках. > > Попробую проанализировать работу от DrawText. Это не тот уровень совершенно. Проблема либо в кодировке исходного текста, либо в особом названии шрифта, который используется. Но всё это можно увидеть гораздо раньше.
при помощи Help & Manual 5 (http://www.ec-software.com/) и Microsoft Winhelp compiler (там же скачать можно) удалось создать русский hlp файл, в котором не искажается текст. Попробую сравнить канал font искажаемого и неискажаемого файла и попробывать создать файл с искажением.
В 1С-овском hlp-файле используется шрифт (ARIAL CYR, 9) с нестандартным размером отступа между строк (он уже обычного). Попытка перекомпилировать этот файл в просто (Arial, 9) или поправить отступ, дает hlp-файл, который отображается "вопросиками". Попытки прописать в реестре, чтобы вместо Arial CYR отображался просто Arial, также ничего не дают.
Нужно анализировать, какой шрифт запрашивается у шрифтового движка, с какими параметрами.
По-моему, говорить о проблеме со шрифтами - это не совсем верно. Вот что сыпется в трейсы функции ExtTextOutW: trace:font:ExtTextOutW 0x1e0, 21, 422, 00001004, 0x33ec40, L"Iaoaaaiiua", 10, 0x33e8e4) ... trace:font:ExtTextOutW 0x1e0, 21, 443, 00001004, 0x33ec40, L"Iieuciaaoaeuneea eioadoaenu", 27, 0x33e8e4) ... trace:font:ExtTextOutW 0x1e0, 21, 464, 00001004, 0x33ec40, L"Idaaa ainooia", 13, 0x33e8e4) А вот это появляется на экране, очень похоже: Ìåòàäàííûå Ïîëüçîâàòåëüñêèå èíòåðôåéñû Ïðàâà äîñòóïà
(In reply to comment #17) > По-моему, говорить о проблеме со шрифтами - > это не совсем верно. > Ну так выводится верно - текст в неправильной кодировке. Осталось только узнать, какой заказывается шрифт, отображаемый или подменяемый wine неправильно.
(In reply to comment #18) > (In reply to comment #17) > > По-моему, говорить о проблеме со шрифтами - > > это не совсем верно. > > > Ну так выводится верно - текст в > неправильной кодировке. Осталось только > узнать, какой заказывается шрифт, > отображаемый или подменяемый wine > неправильно. На мой взгляд, там при перекодировании из 8-битного в UCS2 неверно подразумевается кодировка для 8-битного текста, поэтому результат в UCS2 получается латиницей. Вот пример исправления: --- hlpfile.c.orig<---->2004-02-16 03:17:40 +0300 +++ programs/winhelp/hlpfile.c<>2004-02-16 03:16:37 +0300 @@ -1186,7 +1186,7 @@ hlpfile->fonts[i].LogFont.lfItalic = (flag & 2) ? TRUE : FALSE; hlpfile->fonts[i].LogFont.lfUnderline = (flag & 4) ? TRUE : FALSE; hlpfile->fonts[i].LogFont.lfStrikeOut = (flag & 8) ? TRUE : FALSE; - hlpfile->fonts[i].LogFont.lfCharSet = ANSI_CHARSET; + hlpfile->fonts[i].LogFont.lfCharSet = DEFAULT_CHARSET; hlpfile->fonts[i].LogFont.lfOutPrecision = OUT_DEFAULT_PRECIS; hlpfile->fonts[i].LogFont.lfClipPrecision = CLIP_DEFAULT_PRECIS; hlpfile->fonts[i].LogFont.lfQuality = DEFAULT_QUALITY; Собственно при поиске в этом файле по DEFAULT_CHARSET одну багу я уже вижу.
> На мой взгляд, там при перекодировании из > 8-битного в UCS2 > неверно подразумевается кодировка для > 8-битного текста, > поэтому результат в UCS2 получается > латиницей. > По-моему, если неверно идёт из 8 в 16 или больше, то отображается всё квадратами (управляющими символами).
(In reply to comment #20) > По-моему, если неверно идёт из 8 в 16 или > больше, то отображается всё квадратами > (управляющими символами). Ну почему же, в кодовой странице cp1252 например http://en.wikipedia.org/wiki/Windows-1252 на том месте, где у нас русские буквы, находятся разные символы с диакритическими знаками. Соответственно, их мы потом в Юникоде и видим.
(In reply to comment #21) > (In reply to comment #20) > > По-моему, если неверно идёт из 8 в 16 или > > больше, то отображается всё квадратами > > (управляющими символами). > Ну почему же, в кодовой странице cp1252 > например > http://en.wikipedia.org/wiki/Windows-1252 > на том месте, где у нас русские буквы, > находятся > разные символы с диакритическими знаками. > Соответственно, их мы потом в Юникоде и > видим. > А, ну ясно. Тут сначала выбирается 1252, а потом это безобразие кодируется в юникод.
В winhlp32 используем charset, полученный из функции TranslateCharsetInfo(). commit 1eedd807fc267af2f2fafb0de06935a861230e6d Author: Konstantin Kondratyuk <kondratyuk@etersoft.ru> Date: Thu Apr 16 17:32:50 2009 +0400 winhlp32: Use charset from TranslateCharsetInfo results (eterbug #108)
Принято eter20/13
