Укажите отработанное время

Отработанное время:
Продуктивное время:
Bug 108 - 1Cv77: Некорректно работает помощь в 1С   Make a simular bug
Summary: 1Cv77: Некорректно работает помощь в 1С
Status: CLOSED FIXED
Alias: None
Product: WINE@Etersoft
Classification: Продукты (Products)
Component: Шрифты (show other bugs)
Version: unspecified
Hardware: Other All
: P2 normal
Target Milestone: ---
Assignee: Константин Кондратюк
QA Contact: Vitaly Lipatov
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 760 1217
  Show dependency treegraph
 
In work:
Reported: 2006-04-28 17:11 MSD by Александр Пликус
Modified: 2009-04-25 18:11 MSD (History)
6 users (show)

See Also:
Заявки RT:
Связано с:
Дата напоминания:


Attachments
скрин (209.92 KB, image/jpeg)
2010-11-18 03:58 MSK, Денис Баранов
Details
патч (596 bytes, patch)
2010-11-18 03:58 MSK, Anton Rudnev
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Александр Пликус 2006-04-28 17:11:07 MSD
Проблемы с отображением
Comment 1 Александр Пликус 2006-12-12 12:14:02 MSK
При открытии отображается окно "Ошибка помощи". Содержание помощи отображается не очень корректно, но информация присутствует вся.
Панель инсрументов не работает и выглядит некорректно
Comment 2 Vitaly Lipatov 2007-06-02 20:38:08 MSD
Причём окно "Ошибка помощи" открывается только после того, как winhelp запустится, прочитает справку и выведет её на экран.
Comment 3 Анатолий Лютин 2008-01-28 14:21:32 MSK
В бета-версии 1.0.9 окна с сообщением об ошибке не возникает.
Comment 4 Денис Баранов 2008-11-03 17:54:52 MSK
Сейчас помощь открывается корректно, но появились проблемы со шрифтами, см. скрин.

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
Comment 5 Денис Баранов 2008-11-03 17:55:07 MSK
Created attachment 861 [details]
скрин
Comment 6 Anton Rudnev 2009-02-21 15:48:26 MSK
На данный момент баги, похоже две.

Первая с запуском, собственно, помощи.
Если запустить через 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.


Comment 7 Anton Rudnev 2009-02-24 10:55:19 MSK
по строчкам канала 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)
Comment 8 Anton Rudnev 2009-02-24 11:26:22 MSK
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
Comment 9 Anton Rudnev 2009-02-24 18:12:02 MSK
я пришел к тому, что причина падения кроется в этом коде из 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С никак не передает в командной строке какой именно файл помощи открывать. И как оно на самом деле передается пока не выяснил.
Comment 10 Anton Rudnev 2009-02-26 18:06:13 MSK
Попытки вручную по коду проанализировать почему все-таки на самом деле происходит падение, не увенчались успехом.

На данный момент, версия wine, запускаемая через "wine" -- это 1.0.9-eter42. Через git откатился до 1.0.9-eter34.1. Падение всё равно проявляется.

Из этого следует думать, что проблема никак не решается на уровне исходников: т. е. нет ни одного коммита приводящего к падению winhlp32. Проблема, возможно, на уровне сборки.

Далее буду решать проблему с неправильным отображением букв.

Следующий патч -- способ заставить winhlp32 отображать .hlp-файл на собственных исходниках без падения...
Comment 11 Anton Rudnev 2009-02-26 18:25:51 MSK
Created attachment 1083 [details]
патч
Comment 12 Anton Rudnev 2009-02-27 17:15:15 MSK
Изменение шрифтов через реестр ни как не помогает.

И, скорее всего, не должно помогать: если взглянуть на приаттаченый скриншот, то искажение можно видеть также и в заголовках.

