October 2nd, 2009

not

Знак тройного тремоло в Maestro

В нотных шрифтах, поставляемых с Finale, под номером 190 имеется символ быстрого (тройного) тремоло: . Из трёх предлагаемых гарнитур наиболее прилично выглядит Maestro, поэтому до недавнего времени во всех наших работах использовалась именно она. Однако упомянутый символ тремоло из Maestro по какой-то причине некорректно воспроизводится некоторыми драйверами принтеров (в том числе PDF-драйверами). Среднее ребро этого символа теряет свою заливку и печатается лишь едва заметным контуром. Именно таким я его вижу во всех корректурах, присылаемых заказчиком (в то время, как у меня символ всегда печатается нормально):


В качестве быстрого решения проблемы было предложено использовать этот символ из гарнитуры Engraver вместо Maestro. Однако лично мне это решение не очень нравится, поскольку шрифт Engraver самый ужасный из троицы, входящей в комплект Finale. Хотелось бы разобраться в истинных причинах проблемы и научиться их обходить.

Я предполагал, что всё дело в том, что направление контура внутреннего ребра в обсуждаемом знаке, задано обратное, и те драйвера, для которых направление имеет значение, не в состоянии его правильно залить. Однако при ближайшем рассмотрении выяснилось, что это не так:


Да, в устройстве этого символа очень много странностей. Например: почему верхняя грань верхнего ребра сделана дугой, а не прямой. Или почему все угловые точки на единицу смещены от своих направляющих — влево от левого края, вниз от базовой линии, вправо от линии ширины символа. Однако направление контура у всех рёбер задано одинаково по часовой стрелке.

Уверен, среди моих читателей есть специалисты, которые сходу скажут, в чём проблема.
not

Finale и жёсткие ссылки

Проблема № 2.

У меня есть в работе четыре песни Берга, переложенные для орекстра. Каждая из них аранжирована в двух тональностях — для высокого и среднего голоса. То есть всего восемь комплектов оркестровых материалов. В комплект входят партитура, клавир и от пяти до 22 инструментальных партий. Всего — 126 файлов. Как видно из следующей иллюстрации, каждый комплект хранится в отдельной папке, чтоб можно было в любой момент работать с материалами отдельно взятой песни:



Тем не менее, есть, как минимум, две ситуации, когда удобнее иметь все 126 файлов в одной папке:

1. Когда требуется запустить Finale script для всех файлов. Скажем, чтобы осуществить замену гарнитуры знака с Maestro на Engraver (см. Проблему № 1). Поскольку Finale script не работает с вложенными папками, то пришлось бы вызывать его восемь раз для каждой из папок, а каждый раз указывать ему нужную папку — это занятие не для слабонервных.

2. Когда требуется отправить изменённые несколько файлов заказчику. Если бы все файлы находились в одной папке, то можно было бы отсортировать их по дате, и выбрать последние.

Если бы мы работали под Юниксом, то мы бы легко вышли из положения, создав для каждого из 126 файлов жёсткую ссылку и поместив их все в общую папку. Но ведь в NTFS теперь тоже есть жёсткие ссылки! Попробуем:

mkdir all
for /f "delims=" %%i in ('dir .\?_* /b') do 
    for /f "delims=" %%j in ('dir .\%%i\*.mus /b') do 
        fsutil hardlink create ".\all\%%j" ".\%%i\%%j"


Всё, как мы хотели: теперь у нас есть папка all, в которую все файлы свалены в одну большую кучу. И это, заметим, не копии файлов, а те же самые файлы, что и разложены по комплектам в восемь папочек. Сообщающиеся сосуды. Хочешь — работай по комплектам, хочешь — одним списком. Ура.

Теперь настало время обломов.

Заходим в FinaleScript и создаём новый скрипт:

process bath folder
search "" [Maestro] replace "" [EngraverFontSet]
save
close


Вернее… это мы хотим создать такой скрипт. А как нам вставить в него символ тремоло? Заглядываем в табличку (библиотека символов артикуляции), видим, что нужный символ имеет код 190, заходим в редактор скрипта и нажимаем Alt+0190. Появляется знак ¾, что нас полностью устраивает, так как именно этот знак соответствует в текстовых шрифтах позиции тройного тремоло. Записываем скрипт (Save and Close), запускаем, видим мелькание файлов и… ничего не происходит. Символ как был в шрифте Maestro, так и остаётся в нём. Открываем скрипт, чтоб проверить, в чём дело, и видим, что наше ¾ в тексте скрипта заменилось на вопросительные знаки!

Тут самое время вспомнить о том, что Finale до сих пор не дружит с юникодом. Несмотря на то, что работает под управлением юникодовой операционной системы. Поэтому хитрым образом она выбирает кодовую страницу вводимых символов в соответствии с тем, какая раскладка клавиатуры сейчас включена. А потом переводит эти символы в дефолтовую кодовую страницу (на моём компьютере — в кириллическую). А в кириллической странице нет знака ¾. На его месте там стоит другой знак — ѕ (это не латинская буква s, это кириллическая буква зело или дзе, по-македонски). Попробуем переключиться в кириллическую раскладку клавиатуры и снова набрать Alt+190. Затем сохраним скрипт и откроем его заново. Получилось. Буква зело стоит на месте. Запустим скрипт.

Трахты-барахты! Замена произошла. Но вместо обычного (некрасивого) знака тройного тремоло из EngraverFontSet мы видим что-то невразумительное серое (как тут не вспомнить соответствующий анекдот). При замене программа включила для символа все возможные атрибуты — жирный, курсив, фиксированный, подчёркнутый, зачйркнутый, скрытый. Если добавить в скрипт различные комбинации «plain, non italic, non bold, non underline, non hidden, non fixed», то это не помогает. Придётся всё равно идти и везде отключать поставленные атрибуты вручную. Так что легче уж — так же, вручную — просто поменять везде гарнитуру. Сие вполне консистентно с предыдущим опытом применения FinaleScript’а.

Это был облом номер 1. Но нас ещё ожидает второй номер. После правки корректуры во всех файлах, которые того требовали, отправляемся в нашу папку all с волшебными жёсткими ссылками. Сортируем, как и планировали, по дате и… не находим файлов, изменённых сегодня. То есть в отдельных восьми папках все файлы с изменениями есть, а в папке all, которая, вроде бы, содержит линки на те же самые файлы, стоят старые даты.

Ларчик открывается просто. Дело в том, что когда Finale сохраняет изменённый файл, она это делает следующим образом. Сперва она сохраняет открытый документ в файле ~finsave.tmp, а после этого удаляет старый файл и называет ~finsave.tmp его именем. Таким образом, файл, на который указывают наши жёсткие ссылки, и файл, куда сохранены изменения — это два разных файла. Благодаря тому, что у нас были жёсткие ссылки, старые версии файлов оказались не удалены, а доступны через эти самые ссылки. Однако то, ради чего эти ссылки создавались, осуществить не удаётся. Фактически, ссылки превращаются в бесполезные копии старых версий файлов.

Ну и лирическое отступление в связи со вторым обломом. Я тут недавно пытался доказать моему другу tender_cactusу, что божество, знающее наш состав до мельчайших частиц, может клонировать (или воскресить) нас без каких-либо физических или ментальных отличий от оригинала. И в качестве примера приводил файлы, которые мы можем побайтно скопировать, а затем удалить оригинал, и считать копию оригиналом, поскольку она от него ничем не будет отличаться. Дудки. Я был не прав. Она отличается тем, как её воспринимает окружающий мир. Видимо, аналогичное ожидает и клонированных/воскрешённых людей. Впрочем, даже это лучше, чем ничего.