[ID CC-CC2022] GrepOnOff.jsx и размер файла документа. Ваше мнение?

[blacksolg]

Здравствуйте.
Здоровья вам и дорогим вам людям!

Нашел скрипт: GrepOnOff.jsx
Скрипт на сайте автора
Тот же скрипт на adobeindesign.ru с русским описанием
Две кнопки: Включить/Отключить Grep-стили у всех стилей абзаца

Grep-стили использую в базовых параграфах для корректуры и проверок выделений - отсюда нагрузка на ID/комп.
Пока верстаешь фреймы - взял отключил Grep-стили - Удобная штука



Но заметил особенность:
Разный размер сохраненного файла документа, при ВКЛЮЧЕННОМ/ОТКЛЮЧЕННОМ
Например:
- 100байт для документа в 1мб, с одной строкой текста, с одним стилем
- 4кб для 2мб документа с множества строк и стилей
- отключение по скрипту, приводит в основном к росту файла
- * никаких изменений в документе: -открыл файл -выключил скриптом -сохранил файл
- * да, мне известно, сохранение файла indesign под другим именем априори меняет размер файл (служебка?)

Вопросы:
1. кто-нибудь пользовался данным скрпитом, какое ваше мнение?
2. изменение размера файла - нормально 0=) ?
3. и следует: может скрипт все таки меняет что-то в документе, и в дальнейшем могут возникнуть проблемы?
(потери назначений стилей например, в большом документе, етак на 800стр)

Спасибо.


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

Спойлер: Содержание скрипта

//DESCRIPTION: Grep Styles On Off.
//(c) 2020 Richard Bines kerntiff.co.uk

#targetengine "GrepOnOff";

main ();

