{
case 'Table Header':
paragraphStylesStorage ['Table Header'] = i; flag [0] = true; break; case 'Table Footer':
paragraphStylesStorage['Table Footer'] = i; flag [1] = true; break; case 'Table contents':
paragraphStylesStorage['Table contents'] = i; flag [2] = true; break;
case 'Table' :
paragraphStylesStorage['Table'] = i; flag [3] = true; break; case 'Tbl Hdr':
paragraphStylesStorage['Tbl Hdr'] = i; flag [4] = true; break;
}
}
Операция break позволяет оптимизировать производительность скрипта: ведь если какой-то из искомых стилей найден, то продолжать его дальнейший поиск смысла нет, можно переходить к поиску следующего стиля. Проверяем, все ли используемые стили присутствуют в публикации:
if(flag[0] && flag[1] && flag[2] && flag[3] && flag[4])
По умолчанию булевы выражения всегда сравниваются с true, поэтому отпадает необходимость каждый раз использовать конструкцию типа
if (flag [. . . ] =true).
Если все стили на месте, переходим к проверке типа выделенной области, что нужно для корректной работы скрипта. Ведь нам необходимо гарантировать, чтобы он был либо точкой вставки, либо абзацем, иначе (например, если выделена ячейка) ранее использовавшееся выражение
myTable = mySelection.parent.parent; потеряет смысл, т. к. оно жестко привязано к конкретному типу выделенной области.
Удостоверимся, что выделение допустимое:
if (mySelection.constructor.name - "InsertionPoint" || ^ mySelection.constructor.name == "Paragraph")
Приступаем непосредственно к форматированию таблицы: сначала присваиваем тексту в ячейках стиль Table contents:
for (i=0; i< myTable.cells.length; i++)…
Однако такой метод достаточно медленный. Эксперименты, проведенные с таблицами, которые занимают одну или несколько страниц, показали, что нужно искать другое, более эффективное решение. Одна из причин такой медлительности - неоптимизированный подход при установке параметров форматирования ячеек. В самом деле, мы по очереди перебираем все ячейки и к каждой по отдельности применяем несколько параметров форматирования. В таблицах с несколькими сотнями ячеек работа скрипта может занять ощутимое время даже на относительно мощной машине. Попробуем исправить ситуацию.
При переборе ячеек мы пользуемся исключительно JavaScript - задаем цикл, начиная с самой первой ячейки и заканчивая последней. Это универсальный подход, а такой редко оптимален. Попробуем отыскать среди возможностей самого InDesign такие методы, которые бы смогли ускорить данный процесс. Диапазон методов, применимых к ячейке (cell), разнообразием не блещет: типичный набор. А что, если посмотреть на методы, существующие для набора ячеек (cells)? Тут нас ждет находка: ключом к решению проблемы будет метод itemByRange о. Он имеет два параметра, задающих диапазон ячеек, к которым InDesign обращается через свои внутренние механизмы (первый задает начальный объект, второй - конечный). Анализ производительности обоими методами (перебор средствами JavaScript и InDesign) дал убедительный результат: в среднем скорость выполнения форматирования поднялась на порядок, что является прекрасным результатом и отлично подходит для работы с таблицами любой степени сложности.