Архив рубрики: software

Редких животных

В поисках мобильных приложений для тренировки редких языков пробую Ling — оно странное.

🇬🇪 На грузинском первом уроке дают слова «ка́ци» — мужчина, «ка́ли» — женщина», «би́чи» — мальчик и «го́го» — девочка, а на втором сразу переходят к числам, и это не «э́рти», «о́ри», «са́ми», то есть 1, 2, 3, а внезапно 25, 12, 14, 40. Ну и алфавит куда-то спрятали: в описании есть уроки по нему, но я их не вижу. Впрочем, с грузинским алфавитом я пробовал разобраться ещё давным-давно, начиная с девяностых, и после приезда в Батуми достаточно быстро освоил оставшиеся буквы.

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

В дуолинго 🦉 этих языков нет.
В 50languages 🗨️ они есть, но там интерфейс неудобный и всё очень мелкое.

P. S. КДПВ созданы c помощью Image Creator from Designer (ранее — Bing Image Creator).

Белое на… Каком?

Малоконтрастный текст (например, светло-серый на белом) плохо читается, как, впрочем, и белый на светло-сером или вовсе голубом. В борьбу за право читать с комфортом даже поисковые системы вступили — насколько помню, и Google, и Bing (про Яндекс не уверен, но возможно) учитывают доступность сайтов при поиске — сайты с хорошей доступностью (в смысле accessibility как возможность воспринять) занимают в нём позиции ближе к началу. Аналогичная ситуация и с мобильной доступностью — вес сайта, скорость загрузки и его отображение на телефонах тоже важны.

Есть разные инструменты для подбора хороших цветов и некоторые совсем рядом — в отладчике браузера — в случае Хрома на Линуксе и Windows он открывается клавишей F12. Отладчик Google Chrome показывает предупреждение, если в паре цветов контраст недостаточен и позволяет исправить цвет текста для соответствия уровням AA и AAA (см. стандарты WCAG 2.0 или ГОСТ Р 52872-2019). Но оно не может подобрать допустимый цвет, когда фон светлый, а текст белый — предлагает лишь поменять белый на точно такой же цвет, не трогая фон. Выход — поменять цвета местами — тогда подбор будет доступен.

Отладчик Google Chrome

Как перенаправить посетителя на HTTPS, если Апач глубоко

Время от времени помогаю знакомым старта́перам в части, относящейся к вебу. В процессе обнаруживаю странное: есть сайты, которыми не сильно можно порулить, даже если и хочется: хостинг-провайдер предоставляет лишь возможность править апачный конфигурационный файл .htaccess. Всё бы ничего, но между файлами и посетителем сайта не только Apache — там ещё и Nginx, чья конфигурация вообще недоступна.

Сейчас в 2023 году редко какой сайт не использует HTTPS (этот — один из них, но сейчас не о нём речь). Если сайт сделан на какой-нибудь CMS, там вполне может существовать возможность указать в настройках основной адрес сайта и включить перенаправление на него — так можно перенаправляться на использование HTTPS и в WordPress, и в Open Journal Systems.

Но что делать, если сайт — статичный? Вроде бы, можно обойтись средствами самого́ Апача, а точнее, его модуля mod_rewrite — напишем в .htaccess:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Этот код включает механизм перенаправлений, проверяет, используется ли HTTPS и если нет — перенаправляет посетителя. Только в нашем случае условие RewriteCond всегда истинно, что вызывает циклические перенаправления. Причина — Apache в конкретном случае работает всегда по HTTP, поэтому значение переменной HTTPS — всегда off. С другими переменными аналогично — например, SERVER_PORT всегда равен 80.

В случае, когда есть доступ к настройкам Nginx, проблем нет — всё настраивается там. Но если нет, приходится искать другие переменные, которые однозначно покажут, как именно посетитель обращается к сайту. Nginx, передавая запрос Апачу, добавляет в него поля, чьи имена начинаются с X-Forwarded — среди них есть и X-Forwarded-Proto, где хранится запрашиваемый посетителем протокол — http или https. В итоге работоспособным оказался такой код:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP:X-Forwarded-Proto} !https
  RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Может возникнуть вопрос — нельзя ли в условии вместо !https написать более короткое http? Оказалось, что нет — сама по себе строка без знака равенства не проверяется на совпадение, а сопоставляется с образцом, то есть, происходит pattern matching. А такому условию удовлетворяли бы оба рассмотренных значения и условие всегда оказывалось бы истинным, что снова бы вызвало циклические перенаправления.

Узковатое меню

Open Journal Systems 3 вышла уже шесть лет назад — в 2016 году, но за всё это время русское меню, отображаемое администратору в шапке страниц в теме оформления, включенной по умолчанию (Manuscript), слишком узкое:

OJS 3 с узким административным меню

Я этот баг 🐞 видел, но как-то не до него было — я поддерживал старые журналы, сделанные ещё на OJS 2. Сейчас посмотрел — исправляется буквально изменением одного байта — github.com/pkp/ojs/pull/3618

Меню стало чуть шире

Когда пулл-реквест будет принят и это изменение появится в новых версиях OJS, пока не знаю, но кому не терпится, может добавить собственное стилевое правило:

@media (min-width: @screen-desktop) {
    .pkp_navigation_user {
        ul {
            width: 13em;
        }
    }
}

Переводы для темы оформления Manuscript лежат в plugins/themes/default/locale — можно найти слово «Администрирование» на разных языках и сравнить ширину:

grep -R 'msgid "navigation.admin"' -A 1 \
| sort \
| perl -nle 'print qq{<li title="$1">$2</li>} if m{^(.+)/.*msgstr "(.*)"}'
Список переводов
Ширина голубой части — 10em

Оказывается русское слово — самое длинное. И самое широкое, потому что буква и шире, чем i.

Почти что Геттекст

Open Journal Systems начиная с вышедшей в позапрошлом году версии 3.2 хранит переводы интерфейса не в XML-файлах, а использует для этого нечто, весьма напоминающее Gettext, но с некоторыми особенностями:

  • Переводы хранятся в обычных геттекстовских файлах *.po, но компилировать их в *.mo не надо. То ли сама OJS компилирует, то ли просто вручную разбирает файлы переодов — не знаю пока, не разбирал ещё так глубоко.
  • Вместо привычного для Геттекста использования в качестве ключей фраз естественного языка (обычно английского) в OJS по-прежнему ключами служат последовательности вида тема.подтема.словоИлиНесколько. Предположу, что так оставили для совместимости.
Electronic scientific journal uses Gettext and keys for translation. Cartoon style

Excelsior — предок Журнальной

Гарнитура Журнальная попадается мне в нотах достаточно давно, да и сам я применял её время от времени уже лет девять. Среди свободных шрифтов я её не находил (не уверен я насчёт лицензионной чистоты того, что называется JournalPSCyr), да и отсутствие дореволюционной кириллицы иногда смущало. Но больше смущало отсутствие букв с диакритическими знаками из западноевропейских алфавитов — più mosso уже не напишешь. В свежих версиях, судя по Паратайповскому каталогу, буква ù уже есть, но хочется и сэкономить (набор из 4 начертаний стоит со скидкой 7500 ₽), и честно пользоваться. В том же самом каталоге пишут и об истории шрифтов:

Гарнитура Journal (Журнальная) представляет собой малоконтрастный текстовой шрифт группы «Леджибилити». Гарнитура была разработана в трех начертаниях в Отделе наборных шрифтов НПО Полиграфмаш, 1951–53 (дизайнеры Лев Маланов, Елена Царегородцева) на основе рисунков кириллической версии шрифта Эксцельсиор, 1936 (коллектив дизайнеров под руководством профессора Михаила Щелкунова при участии Николая Кудряшева), который, в свою очередь, был разработан на основе шрифта Excelcior фирмы Mergenthaler Linotype, 1931 (дизайнер Чонси Гриффит).

Пробуем поискать шрифт Excelsior — находим версию, бесплатную для персонального использования. Засунем её в ноты:

Дореволюционная кириллица есть, причём курсивные ять и ижица выглядят вполне прилично, однако буквы К и Ж в прямых начертаниях выглядят не совсем привычно: с засечками на наклонных элементах. И буквы ù всё-таки нет. И буква Э что-то раздражает. Но зато З — лучше, чем в Edwin.

Ноты без номеров страниц

Делать нотные сборники средствами Лилипонда вроде бы можно: с одной стороны LilyPond сам по себе позволяет размещать несколько пьес рядышком, а с другой содержит в своём составе утилиту lilypond-book, которая позволяет внедрять лилипондовые ноты в документы различных форматов, включая \LaTeX и HTML.

Я проверял — такой способ действительно работает, но мне он показался каким-то неудобным:
во-первых, с ТеХом я давно дела не имел,
во-вторых, верстать печатное издание в HTML — изначально странная затея (хотя CSS3 и включае в себя различные стилевые правила для печати),
ну и самое главное — ноты я сейчас набираю в MuseScore, так получается быстрее, удобнее и качественнее — многие ошибки отлавливаются на слух ещё на этапе набора.

У меня прижился другой метод: выводить отдельные произведения в виде PDF-файла либо пачки PNG-картинок подходящего разрешения, а потом собирать всё это в программе, ориентированной именно на вёрстку — в моём случае это Scribus.

