Ответ: MathType и Indesign
Maks_Tsofin сказал(а):
Вообще 0,353 -- это перевод пунктов в мм. Т.е в ID должны быть правильно настроены единицы измерения, а именно должны быть мм.
Все верно, выбрал миллиметры и все заработало! Да, стыдно мне, я ведь по сути вычислил, где может находиться ошибка, однако не пошел до конца и не поэксперементировал с единицами измерения документа...
Maks_Tsofin сказал(а):
Что касается наездов на нижнюю строку. Да действительно это проблема если там нет формул. Хочу отметить и тот факт, что отбивка от верхней строки работает только при автоинтерлиньяже. Я думал про это, но нормального алгоритма решения проблемы, действительно разумного, который бы не создавал проблем при переверстке, правке и т.д. не придумал. Более того, как показывает практика, если формул, действительно много, то это вовсе не проблема. А если мало то и фиг с ним. Увеличения интерлиньяжа у одного из символов нижней строки быстро решает данную проблему.
Все таки ручками этот интерлиньяж задавать/подбирать, а ведь сдвиг потребный уже по сути посчитала ваша функция getPos... Ну а если вставлять формулы по порядку не снизу вверх (так делает ваш скрипт, нет?), а сверху вниз, т.е. основные подвижки в верхней части (относительно помещаемого в данный момент уравнения) макета уже произошли и после вставки данного уравнения для первого символа в следующей строке (можно ли такой переход осуществить?) задать интерлиньяж -getPos? Лучше было бы задать для какого нибудь из символов вблизи центра строки (это бы уменьшило вероятность ошибки при чистовом подтягивании и сокращении длины верхней части макета, т.е. ситуации, когда этот символ перейдет в строку выше), однако не исключено помещение следующего уравнения (уравнений) в ту же строку, что и предыдущего, что вызовет большую подвижку и переход ключевого символа на строку следующую... Как вариант предотвращения такого сдвига в общем случае можно рассмотреть возможность растягивания/сжатия заменяемого inline-текста до ширины помещаемого на его место уравнения...
Maks_Tsofin сказал(а):
Что касается набора команд. Они самые приметивные. Их описание можно найти в любом описании по скриптингу в ID (на форуме были ссылки, да и в документации по CS2 есть пдф). Мне тяжело себя назвать большим специалистом в скриптинге, но обладая элементарными знаниями javascript и vb + немного ангельско языка+серого вещества, и скрипты пишутся.
Серость между ушами вроде имеется (я уже давно пишу довольно сложные программы на C, правда, это все математическое моделирование), английский тоже в порядке, так что надо изучать матчасть - документацию...
Maks_Tsofin сказал(а):
Что касется русского языка. В Word'е прежде чем делать eps-ы я делаю wmf-ы. После вставки епсов я попрасту переименовываю вмфы в епсы, обновляю связи и все.
Интересно, и iD нормально интерпретирует такую графику? Хотя конечно, это же не OS, он скорее всего определяет тип графики по заголовку в ее файле...
Maks_Tsofin сказал(а):
Единственное приходится мудрить если работа полноцветная (вмфы имеют RGB, что при цветоделении дает разложение фомул на 4 краски). Для этого у меня есть специальная примочка под Acrobat.
Не буду пока донимать вас вопросами об этой примочке, поскольку пока что речь идет о чернобелом документе, который, как я понимаю, можно при экспорте в PDF целиком перегнать в CMYK.
Maks_Tsofin сказал(а):
А вообще спасибо за положительные отзывы. Если будут проблемы и предложения с удовольствием займусь доработкой. Вот версия на русском для CS2
Уже есть одно предложение. Хорошо бы, если вдруг понадобилось отредактировать уже помещенное уравнение, апдейтить и сдвиг по Baseline. Т.е., отредактировал я уравнение, закрыл MathType (фрейм сейчас выделен), и запускаю скрипт:
function getPos(formula) {...)
var myDoc = app.activeDocument;
var MySel = myDoc.selection[0];
MySel.fit(FitOptions.frameToContent);
var fname="Путь к графическому файлу в выделенном фрейме"; // вот это я пока не знаю как задать
MySel.move(null,Array(0,getPos(File(fname))*0.353));
Поразумевается, что редактировали EPS.
, в виду подстройки каждой формулы под базовую линию.
