Jonmey
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
D1D1D1D
Цитата:| Если не заметили, мой комментарий был обращен не к забугорным разработчикам — в качестве открытия, — а как примечание к вашему |
А разве в моем сообщении (от 9 июня 2018 года) есть упоминание про UTF-8 в контексте HTML Workshop?
Там только упоминание о возможности компиляции c полнотекстовым поиском при сравнении указанной программы с программой htm2chm, в которой такая возможность отсутствует. Вы с этим не согласны?
Причем тут ограничения формата CHM, о которых вы тут пишите, и о которых в процитированном вами сообщении нет ни слова?
Цитата:| И не факт, что это проблема HTML Help формата |
К сожалению для вас - это факт. Но вы можете проверить это, изучив спексы формата CHM.
Цитата:| И не факт, что это проблема HTML Help формата, потому что в том числе конкретная программа могла бы "на лету" конвертировать страницы в ANSI (с символами в Юникоде — в HTML-код), затем компилируя в CHM посредством hh.exe. |
Вы обсуждаете программу 1999 года, которой возможность «могла бы "на лету" конвертировать страницы в ANSI» была просто не нужна, в силу сразу многих причин, одной из ключевых из которых является факт того, что создана она, как и сам формат, была для очень специфической и узкой задачи – создание справочных файлов, с чем она прекрасно справляется вот уже более 20 лет фактически без изменений.
То, что юзерам приглянулся формат “проклятого” Microsoft для сохранения вэбстраниц – это в сущности проблемы юзеров, которые так ревностно ненавидели IE и все с ним связанное, что привело к абсолютному раздраю в браузерах и интернет движках. Как результат – поддержка и совершенствование всего околобраузерного, включая CHM формат была остановлена авторами. Хотя и были какие-то попытки совершенствования формата (Help2 и т.д.). В этом смысле каждый нелюбителель IE (аки непользователь IE) приложил руку к ситуации.
Конвертация юникод текста в ANSI – неправильная идея, поскольку ANSI – это кодировка локали в системе (именно из-за этого подхода ряд программ не может нормально работать с кириллицей). Правильным является кодирование юникода в конкретную кодировку, поскольку эта операция не зависит от установленной локали в системе, что исключает ошибки при перекодировании текста.
Перекодировние html в юникоде в 8-битную кодировку – задача более сложная, чем перекодировка простого текста, поскольку требуется инструментарий html-редактора с рядом полностью автоматических функций (типа анализ кода, автоматическое изменение ряда тегов, конвертация в html сущности или их коды и т.д.), что включить в программу размером 3.5 мегабайт (размер HTML Workshop) не только не возможно, но и не нужно было по указанным выше причинам. Отсюда ваше “программа могла бы” – выглядит нытьем человека, опоздавшего на поезд много лет назад.
И наконец, способность формата поддерживать компиляцию типов файлов или кодировок и способность программы поддерживать полнотекстовый поиск в скомпилированных файлах - суть совершенно разные вещи.
Скомпилировать в формат CHM можно что угодно, хоть исполняемые файлы, видео и музыку и даже котиков во флеше, не говоря о любом тексте. Поскольку СНМ - по сути формат архива, к которому добавлены специфические возможности. А вот скомпилировать в CHM файлы с возможностью последующего полнотекстового поиска в них (аки некоторых других возможностей CHM формата, о которых большинство даже не догадывается) - эта возможность предоставляется для очень ограниченного круга текстовых файлов в определенных кодировках.
Кстати hh.exe - это виндовый движок практически всех программ по компиляции CHM. Остальные программы - фактически надстройки для него (GUI).
Цитата:| И не факт, что это проблема HTML Help формата, потому что в том числе конкретная программа могла бы... |
В этой сентенции у вас двойная ошибка логики
- от наличия дополнительной сторонней опции (перекодирование) невозможность поддержки формтом (CHM) полнотекстового поиска в скомпиллированных файлах в юникоде зависеть не может, по определению.
- отрицание факта (отсутствие поддержки полнотекствогого поиска при компиляции файлов в юникоде в CHM формате) допущением (которое не может повлиять на сам факт), а не фактом, который опровергает первый.
* * *
Как резюм всей-всей затянувшейся дискуссии на тему CHM (в которой приходится повторять одно и то же для очередных "естествоиспытателей-первооткрывателей") замечу, что, на мой взгляд, автору OE не стоило добавлять в программу опцию экспорта в CHM, поскольку, кроме головной боли, эта опция ему самому и программе ничего не добавляет. Компилировать напрямую в CHM, как уже говорил выше, с течением времени будет все более и более нецелесообразно (без редактирования кода скачанных страниц) и даже проблематично (в силу отсутствия поддержки вьюверным движком формата новых технологий, используемых в веб страницах). Достаточно продвинутые юзеры использовали CHM для сохранения скачанных вэбсайтов уже тогда, когда OE был еще младенцем, и не имел многих опций, включая экспорт в CHM. Современным же юзерам, не способным, хотя бы, на элементарное пакетное редактирование скачанных страниц - этот формат (в форме прямого экспорта в OE) принесет мало пользы, которая дальше будет сходить на нет.
Автору OE стоило бы добавить в опцию экспорта в CHM (при нажатии на кнопку OK): показ окна, предупреждающего красными аршинными буквами, что результирующий экспортируемый файл CHM с большой долей вероятности может некорректно отображать скачанные и экспортированные страницы (включая ситуацию, когда страницы не отображаются в CHM вовсе), и это не зависит от OE, а связано с форматом CHM, к которому автор программы ОЕ не имеет отношения и ответственности за это не несет. Экспорт в CHM юзер осуществляет на свой страх и риск.
Возможно бы это уменьшило количество “памагите-OE-делает-кривой-(какой-то-не-такой)-снм”. |
Всего записей: 1319 | Зарегистр. 17-01-2011 | Отправлено: 10:32 01-11-2018 | Исправлено: Jonmey, 12:38 01-11-2018 |
|