Попробую проанализировать работу от DrawText.
Comment 13 Vitaly Lipatov 2009-02-28 10:52:08 MSK
(In reply to comment #12)
> Изменение шрифтов через реестр ни как не
> помогает.
> 
> И, скорее всего, не должно помогать: если
> взглянуть на приаттаченый скриншот, то
> искажение можно видеть также и в
> заголовках.
> 
> Попробую проанализировать работу от DrawText.
Это не тот уровень совершенно. Проблема либо в кодировке исходного текста, либо в особом названии шрифта, который используется.
Но всё это можно увидеть гораздо раньше. 

Comment 14 Anton Rudnev 2009-03-02 18:01:13 MSK
при помощи Help & Manual 5 (http://www.ec-software.com/) и Microsoft Winhelp compiler (там же скачать можно) удалось создать русский hlp файл, в котором не искажается текст.

Попробую сравнить канал font искажаемого и неискажаемого файла и попробывать создать файл с искажением.
Comment 15 Anton Rudnev 2009-03-03 20:24:36 MSK
В 1С-овском hlp-файле используется шрифт (ARIAL CYR, 9)
с нестандартным размером отступа между строк (он уже обычного).

Попытка перекомпилировать этот файл в просто (Arial, 9) или поправить отступ, дает hlp-файл, который отображается "вопросиками".

Попытки прописать в реестре, чтобы вместо Arial CYR отображался просто Arial, также ничего не дают.
Comment 16 Vitaly Lipatov 2009-03-03 21:02:52 MSK
Нужно анализировать, какой шрифт запрашивается у шрифтового движка, с какими параметрами.
Comment 17 Константин Кондратюк 2009-04-16 14:49:35 MSD
По-моему, говорить о проблеме со шрифтами - это не совсем верно. 

Вот что сыпется в трейсы функции 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)


А вот это появляется на экране, очень похоже:
Ìåòàäàííûå
Ïîëüçîâàòåëüñêèå èíòåðôåéñû
Ïðàâà äîñòóïà
Comment 18 Анатолий Лютин 2009-04-16 14:52:02 MSD
(In reply to comment #17)
> По-моему, говорить о проблеме со шрифтами -
> это не совсем верно. 
> 
Ну так выводится верно - текст в неправильной кодировке. Осталось только узнать, какой заказывается шрифт, отображаемый или подменяемый wine неправильно.
Comment 19 Vitaly Lipatov 2009-04-16 15:00:29 MSD
(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
одну багу я уже вижу.
Comment 20 Анатолий Лютин 2009-04-16 15:08:06 MSD
> На мой взгляд, там при перекодировании из
> 8-битного в UCS2
> неверно подразумевается кодировка для
> 8-битного текста,
> поэтому результат в UCS2 получается
> латиницей.
> 
По-моему, если неверно идёт из 8 в 16 или больше, то отображается всё квадратами (управляющими символами).
Comment 21 Vitaly Lipatov 2009-04-16 15:17:38 MSD
(In reply to comment #20)
> По-моему, если неверно идёт из 8 в 16 или
> больше, то отображается всё квадратами
> (управляющими символами).
Ну почему же, в кодовой странице cp1252 например
http://en.wikipedia.org/wiki/Windows-1252 
на том месте, где у нас русские буквы, находятся
разные символы с диакритическими знаками. Соответственно, их мы потом в Юникоде и видим.

Comment 22 Анатолий Лютин 2009-04-16 15:20:27 MSD
(In reply to comment #21)
> (In reply to comment #20)
> > По-моему, если неверно идёт из 8 в 16 или
> > больше, то отображается всё квадратами
> > (управляющими символами).
> Ну почему же, в кодовой странице cp1252
> например
> http://en.wikipedia.org/wiki/Windows-1252 
> на том месте, где у нас русские буквы,
> находятся
> разные символы с диакритическими знаками.
> Соответственно, их мы потом в Юникоде и
> видим.
> 
А, ну ясно. Тут сначала выбирается 1252, а потом это безобразие кодируется в юникод.
Comment 23 Константин Кондратюк 2009-04-17 11:52:26 MSD
В 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)
Comment 24 Денис Баранов 2009-04-25 18:11:18 MSD
Принято eter20/13