function main ()
{
var myscript = "@JSXBIN@ES@2.0@MyBbyBnABMIbyBnACMhbbyBn0ABOhdbhfn0AFJhfnASzDjEjPjDBAXzBhQCfXzJjEjPjDjVjNjFjOjUjTDfjzDjBjQjQEfnftJiAnASzKjQiTjUjZjMjFiMjJjTjUFBXzSjBjMjMiQjBjSjBjHjSjBjQjIiTjUjZjMjFjTGfVBfAnftaiCbyiEn0ABaiEOiFbiHn0ADJiHnASzGjUjNjQiTjUjSHEXzOjHjSjFjQiFjYjQjSjFjTjTjJjPjOIfQzAJfXzQjOjFjTjUjFjEiHjSjFjQiTjUjZjMjFjTKfQJfVFfBVzBjKLfCVzBjLMfDnftJiInASHEEXzHjSjFjQjMjBjDjFNfVHfERCjzJjXjSjPjOjHiHjSjFjQOfFeAffnffJiJnABXIfQJfXKfQJfVFfBVLfCVMfDVHfEnfACzChdhdPEXzHjJjOjEjFjYiPjGQfXIfQJfXKfQJfVFfBVLfCVMfDRBjOfffnndAnAVMfDAXzGjMjFjOjHjUjIRfXKfQJfVFfBVLfCByBzBhcSAVLfCAXRfVFfBByBSJiMnAEXzJjSjFjDjPjNjQjPjTjFTfVBfAnfJiNnAEjzFjBjMjFjSjUUfRBFeUiHjSjFjQhAjTjUjZjMjFjThAjCjBjDjLhAjPjOhOffACzChehdVXRfXDfjEfnndBnAFL4C0AiAF4B0AiAM4D0AiAH4E0AiAB40BiAAFAzIjEjPiHjSjFjQiPjOWAiRMiTbyBn0ABOiVbiXn0AFJiXnASBAXCfXDfjEfnftJiYnASFBXGfVBfAnftaiabyicn0ABaicOidJienABXIfQJfXKfQJfVFfBVLfCVMfDCzBhLXjOfXIfQJfXKfQJfVFfBVLfCVMfDnnnfACSEXQfXIfQJfXKfQJfVFfBVLfCVMfDRBjOfffnndAnAVMfDAXRfXKfQJfVFfBVLfCByBSAVLfCAXRfVFfBByBSJjAnAEXTfVBfAnfJjBnAEjUfRBFeQiHjSjFjQhAjTjUjZjMjFjThAjPjGjGhOffACVXRfXDfjEfnndBnAEL4C0AiAF4B0AiAM4D0AiAB40BiAAEAzJjEjPiHjSjFjQiPjGjGYAjFTJKnASOAneEhDhDjYjYftJMnABjzLjFjYjQjPjSjUiQjBjOjFjMZfBjzFiFiNiNiNiXgafEjzGiXjJjOjEjPjXgbfREFeHjQjBjMjFjUjUjFFeXiHjSjFjQhAiPjOhAiPjGjGhAiWhRhOhQhOhQhAiGjSjFjFjzJjVjOjEjFjGjJjOjFjEgcfWzGiPjCjKjFjDjUgdBzLjDjMjPjTjFiCjVjUjUjPjOgeFctftnfnfJNnABXzLjPjSjJjFjOjUjBjUjJjPjOgffjgafneGjDjPjMjVjNjOfJOnABXzHjTjQjBjDjJjOjHhAfjgafndBfJPnABXzHjNjBjSjHjJjOjThBfjgafndBfJRnASzIjCjCjVjUifjHjSjQhCBEXzDjBjEjEhDfjgafRBFeiEjHjSjPjVjQhAjbjPjSjJjFjOjUjBjUjJjPjOhahAhCjSjPjXhChMhAjBjMjJjHjOjNjFjOjUhahAhCjMjFjGjUhChMhAjBjMjJjHjOiDjIjJjMjEjSjFjOhahAhCjGjJjMjMhCjdffnftJSnABjzGjHjSjFjQiPjOhEfEXhDfVhCfBRDFeGjCjVjUjUjPjOjgcfFeOiHjSjFjQhAiTjUjZjMjFjThAiPjOffnfJTnABXzHjIjFjMjQiUjJjQhFfjhEfnegbiTjXjJjUjDjIhAjHjSjFjQhAjTjUjZjMjFjThAjCjBjDjLhAjPjOhOfJVnABjzHjHjSjFjQiPjGjGhGfEXhDfVhCfBRDFeGjCjVjUjUjPjOjgcfFePiHjSjFjQhAiTjUjZjMjFjThAiPjGjGffnfJWnABXhFfjhGfneXiTjXjJjUjDjIhAjHjSjFjQhAjTjUjZjMjFjThAjPjGjGhOfJZnASzHjQjBjEiTjUjYjUhHCEXhDfVhCfBRDFeKjTjUjBjUjJjDjUjFjYjUjgcfFeBhAffnftJganABXzFjXjJjEjUjIhIfXzLjNjJjOjJjNjVjNiTjJjajFhJfVhHfCndhIfJgbnASzKjHjPjUjPjCjVjUjUjPjOhKDEXhDfVhCfBRDFeGjCjVjUjUjPjOjgcfFeBhfffnftJgcnABXhIfXzLjNjBjYjJjNjVjNiTjJjajFhLfVhKfDndgefJgdnABXhFfVhKfDnehGiHjPhAjUjPhAjLjFjSjOjUjJjGjGhAiQjVjCjMjJjTjIjJjOjHhAiTjZjTjUjFjNjThAiMjUjEhOfJhAnABXzHjPjOiDjMjJjDjLhMfjhEfjWfnfJhBnABXhMfjhGfjYfnfJhDnABXhMfVhKfDNyBnAMhDbyBn0AIJhFnASzLjBjCjPjVjUiEjJjBjMjPjHhNAEjgbfRCFeGjEjJjBjMjPjHFeFiBjCjPjVjUftnftJhGnASzNjNjZiCjVjUjUjPjOiHjSjPjVjQhOBEXhDfVhNfARBFeFjHjSjPjVjQffnftJhHnASzCjPjLhPCEXhDfVhOfBRDFeGjCjVjUjUjPjOjgcfFeUiHjPhAjUjPhAjLjFjSjOjUjJjGjGhOjDjPhOjVjLffnftJhInASzGjDjBjOjDjFjMhQDEXhDfVhOfBRDFeGjCjVjUjUjPjOjgcfFeCiPiLffnftJhKnABXhMfVhPfCNyBnAMhKbyBn0ACJhMnAEXzFjDjMjPjTjFhRfjhNfnfJhNnAEjzIiHjPjUjPiMjJjOjLhSfRBFeZjIjUjUjQhahPhPjXjXjXhOjLjFjSjOjUjJjGjGhOjDjPhOjVjLff0DJChOnfJhPnABXhMfVhQfDNyBnAMhPbyBn0ABJhRnAEXhRfjhNfnf0DJChSnfJhUnAEXzEjTjIjPjXhTfVhNfAnfZhWnAnAEhP4C0AiAhQ4D0AiAhN40BiAhO4B0AiAAEAJChXnfJjHnAEXhTfjgafnfAEhC4B0AiAhH4C0AiAhK4D0AiAO40BiAAEAzEjNjBjJjOhUAjJBJGnAEjhUf\
nf0DJByB";
        eval( myscript );
}

 

[_MBK_]

100байт

Этого не может быть, потому что не может быть никогда. То же касается и 4К
Индизайновские документы не могут занимать такие размеры по определению или вы чтото неправильно обьясняете

 

[Gad]

Этого не может быть

Это разница в весе
1. нет
2. да
3. меняет, дописывает "шлабуду" в условие поиска Вот такую:

навредит врядли, и шифровать такое я бы не стал

 

[_MBK_]

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

 

[_MBK_]

да, мне известно, сохранение файла indesign под другим именем априори меняет размер файл (служебка?)

