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

Малоконтрастный текст (например, светло-серый на белом) плохо читается, как, впрочем, и белый на светло-сером или вовсе голубом. В борьбу за право читать с комфортом даже поисковые системы вступили — насколько помню, и 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. А такому условию удовлетворяли бы оба рассмотренных значения и условие всегда оказывалось бы истинным, что снова бы вызвало циклические перенаправления.

Четыре и шесть

0. КДПВ — четыре синеньких луча да шесть рыженьких:

1. На Урале уже пятнадцатое — можно поздравлять.

2. Буду ли жарить мясо, когда и где — пока не знаю. Точно знаю, что в ближайшие выходные на традиционном месте меня не будет — я сейчас не в Челябинске.

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

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 по-прежнему ключами служат последовательности вида тема.подтема.словоИлиНесколько. Предположу, что так оставили для совместимости.

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"