» GoldenDict

Tvangeste

Цитата:

Воспроизвел, надо было просто сделать окно поменьше. Как я понял логику, если раскрытая панелька со всеми словарями в окно не влазит, то Qt решает, что вместо панельки нужно показать меню. Что логично в общем-то.

Спасибо, что помогли разобраться

ramix

Цитата:

Так юзабилити страдает. Человек лентяй по своей натуре, о чем красноречиво свидетельствует анекдот про выключатель и ввинчивание лампочки.

Не понял, как тут страдает юзабилити? Это ни чем не отличается от того списка, что я видел в других реализациях. Мало того, на сколько понял в том же Lingose, выводиться простой готовый алфавитный список. Так же как это сейчас можно сделать и в GD.


Цитата:

Этот "муьтитрановский" принцип не везде хорош. Да и весь цимус FTS не только в поиске в обратных переводах, а по всей карточке (в примере, комментарии и пр.).

То же не ясно, я разве предлагал выкинуть примеры комментарии? Или вы имеете ввиду раздельный поиск по примерам и комментариям? Кажется я понял, что вы не поняли меня . Это не вариант мултитрановского поиск замены местами перевода. Я менял местами ЗАГОЛОВКИ КАРТОЧКИ и СТРОКИ КАРТОЧКИ. В этом случае мы как раз попадаем именно на нужную карточку, откуда была взята фраза, статья...

Полагаю запросы должны расти по мере реализации хотя бы более простого варианта.

Попробовал вариант загрузки локального шрифта стиля из папки \\\portable\fonts. Теперь можно создавать несколько пользовательских стилей с отображением транскрипции, и при этом загружать шрифт из общей папки. Пример здесь (распаковать в папку portable): http://rghost.ru/43888754

Tvangeste, Abs62



Хотел бы узнать, выше, в представлении диакритики заголовка "tete de cuvee" - это ошибка парсинга или словароделателя?

ramix, вроде бы это дело как-то обсуждалось и даже фиксилось (by Abs62). Но проблема не в GD изначально, а в кривой конвертации. И фиксы заключались, как я понимаю в попытках эвристически определить плохой перед нами заголовок или нет, и если плохой, то попытаться его исправить. В идеале нужно сам словарь править, конечно.

http://goldendict.org/forum/viewtopic.php?f=6&t=1756
https://github.com/goldendict/goldendict/issues/53
https://github.com/goldendict/goldendict/pull/114

ramix
В данном случае натуральная ошибка редактора или конвертера. Тегу параграфа <p> нечего делать в заголовках. Без него GD скорее всего справился бы.

Abs62
И все таки не плохо было бы дать возможность каждому словарю иметь свой файл стилей.

Abs62
Нет ли способа программно назначить шрифту, загружаемому из локальной папки (portable), полужирное начертание? К сожалению, с помощью атрибутов это сделать не получается...

anion23
Загрузить полужирный шрифт, а не обычный. Каждое начертание как правило - отдельный файл шрифта. К примеру, arial.ttf - обычное начертание шрифта Arial, arialbd.ttf - полужирное, ariali.ttf - курсив, arialbi.ttf - полужирный курсив.

Abs62
Смущает необходимость или невозможность реализации присвоения стиля словарику?

Tvangeste

Цитата:

фиксы заключались, как я понимаю в попытках эвристически определить плохой перед нами заголовок или нет, и если плохой, то попытаться его исправить

Заголовок сам по себе не плохой - только диакритика в нем заменена на стандартные HTML-соответствия.
То есть t&#234;te de cuv&#233;e = tete de cuvee с диакритикой.


Цитата:

В идеале нужно сам словарь править, конечно.

Файл самого словаря (OxfordTalkingDictionary.dict) с такими же подменами обрабатывается правильно (что и видно на картинке выше). А вот бинарный индексный, который и содержит эти "искаженные" подменами заголовки, трогать страшно - может всё посыпаться.

Abs62

Цитата:

Тегу параграфа <p> нечего делать в заголовках. Без него GD скорее всего справился бы.

Другие заголовки с тегом <p> (не содержащие диакритики) обрабатываются корректно и он не появляется в списке заголовков.
Попробовал я удалить в индексном файле у некоторых карточек тег <p> - не помогло, всё равно подмена светится в списке заголовков, только уже без этого самого <p>. Мне кажется, если бы GoldenDict обрабатывал HTML-подстановы, то отображалось бы корректно в списке заголовков. Правда, я не знаком с этим форматом словарей и не знаю, соответствует ли такое оформление их стандарту. Так что это вполне может быть и косяк конвертора.

