В некоторых контролах 1С 7.7, например, в окне поиска на панели инструментов шрифт имеет очень маленький размер (4-5 по оценкам пользователей). Очень неудобно пользоваться. Проявляется в нескольких местах, ещё: > окно запроса "сохранить/отменить изменения" (rt #11729)
Только в этой панели такой размер и появляется... Я не смог найти багу, мы её исправляли не раз, возможно ещё до появления багзиллы.
Раньше у нас в CreateFontIndirectW (dlls/gdi32/font.c) был такого вида хак: /* FIXME: due font overrides hack for 1C find text combobox */ if (plf->lfHeight==8) { fontPtr->logfont.lfHeight=-10; //strcpyW(fontPtr->logfont.lfFaceName,ArialW); } Т.е. фиксированный шрифт 8 заменяли на масштабируемый 10. Дополнительно можно подставлять другой шрифт, но это хуже. Проблема вытекает из того, что шрифта размером 8 вроде как нет, поэтому берётся ближайший меньший. Если проблема воспроизводится, надо подумать, что бы с ней сделать. По возможности решение лучше организовать в закрытой части.
Не уверен, что удалось полностью разобраться в проблеме, но похоже дело в следующем. Когда приложение пытается создать не масштабируемый логический шрифт с размером 8, wine на самом деле выбирает масштабируемый физический в функции WineEngCreateFontInstance. MSDN об этом пишет: The CreateFontIndirect function creates a logical font with the characteristics specified in the LOGFONT structure. When this font is selected by using the SelectObject function, GDI's font mapper attempts to match the logical font with an existing physical font. If it fails to find an exact match, it provides an alternative whose characteristics match as many of the requested characteristics as possible. Т.е. должен подбираться шрифт с наиболее подходящими характеристиками. В wine выбирается первый попавшийся масштабируемый шрифт. Проблема в том, что для масштабируемого шрифта используется положительный размер. Возможно, в этом не должно быть ошибки. Однако в wine в этой ситуации выбирается шрифт с минимальной высотой. Решение заключается в том, чтобы преобразовывать положительный размер (point'ы) в отрицательный размер (логические координаты устройства), в случае когда используется масштабируемый шрифт с положительным размером. По сути получился хак, но надеюсь, что ничего не сломается.
Так а возможно преобразовать только в том случае, когда точно совпадающий по размеру шрифт не найден?
> Так а возможно преобразовать только в том > случае, когда точно совпадающий по размеру > шрифт не найден? Не думаю. Проблема в том, что проверка на соответствие размеров осуществляется если нет масштабируемого шрифта и wine вынужден использовать не масштабируемый. Сейчас масштабируемый шрифт есть, поэтому размеры вообще не проверяются.
*** Bug 4456 has been marked as a duplicate of this bug. ***
Принято. wine-etersoft-1.0.12-alt1
Переоткрываю ошибку для дальнейшего исследования. Т.к. патч привел к багам #5226, #5346
Если убрать в реестре замену растрового MS Sans Serif на векторный Microsoft Sans Serif (замена нужна для баги #4259), то в окне поиска шрифт правильного размера.
Проблема в #4259 заключается в том, что для растрового шрифта MS Sans Serif нет курсива и жирного в wine. Поэтому его пришлось заменить на векторный.
Насколько понял из тестирования происходит следующее: Для растрового шрифта положительный размер - это высота символа в point'ах Для векторного шрифта положительный размер - это высота ячейки в point'ах Для векторного шрифта отрицательный размер - это высота ячейки в логических координатах. Тогда багу можно объяснить так - происходит подстановка растрового шрифта на векторный, но его размер уменьшается, т.к. теперь он означает высоту ячейки, а не высоту символа. Размер в данном случае положительный.
(In reply to comment #11) > Для растрового шрифта положительный > размер - это высота символа в point'ах > Для векторного шрифта положительный > размер - это высота ячейки в point'ах > Для векторного шрифта отрицательный > размер - это высота ячейки в логических > координатах. Поправка: Для векторного шрифта положительный размер - это высота ячейки в логических координатах Для векторного шрифта отрицательный размер - это высота символа в логических координатах.
Решение должно быть такое же как и было - пересчитывать размер символа растрового шрифта в point'ах в размер символа векторного шрифта в логических координатах. Осталось только понять как различить - была ли подмена растрового шрифта на векторный.
Сейчас и для САМО-тура и для 1с7 срабатывает такая подстановка: trace:font:WineEngCreateFontInstance substituting L"MS Sans Serif",1 -> L"Microsoft Sans Serif",1 т.е. charset в обоих случаях одинаковый. Значит замену шрифта в реестре только для определенного charset не сделать.
Выложил реверт текущего решения и новое исправление. Решение заключается в пересчете размера шрифта из point в логические координаты если была подмена шрифта MS Sans Serif и приложение запросило положительную высоту этого шрифта. По сути получился хак. Для корректного решения надо реализовать наклонный и жирный шрифт MS Sans Serif, чтобы починить #4259 без подмены шрифтов.
(In reply to comment #15) > По сути получился хак. Для корректного > решения надо реализовать наклонный и > жирный шрифт MS Sans Serif, чтобы починить #4259 без > подмены шрифтов. А бага такая есть? Надо бы в блокирующие...
Принято. WINE@Etersoft 1.0.12 eter5/eter4
Сейчас на server'е такая ситуация повторилась. wine-etersoft-sql-1.0.12-alt21 wine-etersoft-1.0.12-alt11.13
Created attachment 2234 [details] Вид маленького текста в строке поиска
Откатил патчи из eterhack: commit bfba4c56123fba17f512b49694c8b1fa291211bf Author: Ilya Shpigor <shpigor@etersoft.ru> Date: Wed Mar 31 14:35:58 2010 +0400 gdi32: Fix patch for scalable text faces (eterbug #5226 #4409) commit 35d4410359246de7a79dfa45bdb217a8681269d1 Author: Ilya Shpigor <shpigor@etersoft.ru> Date: Tue Nov 10 14:25:52 2009 +0300 gdi32: Use the logical device coordinates for scalable text faces (eterbug #4409) Патчи приводят к проблеме, описанной в баге 4619 Требуется переделать решение. После этого надо проверить на всех трёх инсталляторах, описанных в баге 4619, Также нужно проверить багу 5226.
откатил патчи и для school
Тут странная ситуация. Маленький шрифт сейчас именно в .wine-buh. Если сделать .wine заново, или обновить другую существующую, проблема не воспроизводится.
(В ответ на comment #22) > Тут странная ситуация. Маленький шрифт сейчас именно в .wine-buh. > Если сделать .wine заново, или обновить другую существующую, проблема не > воспроизводится. А ты как проверяешь? Если запускать через wine из пакета, то всё должно работать. Воспроизводится только при запуске wine из git-репозитория
(В ответ на comment #23) > А ты как проверяешь? Запускаю 1с7.7 в нашем .wine-buh на server -- воспроизводится. Создаю новую .wine на server, ставлю туда 1c, запускаю там же -- не воспроизводится.
На текущем eterhack воспроизводится. Интересно, нашёл комментарий Ильи к #4619: "В текущем релизе оригинального wine 1.1.34 бага #4409 решена. Поэтому при merge eterhack'а с оригинальным wine необходимо отктатить этот патч и на #4409."
*** Bug 8115 has been marked as a duplicate of this bug. ***
Может быть, имеет смысл убрать замену и избавиться от ряда проблем, возникающих из-за неё? А ошибку 1819, если она воспроизведётся, решать при необходимости.
(В ответ на comment #30) > Может быть, имеет смысл убрать замену и избавиться от ряда проблем, возникающих > из-за неё? А ошибку 1819, если она воспроизведётся, решать при необходимости. Я бы тоже предпочел удалить этот хак, так как он создает слишком много проблем.
wine@eter-2 bottle 1c/bug42 WINE@Etersoft SQL 2.0.1-eter1.2/2 Все еще воспроизводится.
Давайте не будем просто кидаться фразами, а подтверждать свои слова скриншотами. Спасибо.
Created attachment 2487 [details] XP 96 dpi
Created attachment 2488 [details] XP 120 dpi
Created attachment 2489 [details] wine 96 dpi
Created attachment 2490 [details] wine 110 dpi
По-моему, просто отлично.
Сделала новую бутылку wine@eter-2 bottle bugs/4409> WINE@Etersoft SQL 2.0.1-eter2.2/1 Все равно шрифт мелкий. Проверю на машине в vbox.
Удалила из реестра "Microsoft Sans Serif" Шрифт в строке поиска стал нормальным.
