Smitis wrote:1. ФАР отбрасывает в описаниях начальные и конечные пробелы
Вообще-то это плохо, и поэтому пришлось в XnViewMP тоже отбрасывать начальные пробелы, потому как описание смотрелось плохо.
Сперва надо исправить сам FAR. Зачем отбрасываются начальные пробелы, какой в этом смысл?
Если желание делать красивые колонки, то пользователь не будет лезть в сам файл Descript.ion, а обработать его очень легко, особенно если FAR будет иметь опцию для альтернативного разделителя в виде табуляции. В этом случае загрузив в MS Word, можно задать любую позицию табуляции.
Красивых же колонок всё равно не получится, потому как на диске файлы имеют любую произвольную длину в имени файла, и длинные имена всё равно не умещаются.
Smitis wrote:2. Самое главное, ТС не поддерживает в описаниях юникод.
Это не самое главное, со временем его там тоже введут, думается. Ведь если делать описания к файлам, символы имени которого не вписываются в однобайтную кодировку, то UNICODE напрашивается сам собой.
По крайней мере, если FAR сумеет считать его многострочное описание в CP1251, то при обновлении преобразуется в UTF-8 несомненно, если это задано в опциях. И наоборот, если важно иметь совместимость созданного в FAR описания с существующим TC, то можно просто убрать опцию для UTF-8. Просто UNICODE это хорошо, этим я пользуюсь, но ещё долго надо будет поддерживать и однобайтные Descript.ion, для совместиимости.
Smitis wrote:посоветуйте разработчику XnViewMP использовать для описаний UTF-8 с BOM. Для совместимости.
Странно, а я отписал, что это работает...
Вроде работало в бета.
Вспомнил, я сам просил для совместимости преобразовывать в UTF-8 только тогда, когда исходный файл содержит описание в UTF-8 до копирования. Если Descript.ion уже содержит BOM, то при копировании файлов из него новый Descript.ion создаёт тоже в UNICODE, и содержит BOM. Потому как если произойдёт непрошеное преобразование в UNICODE, то это будет неприятностью для тех, у кого программное обеспечение не поддерживает UNICODE. В FAR это решается просто убиранием опции в настройке. Добавление же предпочтения создания в UTF-8 или однобайтной кодировке, или определение автоматом при появлении двухбайтных символов в момент записи описания (как это было во время бета-тестирования - поначалу автор так и сделал), это будет в будущих версиях, - затрагивает интерфейс настройки, который пока не меняется.
Пока это сильно не напрягает, - FAR у меня создаёт описания Descript.ion в UTF-8, и я просто копирую любой из них в папку, в которой хочу создать описание с символами, которые не помещаются в однобайтную кодировку, или просто в FAR корректирую одно из описаний, чтобы он стал UTF-8. Было бы странно, если это нововведение приняли в штыки те, кому UTF-8 не нужен (например, пользователи TC). Улучшения должны быть по согласию пользователей (возможность отключить настройкой), или не ущемлять их интересы.
Меня больше интересовало копирование, - в новой папке создаётся файл Descript.ion с полагающимся BOM, а FAR его успешно читает. Проверил только что...