BKSRU
Как на мой взгляд, вид словарей должен быть по возможности унифицирован - это облегчает восприятие. Идея отдельных стилей для каждого словаря идёт вразрез с этим тезисом.

ramix
А, так это стардиктовский словарь? До сих пор подобные глюки лезли в вавилоновских, там и боролись. Посмотрим.

Abs62

Цитата:

Как на мой взгляд, вид словарей должен быть по возможности унифицирован - это облегчает восприятие. Идея отдельных стилей для каждого словаря идёт вразрез с этим тезисом.

В общем то странная позиция и это при том, что гордость GoldenDict в его многоформатности. Как же ваш тезис связать с этим?:

Цитата:

Поддержка подключения словарей в форматах: Babylon (.BGL), StarDict (.ifo/.dict./.idx/.syn), Dictd (.index/.dict(.dz)), ABBYY Lingvo (.dsl тексты и аудиоматериалы .lsa/.dat), XDXF (в последних сборках), AARD;

При этом привилегия, на сегодня только у одного формата и не самого лучшего, с точки зрения стандартных возможностей.
Кроме того это решает следующие проблемы:
- Возможность давать индивидуально шрифт каждому словарю свой независимо от ситуации, решая некоторые проблемы.
- Возможность каждому словарю дать свой набор кнопок.
- Возможность манипулирования графикой. Делать превью и оптекание с любой стороны.
Выше перечисленные возможности полностью совместимы с Lingvo, при том, что сами по себе уже создают аккуратность статей, значительную экономию полезного пространства. И при этом никак не лишают статьи общей целостности. Наоборот, улучшают юзабилити.
- Дает возможность манипулирования стилем стандартных тегов DSL.
Это то же не влияет на совместимость с Lingvo. Причем делать это возможно не правя сам код уже готовых словарей.
Остальные возможности безграничны и перечислять их нет смысла.

И с другой стороны. А чего собственно опасаться? Последнее слово все равно за энтузиастами. Сама по себе возможность еще ничего не меняет. Она просто расширяет возможности.
Надо сказать, что на сегодня это все уже можно сделать средствами файла стилей и это никак не отразиться на состоянии других словарей. Полностью поменять стиль словаря можно всего одним тегом, при этом остальные словари остаются при своем общем стиле.
Но было бы куда лучше иметь возможность улучшить некоторые вещи. Можно вообще обойтись без этого волшебного тега.
Тем более уже очевидно, что не сложно организовать отдельный стиль для каждого словаря.

Добавлено:

Идея такова:
- Допустим есть словарь gd.dsl.
- Рядом или в папку мультимедиа ложем файл стилей gd.css.
- Необходимо, что бы при наличии такого файла тело карточки обертывалось в блочный тег. Примерно:
<BODY>
<DIV klass="gd">

</DIV>
</BODY>