При этом остаётся лишь один вопрос — как убрать номера со страниц произведений, которые должны войти в сборник — в сборниках используется сквозная нумерация и исходные номера не нужны. Понятно, что из сторонних материалов номера придётся вы́резать, но в тех нотах, которые сам набираешь, проще сразу отключить нумерацию. В MuseScore отображение номеров страниц можно настроить (и отключить) в стилевых настройках, которые доступны через меню: Format → Style, после чего в открывшемся окне надо выбрать пункт Header, Footer в левом меню:

Чтобы каждый раз не пробираться через дебри настроек, можно сохранить стилевые настройки (Format → Save Style) и использовать их в других нотах для того же сборника.

В Лилипонде для управления нумерацией страниц можно указать значения соответствующих переменных в блоке \paper — для полного отключения нумерации надо присвоить ложное значение переменной print-page-number

\paper {
  #(set-paper-size "a4")
  print-page-number=##f

  % остальные настроки: размеры, шрифты
}

Для повторного использования настроек листа бумаги (включая нумерацию) целесообразно вынести их в отдельный файл, который присоединять командой \include:

\include "../lib/paper-book-2022.ly"

Боль-ше де-фи-сов

Нотный редактор LilyPond по умолчанию считает, что при недостатке свободного места для текста в вокальных произведениях можно выкинуть лишние пробелы и дефисы между слогами — в результате слова такого текста вообще не разбиваются на слоги:

Слипшиеся слоги

В русском тексте с его обилием букв это достаточно часто встречается. Выглядит непривычно, да и авторы набираемых произведений настаивают всё-таки на разделении.

Решение нашлось в LilyPond Snippet Repository — переопределив значение свойства LyricHyphen.minimum-distance, можно добиться не только увеличения дистанции между слогами, но и принудительной расстановки дефисов — такое переопредение можно засунуть прямо в блок с текстом:

choirVerse = \lyricmode {
  \override LyricHyphen.minimum-distance = #0.5

  Да не у -- мрёт ни с_на -- ми, ни по -- том

Результат — появились дефисы:

Слоги разделены дефисами

Если вместо 0.5 указать значение побольше, слоги разойдутся дальше.

Edwin — очередной потомок Школьной

В состав нотного редактора MuseScore начиная с версии 3.6 входит шрифт Edwin — он используется для текста по умолчанию и неплохо выглядит в латинской части — всё-таки она даже в страшненьких свободных вариантах шрифта, скопированного с New Century Schoolbook, была нормальной, чего не скажешь о кириллице — во входящем в состав GhostScript шрифте Century Schoolbook L она была вообще ужасна.

В Эдвине кириллицу слегка подправили — иногда ноты с ней смотрятся вполне терпимо, особенно если там нет букв З и Э. С дореволюционной кириллицей ситуация хуже: буква ять — только строчная, да и та страшная, ижица в курсиве смотрится странновато.

Ноты с шрифтом Edwin

Для современных нот этот шрифт использовать уже можно (если не сильно всматриваться в детали), для дореволюционных — ещё нѣтъ.

Имиджмеджику надо бы добавить память

Если собирать Имиджмеджиком многостраничный PDF-файл из картинок разрешением 600 DPI, он ругается на недостаточный размер памяти даже для файлов, которые не такие и большие

convert-im6.q16: cache resources exhausted `0002-bw.png' @ error/cache.c/OpenPixelCache/4095.
convert-im6.q16: cache resources exhausted `0003-bw.png' @ error/cache.c/OpenPixelCache/4095.

Раньше оно работало, но сломалось в процессе обновления системы — в ходе него изменился файл /etc/ImageMagick-6/policy.xmlтот самый, где по умолчанию запрещено создавать PDF — в нём же задаются и предельные размеры картинок и используемых для их обработки ресурсов. Я эти параметры уже менял в 2018 году, ещё живя под Ubuntu — сейчас у меня Debian, от которого Убунту и происходит. Значения параметров в сохранённой копии конфигурационного файла отличаются от того, что появилось после обновления. Увеличим парочку параметров вдвое:

  <policy domain="resource" name="area" value="256MP"/>
  <policy domain="resource" name="disk" value="2GiB"/>

После этого сборка идёт как надо.

Лишь недавно заметил, что площадь всё-таки указывается в мегапикселях (MP), а не в мегабайтах, как у меня почему-то было раньше. При этом в policy.xml допустимы два варианта: традиционный двоичный, равный 2²⁰ = 1048576 байт, обозначается как MiB, а то, что обозначают как MB — мегабайт десятичный, по системе СИ.