Сохранение файла под другим именем как раз меняет размер в сторону уменьшения ибо выкидывает лишние паразитные блоки.

 

[Gad]

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

Таки да 100 байт никак

 

[_MBK_]

Ну да, дискретизация в 0x1000 байт, по моему, то есть как раз в 4 килобайта

 

[blacksolg]

Это разница в весе
1. нет
2. да
3. меняет, дописывает "шлабуду" в условие поиска Вот такую:

навредит врядли, и шифровать такое я бы не стал

О! Благодарствую!
Наверно, из-за подмены и меняется размер файла.

Сохранение файла под другим именем как раз меняет размер в сторону уменьшения ибо выкидывает лишние паразитные блоки.

но после скрипта увеличивается
возможно, из-за подмены запроса в Grep-стиле и идёт увеличение


P.S.

Gad и _MBK_​

Спасибо вам большое, за скорый ответ и внимание к вопросу!

 

[_MBK_]

О! Благодарствую!
Наверно, из-за подмены и меняется размер файла.


но после скрипта увеличивается
возможно, из-за подмены запроса в Grep-стиле и идёт увеличение

Увеличение идет при любом изменении файла просто изза добпвления лишней транзакции в базу. Корректный эксперимент выглядит так: сохраняете файл под другим именем чтобы очистить лишние блоки; применяете скрипт; снова сохраняете под другим именем. При этом, скорее всего, размер после шага 1 и 3 не изменится вообще, в худшем случае, максимум, на 1 дискретную единицу (0х1000) да и то если изменение придется на границу блока.
То же касается любого небольшого изменения файла, например, добавления/удаления символа, скрипт вообще ни при чем.

 

[Petruccio]

Не по теме:
@blacksolg Можно я немножко не по теме?
Зачем вам греп стили? Почему нельзя пройти греп поиском и заменить на всё нужное?

 

[_MBK_]

А вообще, если кому интересно, что реально делает скрипт, код его предельно прост:

function doGrepOn()
{
var j,pStyleList,k,tmpStr,doc;
{
if(app.documents.length >= 1)
{
doc = app.documents[0];
pStyleList = doc.allParagraphStyles;
for (  j=0 ; j<pStyleList.length ; j = j+1)
{
for (  k=0 ; k<pStyleList[j].nestedGrepStyles.length ; k = k+1)
if(pStyleList[j].nestedGrepStyles[k].grepExpression.indexOf(wrongGrep) == 0)
{
tmpStr = pStyleList[j].nestedGrepStyles[k].grepExpression;
tmpStr = tmpStr.replace(wrongGrep,"");
pStyleList[j].nestedGrepStyles[k].grepExpression = tmpStr;
}
}
doc.recompose();
alert("Grep styles back on.");
}
}
}

function doGrepOff()
{
var j,pStyleList,k,doc;
{
if(app.documents.length >= 1)
{
doc = app.documents[0];
pStyleList = doc.allParagraphStyles;
for (  j=0 ; j<pStyleList.length ; j = j+1)
{
for (  k=0 ; k<pStyleList[j].nestedGrepStyles.length ; k = k+1)
if(pStyleList[j].nestedGrepStyles[k].grepExpression.indexOf(wrongGrep) < 0)
pStyleList[j].nestedGrepStyles[k].grepExpression = wrongGrep + pStyleList[j].nestedGrepStyles[k].grepExpression;
}
doc.recompose();
alert("Grep styles off.");
}
}
}

 

[Skvoznyak]

wrongGrep не определен

 

[_MBK_]

wrongGrep не определен

Ну я разумеется не весь код с диалоговым интерфейсом а только значимые процедуры для понимания процесса
wrongGrep ясен из скриншота выше (его специально красным Гад обвел)

 

[blacksolg]

Не по теме:
@blacksolg Можно я немножко не по теме?
Зачем вам греп стили? Почему нельзя пройти греп поиском и заменить на всё нужное?

Не по теме:
Думаю вы более меня в теме =) - опыта больше.
Проект-книжка, для себя и близких; Греп-стили использую для корректуры и редактуры внутри ID.
Например добавил слова паразиты в греп-стиль - всё сразу видно. Такж использую для тех. задач/редактуры рукописи.
Для себя - оптимальный вариант;
В работе "на бабло" - понятно никто так не делает (редактор-корректор-верстка-редактор-верстка... или по минимуму от бюджета)

Indesign + Scrivener...
- оптимальный текстовой редактор, с всем объемом функций не встречал, потому вот и допиливаю в ID...
Например, Sublime Text + плагины = замечательно для набора,
Но Scrivener 3 гораздо удобнее под редактуру (Scrivener 2 - ужасен был),
хотя в версии под Win, до сих пор есть над чем работать... переносы, оформление разбивки на станицы, работа с корректурой, не все работает с темами оформления