- А сам словарь подхватывал стиль.
В этом случаем изолируется словарь и можно для каждого при желании создавать свой стиль.
Подобный блок, вы уже создавали, когда делали тег вторичного отображения [ *][/*].

ramix
Пробуйте этот вариант.
Диакритику поймёт. Остальное, думаю, лучше не трогать, всё равно каша получается.

Abs62

Цитата:

Пробуйте этот вариант.

Пересканировал автоматически словари данного формата и стал корректно отображать диакритику. Спасибо!

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

BKSRU - Несколько вопросов прямых:

Простой ответ, если Вы таки делаете - полноценное простое форматирование словарей, таблицы в словарях, и т.д., то - поменьше „шумите“, тогда - побольше сделаете. Действуйте сами, а народ - уже сам разберется нужно ли это ему и зачем, вне зависимости от чьей-либо оценки или точки зрения.

TOMAS22

Цитата:

Простой ответ, если Вы таки делаете - полноценное простое форматирование словарей, таблицы в словарях, и т.д., то - поменьше „шумите“, тогда - побольше сделаете. Действуйте сами, а народ - уже сам разберется нужно ли это ему и зачем, вне зависимости от чьей-либо оценки или точки зрения.

Об этом можно не беспокоиться. Словари будут.
Но вы считаете, что создаю много шума и ничего не делаю? Вы хоть понимаете, сколько понадобилось времени, что бы создать то, что я уже сделал?
В учебно-демонстрационном словаре все подробно описано и показаны примеры. Система уже полностью самостоятельна. И я готов создавать и создаю комплект словарей. Однако, никто не говорил, что код оптимален. Его можно значительно упростить.
А такая позиция хороша. Мол вы начинайте делать словари, а мы посмотрим. А после того как осознаем, скорректируем код и будем работать. А вы там начинайте свои словарики переправляйте.
На сегодняшний день, впрочем как и всегда я предлагаю работать коллективно. Я готов выслушать критику и предложения. Допустим, тут много говорили и мечтали о возможности построения таблиц. Что пугает в этой структуре таблицы?:
[c _cp]Заголовок таблицы[/c]
[c _tb]Ячейка[/c][c _tb]Ячейка[/c]
[c _tb]Ячейка[/c][c _tb]Ячейка[/c]
[c _tb]Ячейка[/c][c _tb]Ячейка[/c]

Куда проще такая шаблонная-теговая система? Мало того, поддается простой шаблонизации в Excel. Вставляйте колонки в Excel, обрамляйте тегами. Таблица готова. В ячейках может быть все, что угодно: форматированный текст, графика, мультимедиа...
По секрету скажу, что можно упростить .
Что то смущает в моем стиле? Вставляйте соответствующий раздел тегов DSLGD в свой стиль (если мой стиль не по душе) и можете пробовать творить. Причем без опаски испортить стиль других словарей.
Пользователь или составитель словарей вообще может не подозревать о наличии таких возможностей, но со временем обнаружить и войти во вкус.
Но что бы сформировать окончательно стиль и прийти к единому мнению, нужно обсуждение и предложения. Например, какие бы вы хотели видеть имена тегов. Пока я руководствовался правилом соответствия именам в CSS. Например: [c _fs24] - font size 24px. Т.е. ориентировался на то, что бы запомнить было просто и действительно, запомнить не сложно, имея ассоциации.
В системе много вариантов тегов, выполняющие одинаковые функции со своими преимуществами и недостатками. Нужно прийти к единому знаменателю. Найти новые решения и сделать оптимальнее.
Какие бы теги вы хотели видеть, с какими свойствами? Какие возможности?

И уже упоминал не раз, что бы система была идеальной на сегодня не хватает в коде GD всего пары зарезервированных тегов <div klass=""></div>, <span klass=""></span>. И без этих тегов удалось изолировать новые теги, что бы они не влияли на поведение стандартных. И на сегодня, без опаски, можно пользоваться всеми тегами прописанными в стиле. Но лучше использовать специально предназначенные для этого теги.
Ну а имея в распоряжении и этот вариант http://forum.ru-board.com/topic.cgi?forum=5&topic=30250&start=1980#14 есть возможность сохранить совместимость с компилированием словарей под Lingvo процентов на 80%-90% и для этого не придется даже править код словарей. Фактически, несовместимыми у нас останутся только таблицы. Да и зачем стремится к совместимости с тем, чем не обладает Lingvo.
Естественно, эта неопределенность со стандартом меня смущает по выпуску новых словарей. Хотелось бы делать все по правилам.

Abs62

Цитата:

Загрузить полужирный шрифт, а не обычный. Каждое начертание как правило - отдельный файл шрифта. К примеру, arial.ttf - обычное начертание шрифта Arial, arialbd.ttf - полужирное, ariali.ttf - курсив, arialbi.ttf - полужирный курсив.

Дело в том, что загрузка arialbd.ttf и назначение полужирного стиля ничего не дает - все отображается обычным начертанием. Поэтому и возник вопрос, а можно ли эту проблему решить другим путем?

ramix писал, что


Цитата:

Операционная система из простых шрифтов (тех, в которых нет отдельных файлов с жирным/курсивом и т.д.) может "искусственно" делать жирный и курсив. Программы могут это делать через ОС.
Шрифт "Arial Unicode MS", в отличие от шрифтов Arial и Arial Narrow, является "простым" однофайловым (как и, например, Arial Black). Если хотите использовать их в жирном/курсиве, ставьте их системно.

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

anion23

Обычный шрифт "Arial" может вызвать сложности.

Попробуйте поэкспериментировать так:
Возьмите и используйте для портатива вместо шрифта "Arial" или "Arial Unicode MS" какой-нибудь другой, который 1) не установлен в системе и в составе которого 2) есть и обычное начертание, и жирное, и вместе с тем в нем 3) есть транскрипционные значки.

Такой шрифт у вас будет состоять из двух файлов. Рассмотрим на примере шрифта "Calibri" (W7, версия шрифта 5.72). В таком случае вам надо поместить в соответствующую папку портативного GoldenDict два файла шрифта: 1) calibri.ttf и 2) calibrib.ttf. Проверить версию шрифта можно просто щелкнув на файле два раза. Всплывет окно и в нем будет указано и название шрифта и номер версии.

Убедиться в том, что в этом шрифте есть транскрипционные значки можно разными способами, например, откройте Word, выберите команду "Символ" и во всплывшем окне выберите шрифт "Calibri", а в качестве набора - "фонетические значки". Если их там примерно 92 (с кодами 0250-02AF), то набор достаточный и шрифт вам подходит.

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

В зависимости от ситуации, кроме "Calibri", можете поэкспериментировать со шрифтами "Cambria", "Consolas" и др.

BKSRU

Цитата:

готов выслушать любую критику по поводу новой системы. Что в ней не так

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

Да, формат DSL не идеален, да, он где-то ограничен. Но в его минимализме - и его сила, словари просто делать, они похожи друг на друга, они портабельны между кучей разных программ и устройств. Да, отсутствуют таблицы, это огорчительно, но если это цена, которую нужно заплатить за ту пользу, что DSL принес словаределателям и пользователям, я с удовольствием заплачУ.

Я понимаю, что вы знакомы с HTML/CSS, а теперь и с DSL, и с молотком в руках вам все вокруг кажется гвоздями. Но смысл такого скрещивания далеких друг от друга вещей мне не очень понятен.

Есть же вполне полноценные словарные форматы, основанные на HTML, как то: AARD и StarDict. Там не нужно заморачиваться и придумывать горы странных тэгов, там чистый HTML. Да, инструменты по созданию Aard и Stardict словарей оставляют желать лучшего. Ну так надо проблему и решать, а не создавать еще одну пролблему поверх, новым несовместимым полуформатом, который не поддерживается полноценно нигде вообще, и не будет поддерживаться в 99.999999% случаев ни на iOS, ни на Андроиде, ни в других словарных оболочках, ни в Лингво.

Tvangeste

Цитата:

Есть же вполне полноценные словарные форматы, основанные на HTML, как то: AARD и StarDict. Там не нужно заморачиваться и придумывать горы странных тэгов, там чистый HTML. Да, инструменты по созданию Aard и Stardict словарей оставляют желать лучшего. Ну так надо проблему и решать, а не создавать еще одну пролблему поверх, новым несовместимым полуформатом, который не поддерживается полноценно нигде вообще, и не будет поддерживаться в 99.999999% случаев ни на iOS, ни на Андроиде, ни в других словарных оболочках, ни в Лингво.

Вы это писали 4 года назад. В результате у нас нет ни таблиц, ни нормального форматирования... Не было.
Т.е. вам не нужны ни широкие возможности форматирования, ни простота самого форматирования, ни совместимость с Lingvo...
Мне просто интересно, а каким образом можно создать новый формат, который будет поддерживаться везде?
Я не предлагаю плодить теги. Я предлагаю свести их количество до необходимого минимума. Можно начать с самых необходимых: таблицы, списки, меню, шрифты. Никакой путаницы нет. Все намного проще.
Эту таблицу я создал минуты за 3-5:

Причем делал я это спонтанно и использовал простое копирование из Lingvo в Excel. Снабдил тегами и вставил в карточку. И это ручная работа. Думаю макрос справится с этим самостоятельно.
Можете предложить вариант проще?
Каким образом наличие возможности создания таблиц в DSL может повлечь за собой получение разных несовместимых диалектов DSL?

Добавлено:
Tvangeste

Цитата:

когда вместо одного популярного стандарта (хоть и не идеального, но хорошо описанного, понятного и широко применяемого, совместимого с огромным количеством разных словарных оболочек) получаем разные несовместимые диалекты.

Однако вы изнутри эту кухню не понимаете или делаете вид что не понимаете. Не намечается огромного количества разных форматов. И нет тут скрещивания. Здесь расширение формата DSL и с точки зрения HTML+CSS кода там все в порядке и нет никаких конфликтов. Но можно значительно улучшить ситуацию.

Друзья, а у меня одного GoldenDict последнее время периодически "вылетает" (аварийно завершается), причем довольно часто? Начиная, кажется, с версии 501, а может и с 409.

Предвидя вопрос, -- словари недавно добавлял, да, но вылеты начались за некоторое время до того, как я добавлял словари, а перед этим с полгода словари не добавлял, и всё работало нормально. Вылеты начались после обновления на какую-то версию, не помню, на какую. Возможно, на ту, которую сделал ув. Tvangeste (не помню, какая это была).

Допускаю, что у меня самого что-то не так. Поэтому и спрашиваю, у меня одного вылетает или нет?

BKSRU

Цитата:

В результате у нас нет ни таблиц, ни нормального форматирования...

Ну, может, "у вас" нет, а у нас вполне себе есть. Собственно, таблицы мне были нужны для Википедии и для неправильных форм. Для первого теперь есть Aard формат со всей оффлайновой википедией, для второго использую стардиктовский формат.


Цитата:

Т.е. вам не нужны ни широкие возможности форматирования, ни простота самого форматирования, ни совместимость с Lingvo...

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


Цитата:

Мне просто интересно, а каким образом можно создать новый формат, который будет поддерживаться везде?

Да как обычно, разработать стандарт, который добавляет нечто новое, полезное и уникальное, создать удобные инструменты работы с ним, встроить поддержку этого формата в наиболее популярные словарные оболочки, сделать скрипты по конвертации из других форматов, написать документацию, вести работу с пользователями, создать сайт для поддержки, начать выкладывать (легальные) сконвертированные словари, провести маркетинговую работу. Ну и там еще по мелочи!


Цитата:

Я не предлагаю плодить теги. Я предлагаю свести их количество до необходимого минимума.

Ну нельзя быть немножко беременным. Либо есть совместимость с Lingvo, либо нет. Если нет - то все, формат не совместим, это бинарная операция. Не может быть формат "почти совместим". Раз формат не совместим, то зачем вообще тогда цепляться за DSL и впихивать в него не предназначенный для этого HTML+CSS?

Ну ды мы это уже несколько раз проходили по кругу. Вы просили высказаться, я высказался.

BKSRU

Цитата:

Но вы считаете, что создаю много шума и ничего не делаю?

Вы превратили топик по программе в свой блог с огромными постами.

dragon64

Цитата:

Друзья, а у меня одного GoldenDict последнее время периодически "вылетает" (аварийно завершается), причем довольно часто?

Не замечал такого, вообще не припомню когда GD в последнее время падал.

Попробуйте точно вспомнить какая версия была раньше, на что обновились, когда начались падения и пр. Без этой инфы очень сложно что-либо сказать. Словари по идее не должны крашить GD. Но как вариант можно попробовать убрать свежедобавленные словари и посмотреть на результат.

Честно говоря, без вашей помощи найти причину для падения практически невозможно. В идеальном случае я бы вам посоветовал не самый простой путь, но он практически наверняка приведет к определению где ошибка и к фиксу, ко всеобщей радости.

Итак, лучше всего установить официальный Qt билд (в котором библиотеки, Qt Creator, компилятор), там все очень просто: скачал - установил. После чего собрать GoldenDict в дебаг режиме и потом можно будет посмотреть на вывод при краше. Если вы это можете сделать, то замечательно. Там не так все страшно, как кажется, на все уйдет меньше получаса времени, зато и проблемы быстро найдем.

Если у вас есть время и желание пройти этот путь - дайте знать.

Цитата:

лучше всего установить официальный Qt билд

Попробую, спасибо. Ссылочки не подкинете, где взять правильные Qt и исходники GD?

dragon64
Qt SDK (библиотеки, qt creator, компилятор) вот: http://releases.qt-project.org/qt4/source/qt-win-opensource-4.8.4-mingw.exe

Код GoldenDict'a лучше всего забирать через git:

* Git: http://git-scm.com/download/win
* GoldenDict: git clone git://github.com/goldendict/goldendict.git

После чего запускаете Qt Creator, там открывается проект, т.е. файл goldendict.pro, настраиваете билд - Release или Debug. Потом билд и запуск. И понеслось!

Цитата:

Друзья, а у меня одного GoldenDict последнее время периодически "вылетает" (аварийно завершается),

У меня бывают вылеты после N-го пересканирования словарей (Ctrl+F5, появляется месидж что-то типа "Too many files open...") и при поиске некоторых слов (типа "man" и др. - появляется месидж "This application has requested the Runtime to terminate it in an usual way..."). Но я пока на это внимания не обращаю, грешу на словари.

ramix
Я попробовал поэкспериментировать, но вот что получается. C помощью правила @font-face загружаем основной файл шрифта (например, cambria.ttf) и файл с bold начертанием (например, cambriab.ttf). Но если для атрибута body назначить обычное начертание (font-family с шрифтом cambria.ttf), то назначение жирного начертания для заголовков или тега {b} ничего не дает. Если для body не задавать шрифт, а назначить font-family для каждого элемента и тега, то получается слишком громоздкая конструкция.
В идеале хотелось бы получить решение, аналогичное тому, когда шрифт с фонетикой установлен в системе. Т.е. правилом @font-face загружаем шрифт, назначаем для body атрибут font-family с загруженным шрифтом и получаем на выходе типичное оформление с полужирным и наклонным начертанием плюс отображение фонетики. Однако для этого, насколько я понимаю, необходимо программно реализовать отображение bold и italic начертания для локального шрифта.