Разве могут эти милые значки могут испортить ваши отношения с подписчками или навредить в личной переписке? А что на счёт онлайн-переписки с коллегами в условиях дистанционной работы? Автор статьи на всё отвечает да. Более того, между многобукаф и многосмайлоф он выбирает первое, считая это за меньшее зло. Почему?

Чтобы ответить на этот вопрос, он вводит критерии качества общения и выстраивает соответствующую аргументацию.

Несколько недель назад я опубликовал в Instagram Stories саморекламы пост. Через полчаса я обнаружил, что подписчики положительно отреагировали на него. Вроде бы всё хорошо, но давайте посмотрим внимательнее.


Изображение: Lazlo Barclay

Присмотревшись, я понял, что на самом деле всё грустно. Шесть последних комментаторов просто ткнули на одну из 8 часто используемых эмодзи, не написав ни слова. И я по-прежнему не знал, что же думает каждый из них. Большинство подписчиков просто использовали плюс-минус одни и те же эмодзи. Получается, что шесть одинаковых эмодзи мог отправить один и тот же человек. От этого ничего бы не изменилось.

Мы часто говорим, что время нашего общения в цифровом пространстве превышает время живого общения. Но насколько это сопоставимо по качеству? Можно ли найти по этой теме какие-то исследования? По каким критериям можно сравнить качество этих двух типов коммуникации?

Общение и распознавание

Естественные языки, которые мы используем в речи, позволяют обмениваться детальной информацией о материальных объектах и абстракциях. Это уникальная способность позволяет нам успешно существовать как вид.

Речь, в той или иной форме, служит для нас основным средством коммуникации. До изобретения письменности (около 5 500 лет назад) люди могли общаться устно (слова, междометия и отдельные звуки) и с помощью жестов. Назовём это естественным способом коммуникации.

Качественное распознавание (валидация) секрет построения хороших человеческих отношений.

Речевая коммуникация, проще говоря, разговор это сложный, составной навык, включающий разные скилы. Один из наиболее важных среди них распознавание или валидация. Способность понять, корректно распознать, что имел в виду собеседник, сближает людей, вызывает у них доверие друг к другу. Между двумя людьми возникает дружба только в том случае, когда они смогли успешно пройти через огромную цепочку распознаваний (микровалидаций).

Вот несколько примеров корректного распознавания:

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

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

Письменная коммуникация

Изобретение письменности перевернуло игру. Появилась возможность общаться асинхронно. Можно было нацарапать послание на куске папируса. И тогда ослик мог проделать путь в сотню километров, чтобы доставить фараону сообщение (например, о том, что он козёл). Другой пример: прикрепить любовное послание к колодцу рядом с хижиной вашей девушки.

Две главных особенности асинхронной коммуникации:

• ставки не так высоки: собеседников разделяет время и пространство. Вы вряд ли могли бы обозвать фараона козлом, если бы он стоял прямо перед вами;
• подготовка: у вас есть много времени, чтобы продумать содержание послания.

При таком способе общения собеседники вынуждены додумывать недостающие детали, например, интонации, отношение и подтексты. В итоге участники переписки становятся друг для друга некими абстрактными образами, удаляющимися от реальности.

Напомню, речь не идёт о формализованном обмене документами в рабочей коммуникации. Также мы оставляем за скобками художественные произведения, которые заставляют задуматься и апеллируют к воображению читателя.

Такой побочный эффект письменного общения порой мешает выстроить нормальные отношения с собеседником, так как взаимодействуют не реальные люди, а их абстрактные образы.

Онлайн-переписка

Со времён фараонов изменилось многое, в том числе и скорость доставки сообщений. Благодаря информационным технологиям эта скорость стала настолько высокой, что письменная коммуникация из асинхронной превратилась в синхронную. Сегодня переписка в социальных сетях является едва ли не самой распространённой формой общения. Казалось бы, такой уровень коммуникации максимально приближен к реальному общению, но прежние проблемы с восприятием остаются:

1. Разрыв между реальным человеком и его абстрактным образом.
2. Сложности с обеспечением корректного распознавания посланий из-за недостатка информации.

Переписка в социальных сетях активно вытесняет реальное общение, но не обеспечивает необходимое качество коммуникации. В связи с этим возникает вопрос: решает ли эту проблему возможность отправлять картинки и особенно эмодзи?

Эмодзи

Эмодзи это современные иероглифы. Сегодня их можно считать самым быстрорастущим языком в мире. За последние 20 лет они стали неотъемлемой частью культуры написания текстовых сообщений. Эмодзи нравятся людям. Исследование 2015 года показало, что 72% британцев в возрасте 18-25 лет предпочитают использовать эмодзи вместо текста (где это возможно). В том же 2015-м британские филологи признали смайлик плачу от радости словом года. Да-да, словом.

На фоне современной тенденции к обеспечению простоты и удобства в разных сферах жизни эмодзи пришлись очень к месту: они экономят время, они красочные, милые и иногда забавные. Поэтому люди так активно их используют, полагая, что смайлики позволяют легко и непринуждённо выразить, например, свою реакцию на чей-то пост. Но означает ли это, что их можно использовать вместо текста?

Мне стоит оговориться, что я не выступаю против использования эмодзи в принципе. Бывают случаи, когда они помогают добавить отсылку к шутке, структурировать текст, сделать сообщение более провокационным или придать ему другую эмоциональную окраску.

Однако мне не нравится, когда эмодзи без поясняющего текста делают невозможным корректное распознавание реакции собеседника или лишают его ответ всякого смысла.

Слова vs Эмодзи

Большой академический словарь русского языка содержит около 130 тысяч слов. Однако туда не вошли архаизмы, историзмы, разговорная лексика, сленг и диалектные слова. Такое количество слов накапливалось сотни лет. Это было нужно для того, чтобы лучше доносить новые смыслы, новые идеи, которые появлялись с развитием различных сфер жизни. Языки продолжают обновляться и по сей день.

Эмодзи могут похвастаться коллекцией всего в 3 521 символ. Несмотря на активное развитие, словарю эмодзи ещё очень далеко до уровня развития естественных языков. А наиболее активно мы используем только 200 смайликов.

Когда вы используете эмодзи в своих сообщениях, вы идёте на компромисс.

Вряд ли можно заменить такое количество слов естественного языка (даже если выбрать самые используемые) небольшим набором смайликов. Этим же набором пользуются ещё 4 миллиарда людей. Так что, возможность строить из них уникальные высказывания невелика.

Я бы хотел обладать более широкими возможностями. Поэтому я стараюсь точно выражать свои мысли текстом, а не выбирать похожие мысли из готовых шаблонов в виде смайликов.
Таким образом я решаю первую проблему с восприятием текстовых сообщений, сокращая разрыв между реальным человеком и его абстрактным образом. Или, как минимум, не позволяю ему расти.

Человек vs Карикатура

Теперь давайте посмотрим, как замена слов на смайлики отражается на способности донести смысл. Слова уже давно доказали свою состоятельность не только в быту, но и в искусстве. Накопленный словарный запас позволил авторам создать великие произведения от героических эпосов до романтических поэм. Помимо описания окружающей действительности, слова позволяют выразить простые и сложные чувства: страдание, похоть, агония, наглость, страсть, жадность. Когда вы читаете эти слова, у вас появляется микроскопическое ощущение или переживание, связанное с каждым из этих слов.

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

Эмодзи это графические изображения конкретных объектов и абстрактных понятий и переживаний. Есть значок для слова машина, но есть также значок для слова экстатичный. В настоящее время эмодзи ограничены небольшим количеством предметов и эмоций. И всё бы ничего, но сам их тон, tone of voice, в данном случае, стиль, в котором они нарисованы, почти всегда один и тот же.

1. Карикатурный стиль: человеческие проявления, например, в нём преувеличены и доведены до абсурда. Смеющийся человек изображён как лицо, выплескивающее глаза от оргазмического ликования. Человек, желающий любви, становится с двумя мультяшными сердечками, скрывающими глаза, предположительно отсутствующие. Человек, высунувший язык (Бог знает по какой причине), становится мерзким парящим жёлтым шаром.
2. Многие смайлики слишком упрощены и лишены нюансов. Это мир, в котором вы чаще всего находитесь в двух базовых состояниях восторженный или депрессивный. Есть, конечно, нечто среднее, но его используют редко, так как оно не выражает эмоций
   Вместе с тем, обесцениваются (и по этой причине отсутствуют) многие эмоции, лежащие где-то между спокойствием и возбуждением.
3. Тяжело передавать смыслы и интонации при серьёзном или просто спокойном разговоре. Да, они хорошо помогают развлечься, повеселиться, поиронизировать, расслабиться в перерыве между работой. Но они не помогают передать реальную мимику, жесты и отношение говорящего.

По этим причинам многие смайлики отображают реакции, которых не существует у нормальных людей. Так что, если сейчас мне вместо 3 521 дадут 170 тысяч таких же карикатурных смайликов, это не решит проблемы.

Путь наименьшего сопротивления

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

Насколько важно для вас донести свою мысль в том или ином случае решать вам.

Путь наибольшего распознавания

Некоторые исследования показывают, что от 70% до 90% нашей живой коммуникации составляет невербальное общение. Казалось бы, в условиях онлайн-переписки эту функцию на себя могли взять эмодзи. На мой взгляд, это сделать не получилось. Возможно, когда-нибудь

А пока придётся компенсировать недостаток невербальных сигналов повышением качества текста сообщений. Если, конечно, перед нам стоит задача точно доносить свои мысли и достигать взаимопонимания, то есть, обоюдного корректного распознавания.

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

Опять же, карикатурный стиль смайликов неизбежно будет искажать реакцию или интонацию друга, которую вы привыкли слышать в реальной жизни. Это явно сбивает с толку.

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

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

А какие эмодзи раздражают вас? И вообще, согласны ли вы с мнением автора статьи?

---

На правах рекламы

Закажите и сразу начинайте работать! Создание виртуального сервера любой конфигурации в течение минуты, создайте свою конфигурацию в пару кликов.

В течение последних нескольких недель Nikita Prokopov внедрял поддержку эмодзи для Skija. Он решил поделиться несколькими мелкими деталями того, как это самое большое новшество в человеческом общении со времен изобретения буквы работает под капотом.

Примечание переводчика: Хабр не поддерживает эмодзи, поэтому пришлось выкручиваться и заменить эмодзи картинками.

Unicode

Каждый символ на компьютере кодируется числом. Самая популярная кодировка Unicode, а две самые распространенные подвариации UTF-8 и UTF-16.

Unicode выделяет 2²¹ (2 млн) символов, назывемых codepoints. Из этих двух миллионов сейчас определены только ~150k символов. В эти 150 000 символов впихнули все языки, мёртвые и живые и прочие украшательства. Можно использовать различные шрифты, писать задом наперед и кверх ногами: , а так же отобразить GHz как один глиф: .

Направленная вправо двуглавая стрела с оперением и двумя вертикальными штрихами: или семиглазый монстр: . И утка:



Обратите внимание и на блок с египетскими иероглифами (U+13000U+1342F), там много интересного:

Базовые emoji

Эмодзи это просто символы Unicode, которые располагаются тут U+1F3001F6FF и тут U+1F9001FAFF:



Эмодзи ведут себя как обычные буквы, с ними можно делать все операции, что и с буквами (прим. пер.: только не на Хабре!). Когда вы печатаете A, компьютер видит U+0041. Когда вы печатаете компьютер видит U+1F335.

Эмодзи это шрифты

Почему же они отображаются как картинки? Растровые шрифты. вы можете создать веселые png для глифов вместо скучных черно-белых векторов.



Каждая ОС поставлятся с преустановленным шрифтом для эмодзи. В macOS/iOS это Apple Color Emoji. Windows Segoe UI Emoji, Android Noto Color Emoji.

На разных устройствах эмодзи, как и шрифты, выглядят по-разному. Некоторые приложения имеют свои эмодзи: WhatsApp, Twitter, Facebook.

Резервные шрифты

Вы пишите текст каким-то шрифтом, как туда вписывается эмодзи? И почему русский текст выглядит убого в Clubhouse или на Medium?



Вот вы печатаете символ U+1F419, а ваш шрифт, например, San Francisco. Но в шрифте San Francisco нет глифа для U+1F419, поэтому ваша ОС начинает искать другой шрифт, где такой глиф есть.

U+1F419 есть только в Apple Color Emoji. Поэтому вы видите это:.
Какой бы шрифт вы не использовали, эмодзи выглядят одинаково.

Variation selector-16

Некоторые эмодзи зародились в виде пиктограмм ещё в 1993 году, в разделах Miscellaneous Symbols U+2600-26FF или Dingbats U+2700-27FF:



Эти глифы совсем как буквы, черно-белые. Многие шрифты имеют свои (U+2702 BLACK SCISSORS):



У Apple Color Emoji есть своя версия:



Как ОС понимает что отображать <img src="" alt=image/> или если у них одинаковый код U+2702?

Познакомьтесь с U+FE0F, так же известным как VARIATION SELECTOR-16. Это подсказка текстовому рендеру переключиться на эмодзи.



Просто, элегантно и не надо выделять новые codepoints. имеют одно и тоже значение, но немного разный стиль изображения.

Кластеры графем

Здесь мы сталкиваемся с другой проблемой наши эмодзи теперь представляют собой не одну codepoint, а две. Это означает, что нам нужен способ определить границы символа.

Нам поможет кластер графем. Кластер графем это последовательность codepoints, которая рассматривается как единый воспринимаемый человеком глиф.

Графемные кластеры были изобретены не только для эмодзи, они применимы и к обычным алфавитам. это единый кластер графем, даже если он состоит из двух codepoints: U+0055 UPPER-CASE Uза которым следует U+0308 COMBINING DIAERESIS.

Графемные кластеры создают много сложностей для программистов. Вы не можете просто сделать substring(0, 10), чтобы взять первые 10 символов вы можете разделить эмодзи пополам.

Реверс строки нужно делать хитро. U+263A U+FE0F имеет смысл, а U+FE0F U+263A нет.



Наконец, вы не можете просто вызвать .length для string. Ну, можно, но результат вас удивит. Если вы разработчик, попробуйте выполнить в консоли вашего браузера.

Подсказка для программистов: если вы работаете с текстом, приобретите библиотеку, ориентированную на графемные кластеры. Для C, C++m и JVM это может быть ICU, Swift делает все правильно по умолчанию, для других ищите сами.



Длина этой штуки 65, и её нельзя расщеплять. Живите теперь с этим.

Модификатор оттенка кожи

Большинство человеческих эмодзи изображают абстрактного желтого человека. Когда в 2015 году был добавлен оттенок кожи, вместо добавления новой codepoint для каждой комбинации эмодзи и оттенка кожи было добавлено только пять новых codepoints: U+1F3FB..U+1F3FF

Они не должны использоваться сами по себе, но должны быть добавлены к существующим эмодзи. Вместе они образуют лигатуру: (U+1F44B WAVING HAND SIGN) а затем (U+1F3FD MEDIUM SKIN TONE MODIFIER), то получим

не имеет своей собственной codepoint (это последовательность из двух: U + 1F44B U + 1F3FD), но имеет свой собственный уникальный внешний вид. Всего с помощью пяти модификаторов ~280 человеческих эмодзи превратились в 1680 вариаций. Вот несколько танцоров:

Zero-width Joiner

Допустим, ваша подруга только что прислала вам фотографию яблока, которое она выращивает в своем саду. Вам нужно ответитькак? Вы можете отправить WOMAN EMOJI (U+1F469), с прикрепленным колоском риса SHEAF OF RICE (U+1F33E). В итоге получится , но если вы между ними влепите U+200D, то получится фермерка:

U+200D называется Zero-width Joiner, или сокращенно ZWJ. Он работает аналогично тому, что мы видели с оттенком кожи, но на этот раз вы можете объединить два самодостаточных эмодзи в один. Не все комбинации работают, но многие работают, иногда удивительным образом!

Некоторые примеры:



Одна странная несогласованность, которую я заметил, заключается в том, что цвет волос делается через ZWJ, в то время как оттенок кожи это просто модификатор emoji без ZWJ. Почему? Понятия не имею.



К сожалению, некоторые эмодзи не реализованы в виде комбинаций с ZWJ. Я считаю эти упущенные возможности:



Как напечатать ZWJ? Никак. Но вы можете скопировать его отсюда: . Примечание: это особый символ, поэтому ожидайте, что он будет вести себя странно. Вы его не видите, а он есть. (прим пер.: в оригинальной статье есть, а Хабр не позволяет)

Еще одна большая область, где ZWJ на коне это конфигурация семей и отношений. Вот короткий сюжет для иллюстрации:

Флаги

Флаги стран являются частью стандарта Unicode, но по какой-то причине не реализованы в Windows. Если вы читаете это в браузере из Windows Извините!

Флаги не имеют выделенных codepoints. Вместо этого они представляют собой двухбуквенные лигатуры.



Слева Windows, справа Mac

Правда, они не используют настоящие буквы. Вместо этого используется алфавит regional indicator symbol letter (U+1F1E6..1F1FF). Эти буквы не используются ни для чего, кроме составления флагов.

Что произойдет, если вы сложите вместе две случайные буквы? Не так уж много: (за исключением того, что редактирование текста начинает вести себя странно).

Если вы хотите поэкспериментировать, не стесняйтесь копировать и комбинировать из этого алфавита:

Существует 258 допустимых двухбуквенных комбинаций. Вы можете найти их все?

Забавный побочный эффект двухбуквенной лигатуры:

Последовательности тэгов

Двухбуквенные лигатуры это круто, но разве вы не хотите быть круче? Как насчет 32-буквенных лигатур? Вот вам последовательностями тегов.

Последовательность тегов это последовательность обычных эмодзи, за которой следует другая разновидность латинских букв (U+E0020..E007E), заканчивающаяся U+E007F CANCEL TAG.

В настоящее время они используются только для этих трех флагов: Англии, Шотландии и Уэльса:

Keycaps

Не супер-захватывающе, но необходимо для полноты: последовательности Keycaps используют еще одно соглашение.

Это выглядит так: возьмите цифру * или #, превратите ее в эмодзи с U+FE0F, оберните в квадрат с U+20E3 COMBINING ENCLOSING KEYCAP



Всего их 12:

Unicode updates

Unicode обновляется каждый год, и эмодзи являются основной частью каждого выпуска. Например, в Unicode 13 (март 2020 года) было добавлено 55 новых эмодзи.

На момент написания статьи ни последняя версия Mac OS (11.2.3), ни iOS (14.4.1) не поддерживают эмодзи из Unicode 13 типа:

Вот что я вижу в марте 2021 года:

Но, благодаря магии ZWJ, я все еще могу понять, что происходит, просто не самым оптимальным способом.

Заключение

Подводя итог, можно сказать, что это семь способов кодировки эмодзи:

1. Одиночный codepoint
2. Одиночный codepoint + variation selector-16
3. Модификатор оттенка кожи
4. Последовательность с zero-width joiner
5. Флаги
6. Последовательность тэгов
7. Последовательность Keycap

Методы из 1-4 могут быть объединены для построения довольно сложного сообщения:



Если вы программист, не забывайте всегда использовать библиотеку ICU для:

• извлечения подстроки
• измерения длину строки
• реверс строки

Ключевое слово для гугления Grapheme Cluster. Это относится к эмодзи, к диакритическим знакам в западных языках, к индуцированным и корейским шрифтам, поэтому, пожалуйста, будьте внимательны.

UPD: Прошло больше месяца с тех пор, как я написал первоначальный черновик этой статьи. С тех пор я опубликовал еще три записи в блоге и более двадцати на моем канале в Телеграм. Настройки зарекомендовали себя фантастически, мне он очень нравится, и у меня нет желания искать где-либо еще.

Я был давним поклонником iA Writer из-за того, что писал. Я купил оригинальную версию для iPad, оригинальную версию macOS (когда она еще называлась MacOS X), версию для Android и даже ту, которую они переиздали как платное обновление по полной цене. На мой взгляд, в нем есть идеальный баланс между функциями и простотой, дизайном и направленностью.

Вот скриншот первоначальной версии iA Writer от 2011 года:



А вот как это выглядит сейчас, в 2021 году:



Дизайн настолько вне времени, что практически не изменился за 10 лет.
И я этим доволен, я не собираюсь жаловаться. Это здорово и для вдохновения, и для нововведений, и для фактического воплощения. Я искренне рекомендую его всем, кто пишет.

Ограничения iA Writer

Тем не менее, со временем я начал чувствовать, что это не идеально подходит для моего конкретного рабочего процесса:

• iA Writer предназначен для работы с одним документом за раз. Я предпочитаю работать с проектами и папками, переключаясь между файлами.
• Библиотека iA Writer привязана к iCloud, и вы должны хранить там все свои файлы. Недавно я отказался от iCloud и вообще предпочитаю, когда инструменты не определяют, где мне хранить файлы.
• При наличии собственного блога публикация состоит из периодического редактирования CSS/JS/шаблонов, для чего iA Writer, опять же, не оптимизирован.
• Я привык к таким удобствам Sublime, как несколько курсоров, поиск в файлах, Go Anywhere и интеграция с Git. Чувствуешь себя скованно, не имея этого всего под рукой.

Оптимизация Sublime Text для письменной работы

Я решил попробовать повторить то, что делает iA Writer, но внутри Sublime Text. Это мои настройки.

Цветовая схема

К счастью, iA Writer использует абсолютный минимум цветов, поэтому повторить эту часть было проще всего.



Исходный код: github.com/tonsky/sublime-scheme-writer.

В Package Control: Цветовая схема Writer.

P.S. Да, есть и темная версия.

Шрифт

iA Writer дебютировал с проприетарным шрифтом Nitti, но позже переключился на IBM Plex Mono, который выпускается под лицензией Open Font License.

После нескольких попыток и ошибок мне удалось установить размер шрифта, высоту строки и ширину страницы с параметрами, соответствующими тому, что делает iA Writer:



Параметры следующие:

font_face: IBM Plex Mono,
font_size: 16,
line_padding_bottom: 3,
line_padding_top: 3,
wrap_width: 72

Это уже очень хорошее соответствие, но перфекционист во мне хотел получить точное соответствие. Две вещи требовали корректировки: немного увеличенный вес шрифта (текст вместо обычного) и дополнительные 3,5% ширины символа. Поэтому я взял на себя смелость и модифицировал оригинальный IBM Plex Mono, чтобы он соответствовал этим характеристикам.

Сморите:



Совпадает почти идеально! Вы можете получить мою версию IBM Plex Mono на github.com/tonsky/font-writer.

Смена профиля

Мы настроены на то, чтобы писать, но как нам вернуться к кодированию?

Проблема в том, что режим письма влияет на несколько отдельных настроек (в моем случае 19), а не только на шрифт и цветовую схему.

Встречайте Profile Switcher! Он хранит несколько отдельных файлов Preferences.sublime-settings и мгновенно переключается между ними.





Источники: github.com/tonsky/sublime-profiles

В управлении пакетами: Profile Switcher.

P.S. Альтернативный способ поместить настройки для записи в файл настроек для синтаксиса Markdown. Мне этот подход нравится меньше, потому что он влияет, например, на Sublime Merge diff view и все файлы разметки, некоторые из которых я не хочу видеть в режиме записи.

Кроме того, Profile Switcher кажется чем-то, что может быть полезно не только для написания/кодирования duo.

Все вместе (TL;DR)

1. Скачайте и установите шрифт Writer.
2. Через Package Control установите цветовую схему Writer
3. Через Package Control установите Profile Switcher.
4. Создайте профиль Writing с помощью команды Profiles: Create profile.
5. Поместите эти настройки сюда (просто замените все, что у вас есть):

{
caret_extra_width: 2,
draw_centered: правда,
draw_indent_guides: ложь,
draw_white_space: [нет],
font_face: Writer,
font_size: 16,
желоб: ложь,
highlight_line: ложь,
line_padding_bottom: 3,
line_padding_top: 3,
маржа: 10,
scroll_context_lines: 2,
scroll_past_end: 0,5,
word_wrap: правда,
wrap_width: 72,
color_scheme: Пакеты / sublime-scheme-writer / Writer.sublime-color-scheme,
theme: Adaptive.sublime-theme,
}

Вы должны увидеть что-то вроде этого:



Сравните с тем, с чего мы начали:



Чтобы вернуться, используйте команду Профили: сменить профиль и выберите По умолчанию.

Отсутствующие функции

К сожалению, мне не удалось воспроизвести все, что в свою очередь является еще одной причиной, по которой вы могли бы подумать о покупке iA Writer вместо того, чтобы следовать этому руководству. В нем гораздо больше, чем просто классный шрифт.

Дуоширинный шрифт

Чего ждать? Дуоширинный? Это что?

Что ж, это еще одна гениальная идея от iA: сделать W и M 1,5 ширину, оставив остальную часть шрифта моноширинной. Он по-прежнему выглядит и ощущается моноширинным, но Ms и W больше не уродливы без причины. Хотелось бы, чтобы таких шрифтов было больше.



Можем ли мы воспроизвести это в Sublime Text? И да и нет. ST может отображать не моноширинные шрифты, но отключает полужирный/курсивный шрифт, если шрифт не моноширинный.

Похоже на довольно старое ограничение, может быть, при достаточном количестве голосов оно сможет привлечь то внимание, которого заслуживает? Голосуйте здесь, а мы пока будем придерживаться строгой моноширинной версии для написания.

Если вы хотите попробовать дуоширинный шрифт, его можно бесплатно загрузить по ссылке github.com/iaolo/iA-Fonts.

Висячая пунктуация

Функция, которую я люблю с самой первой версии, единственный способ форматировать заголовки Markdown.



Почему это так круто? Если ### выровнено по основному тексту, вам нужно пропустить ### и найти первую значимую букву.

Если он висит снаружи, ничто не сможет помешать вам.

Динамическая типографика

Еще одна вещь, которую сложно воспроизвести в Sublime Text, это динамическая типографика. Насколько я понимаю, iA Writer динамически переключается между несколькими версиями с разным интервалом и весом в зависимости от текущего размера шрифта и разрешения экрана. Это сложно реконструировать и еще сложнее повторить в Sublime Text.

Хотя, с профилями

Подсветка синтаксиса

Во-первых, да, в iA Writer есть подсветка синтаксиса для простого английского. Выглядит это так:



Предположительно, это помогает писать более сбалансированные предложения. Как вы могли заметить, я этим никогда не пользовался :)

Режим фокусировки

В режиме фокусировки выделено только текущее предложение, все остальное затенено. Это помогает попасть в зону, хотелось бы, чтобы это можно было сделать и в ST.

Заключение

Sublime Text можно довольно хорошо настроить и превратить в фантастический инструмент для письменной работы.

Однако специализированное программное обеспечение, такое как iA Writer, может делать больше.

Надеюсь, вы найдете эту информацию полезной или (что еще лучше!) вдохновитесь написать что-нибудь.

6 апреля 2021 г.

---

Наши серверы можно использовать для разработки и продакшена на любом языке.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

В прошлый раз мы с вами научились делать параллельные книги и сделали русско-английский вариант отрывка романа Харпер Ли "Убить пересмешника". Сегодня мы сделаем следующий шаг и создадим полноценную многоязычную книгу на восьми языках.

Напомню, что целью этого проекта является создание инструмента, который поможет людям, изучающим и преподающим иностранные языки, создавать учебные материалы и параллельные книги для улучшения навыков чтения. Глобальная проблема состоит в том, что трудно найти интересный для изучения материал с параллельным переводом, тогда как найти книгу в оригинале и ее русскую редакцию по отдельности гораздо проще.

Сначала сделаем семь книг

Проделаем все на примере романа Булгакова "Мастер и Маргарита", потому что он очень популярен в мире и был переведен на множество языков. Я нашел его версии на английском и немецком (германские языки); белорусском, чешском и украинском (славянские языки); а также на венгерском и китайском языках. Все семь текстов мы выровняем с русским оригиналом, получим семь книг. Затем выровняем их между собой и получим возможность выбирать любые комбинации языков для своей книги в любом порядке. Полные версии книг можно будет скачать в формате pdf в конце статьи.

Начнем с пары венгерский-русский.

Шаг 1. Подготовка текстов

Кратко напомню основные правила подготовки текстов (подробнее смотрите в первой статье, ссылку найдете ниже).

Правила

1. Удалить заведомо лишние строки (информацию об издателе, посвящение, номера страниц, примечания).
2. Проставить метки для автора и названия.
3. Проставить метки для заголовков (H1 самый большой, H5 самый маленький), количество заголовков в текстах должно быть одинаковым.
4. Убедиться, что в тексте нет строк, которые кончаются точкой и при этом не являются концом абзаца (иначе целый абзац разобьется в этом месте на два).

Четвертое правило можно соблюсти для одного текста, так как при создании книги можно будет выбрать на основе какого из них брать информацию о разбиении на абзацы. В нашем случае возьмем русский, потому что мы будем выравнивать все остальные тексты к нему. К тому же для найденного мной оригинального текста это правило уже соблюдено.

Метки

Язык разметки представляет из себя набор меток, которые ставятся в конце предложения:

Благодаря меткам мы извлечем из сырого текста данные о названии произведения, его авторе, названии и местонахождении глав. Это понадобится нам при создании книги.

Текст

В результате должны получиться тексты, похожие на следующие:

Мастер и Маргарита%%%%%title.М.А. Булгаков%%%%%author.ЧАСТЬ ПЕРВАЯ%%%%%h1.Глава 1%%%%%h2.Никогда не разговаривайте с неизвестными%%%%%h2.Однажды весною, в час небывало жаркого заката, в Москве, на Патриарших прудах, появились два гражданина. Первый из них, одетый в летнюю серенькую пару, был маленького роста, упитан, лыс, свою приличную шляпу пирожком нес в руке, а на хорошо выбритом лице его помещались сверхъестественных размеров очки в черной роговой оправе. Второй  плечистый, рыжеватый, вихрастый молодой человек в заломленной на затылок клетчатой кепке  был в ковбойке, жеваных белых брюках и в черных тапочках.   ...

---

MIHAIL BULGAKOV%%%%%author.A MESTER S MARGARITA%%%%%title.ELS KNYV%%%%%h1.ELS FEJEZET%%%%%h2.Ne lljunk szba ismeretlenekkel%%%%%h2.Egy meleg tavaszi estn, az alkonyat rjban, a Patriarsije Prudin kt frfijelent meg. Az egyik negyvenves forma, kvrks, alacsony, kopasz feketeemberke, szrke nyri ltnyt viselt, elegns kalapjt kezben tartotta, gondosanborotvlt arct istentelen nagy mret, fekete csontkeretes ppaszem kestette.Trsa jval fiatalabb s vllasabb volt nla, borzas hajn tarkjig htratolt kockssapka; ltzke kocks sportingbl, gyrtt fehr nadrgbl, fekete szandlblllt....

Количество меток одного типа должно быть одинаковым среди всех текстов. Иначе где-то будет номер и название главы, а где-то нет. После того как мы приготовили тексты, переходим к выравниванию.

Шаг 2. Выравнивание

Как и в прошлый раз, выравнивать будем библиотекой lingtrain-aligner. Код открыт, так что приглашаю в репозиторий.

Попробовать в Colab

Чтобы попробовать выровнять свои тексты без написания кода используйте вот этот Colab блокнот, который мы использовали в прошлый раз. В нем есть инструкции и некоторые комментарии к процессу. В конце можно будет скачать получившуюся двуязычную параллельную книгу как html страничку.

Попробовать локально

pip install lingtrain-aligner

Сначала немного служебного кода:

# Импортируем необходимые модулиfrom lingtrain_aligner import preprocessor, splitter, aligner, resolver, reader, vis_helper# Подготовленные тексты для выравниванияtext1_input = "master_hu.txt"text2_input = "master_ru.txt"with open(text1_input, "r", encoding="utf8") as input1:text1 = input1.readlines()with open(text2_input, "r", encoding="utf8") as input2:text2 = input2.readlines()# Путь до самого главного файла, в котором будет содержаться вся информация о выравниванииdb_path = "master_hu.db"# Определим языки (важно для разбиения на предложения)lang_from = "hu"lang_to = "ru"# Выберем модельmodels = ["sentence_transformer_multilingual", "sentence_transformer_multilingual_labse"]model_name = models[0]# Добавим метки абзацевtext1_prepared = preprocessor.mark_paragraphs(lines1_prepared)text2_prepared = preprocessor.mark_paragraphs(lines2_prepared)# Разобьем тексты на строкиsplitted_from = splitter.split_by_sentences_wrapper(lines1_prepared, lang_from, leave_marks=True)splitted_to = splitter.split_by_sentences_wrapper(lines2_prepared, lang_to, leave_marks=True)

Итого у нас получилось 9460 предложений на венгерском и 8996 предложений на русском. Их-то мы и хотим сопоставить друг другу таким образом, чтобы ничего не потерялось.

Создадим файл для выравнивания. Это SQLite база данных, которую мы заполним входными данными, для дальнейшей обработки.

aligner.fill_db(db_path, lang_from, lang_to, splitted_from, splitted_to)

Чтобы выровнять первую тысячу строк, выполним следующую команду:

batch_ids = range(10)aligner.align_db(db_path,                 model_name,                 batch_size=100,                 window=60,                 batch_ids=batch_ids,                 save_pic=False,                embed_batch_size=25,                 normalize_embeddings=True,                 show_progress_bar=True                )

Произойдет следующее мы запустим процесс выравнивания (детали смотрите в предыдущей статье), для 10 отрезков (batch_ids их номера) по 100 предложений (параметр batch_size). Параметр window задает "перехлест" между этими кусками, чтобы наверняка захватить целевые предложения. В данном случае этот параметр довольно большой, потому что на протяжении всей книги наша "ось выравнивания" может довольно значительно отклоняться.

В качестве спойлера скажу, что для большинства языков в данном случае такие настройки подойдут для всей книги. Для некоторых же текстов отклонения будут слишком сильными и нужно будет либо делать окно очень большим (это приведет к большему количеству ошибок и отрицательно скажется на качестве), либо двигаться медленнее и использовать параметр shift (о нем ниже).

Визуализация

Теперь у нас есть возможность посмотреть на результат первичного выравнивания при помощи модуля vis_helper:

vis_helper.visualize_alignment_by_db(db_path,            output_path="alignment_vis.png",            batch_size=100,            size=(800,800),            lang_name_from=lang_from,            lang_name_to=lang_to,            batch_ids=batch_ids,            plt_show=True)

В параметр batch_ids мы передали те же номера батчей, что и при выравнивании. Если не передавать ничего, то получим картинки для всех данных.

Мы видим, что модель справилась довольно неплохо. Главное здесь, чтобы "ось выравнивания" не вышла за пределы окна, иначе модель не получит на вход отрезок со всеми правильными вариантами.

Теперь необходимо поставить на место выбросы.

Разрешение конфликтов

Механим разрешения конфликтов заключен в модуле resolver. Подробнее о нем, опять же, смотрите в предыдущей статье. Скажу лишь, что он находит промежутки между удачными отрезками выравнивания, и пытается подобрать для этих промежутков подходящий вариант разрешения. Соответственно, параметрами мы можем задавать минимальную длину хорошей цепочки и максимальную длину для конфликта. На практике, хорошо работает такой подход трижды проходим по всему выравниванию с постепенным увеличением максимальной длины конфликта:

steps = 3batch_id = -1 #пройти по всем батчамfor i in range(steps):    # Найти конфликты    conflicts, rest = resolver.get_all_conflicts(db_path, min_chain_length=2+i, max_conflicts_len=6*(i+1), batch_id=batch_id)    # Показать какие конфликты найдены    resolver.get_statistics(conflicts)    resolver.get_statistics(rest)    # Разрешить конфликты    resolver.resolve_all_conflicts(db_path, conflicts, model_name, show_logs=False)    if len(rest) == 0:        break

В конце могут остаться единичные конфликты. Если такие есть, то добиваем их:

# Найти конфликтыconflicts, rest = resolver.get_all_conflicts(db_path, min_chain_length=2, max_conflicts_len=20, batch_id=-1)# Показать какие конфликты найденыresolver.get_statistics(conflicts)resolver.get_statistics(rest)# Разрешить конфликтыresolver.resolve_all_conflicts(db_path, conflicts, model_name, show_logs=False)# Визуализировать выравниваниеvis_helper.visualize_alignment_by_db(db_path,            output_path="alignment_vis.png",            batch_size=100,            size=(800,800),            lang_name_from=lang_from,            lang_name_to=lang_to,            batch_ids=batch_ids,            plt_show=False)

Цикл

Мы выровняли часть книги. Для продолжения выполним те же дейсвтия, но с другими батчами. Возьмем следующие 4000 строк. Мы выравнивали 10 кусков по 100 предложений, поэтому выполним следующую команду:

batch_ids = range(10, 50)aligner.align_db(db_path, \                model_name, \                batch_size=100, \                window=60, \                batch_ids=batch_ids, \                save_pic=False,                embed_batch_size=25, \                normalize_embeddings=True, \                show_progress_bar=True                )

После выравнивания этого куска (это займет чуть больше времени, на моем компьютере это около пяти минут) переходим к разрешению конфликтов, как было описано выше. Затем дальше, задавая новый диапазон строк. Так как предложений на венгерском у нас 9460, а разбитие идет по первому из заданных текстов, то батчей по 100 предложений у нас будет 95 штук.

Если задать диапазон

batch_ids = range(50, 100)

то мы выровняем остаток (вторую половину) книги. После разрешения всех конфликтов у нас останется файл master_hu, содержащий в себе венгерско-русскую версию "Мастера и Маргариты".

Шаг 3. Создание двуязычной книги

Теперь, если мы воспользуемся модулем reader, то сможем сгенерировать русско-венгерскую редакцию книги:

from lingtrain_aligner import reader# Читаем из абзацы и метаданныеparagraphs_from, paragraphs_to, meta = reader.get_paragraphs(db_path, direction="from")# Создаем html с нашей книгойreader.create_book(paragraphs_from, paragraphs_to, meta, output_path = "lingtrain.html")

Это обыкновенная html страничка со встроенными стилями. Для визуализации связей между предложениями можно задавать стили. Например, такой:

reader.create_book(paragraphs_from, paragraphs_to, meta, output_path = f"lingtrain.html", template="pastel_fill")

Можно задавать свои стили, они будут применены к предложениям каждого абзаца циклически:

# Любые применимые к span'ам стилиmy_style = [    '{"background": "linear-gradient(90deg, #FDEB71 0px, #fff 150px)", "border-radius": "15px"}',    '{"background": "linear-gradient(90deg, #ABDCFF 0px, #fff 150px)", "border-radius": "15px"}',    '{"background": "linear-gradient(90deg, #FEB692 0px, #fff 150px)", "border-radius": "15px"}',    '{"background": "linear-gradient(90deg, #CE9FFC 0px, #fff 150px)", "border-radius": "15px"}',    '{"background": "linear-gradient(90deg, #81FBB8 0px, #fff 150px)", "border-radius": "15px"}'    ]reader.create_book(paragraphs_from, paragraphs_to, meta, output_path = f"lingtrain.html", template="custom", styles=my_style)

Выравниваем остальные книги

Таким образом, повторяя третий шаг для остальных текстов, мы получим помимо файла master_hu.db остальные шесть. Отмечу некоторые трудности, с которыми я столкнулся (и, вероятно, столкнетесь вы, когда будете выравнивать свою книгу).

Большая разница в количестве предложений

В английской редакции большое количество предложений в диалогах было переведено как отдельные части, тогда как в оригинале это была прямая речь.

1.  Фу ты черт!  воскликнул редактор,  ты знаешь, Иван, у меня сейчас едва удар от жары не сделался!2. - Даже что-то вроде галлюцинации было,  он попытался усмехнуться, но в глазах его еще прыгала тревога, и руки дрожали.

---

1. 'Pah, the devil!' exclaimed the editor.2. 'You know, Ivan, I nearly had heat stroke just now!3. There was even something like a hallucination...'4. He attempted to smile, but alarm still jumped in his eyes and his hands trembled.

В итоге имеем 9707 предложений на английском против 8996 на русском. Это довольно большое различие, поэтому после первичного выравнивания с параметром window=100 получаем более 1000 конфликтов.

К счастью, после разрешения конфликтов эти кусочки все равно склеятся обратно.

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

Выход за пределы окна

Упомяну польский текст, который тоже был найден, но не подошел по следующей причине. В польском тексте (8190 предложений) у нас слишком часто отсутствуют целые куски текста. Поток выравнивания получается местами обрывистым и окна в 100 уже не хватает, мы постоянно выходим за его пределы:

batch_ids = range(10,12)aligner.align_db(db_path, \                model_name, \                batch_size=200, \                window=100, \                batch_ids=batch_ids, \                save_pic=False,                embed_batch_size=25, \                normalize_embeddings=True, \                show_progress_bar=True                )

Дальнейшее расширение окна увеличит процент ошибок, поэтому мы перейдем в ручной режим и задействуем параметр shift. Этот параметр позволяет сдвигать поток второго текста при расчете батча:

batch_ids = range(10,12)aligner.align_db(db_path, \                model_name, \                batch_size=200, \                window=100, \                batch_ids=batch_ids, \                save_pic=False,                embed_batch_size=25, \                normalize_embeddings=True, \                show_progress_bar=True,                shift=-100 #сдвигаем русский текст                )

Плюсом такого подхода является то, что мы можем уменьшить окно, улучшив первоначальное качество. Минусом является большее количество итераций.

После разрешения конфликтов эти же куски выглядят так:

Отсутствие частей текста

Ручной режим не поможет нам восстановить разрывы, если в каком-то тексте нет соответствующего куска:

Разрешение таких конфликтов приведет к тому, что какому-то предложению станет соответствовать большой отрывок текста на другом языке. Если таких ситуаций одна-две на весь текст (так было с английским и белорусским текстами), то, в принципе, ничего страшного. В случае польского же отсутствовало более 20 отрывков, поэтому я решил его не добавлять.

Второй уровень выравнивания

К этому моменту мы получили семь файлов с выравниваниями master_*.
Их особенностью является то, что все они выровнены относительно одного языка (русского). Казалось бы, давайте просто возьмем абзацы и сходу получим необходимые локализации.

Делаем так и спустя несколько страниц получаем вот это:

Дело в том, что в некоторых текстах (на рисунке это немецкий) одно предложение могло соответствовать двум русским. Если при этом русские предложения считались разными абзацами, то эти абзацы будут слиты в один. Поэтому в обычной двуязычной книжке все будет хорошо, но относительно друг друга структура абзацев у выравниваний будет отличаться. На помощь приходят метаданные, которые хранятся в базе (наши *.db файлы).

Метаданные

В метаданных хранится информация о том, какое предложение какому абзацу соответствует. Можно получить структуру абзацев для каждого текста в виде массива чисел, показывающих номер последнего предложения в абзаце.
Эти массивы можно слить в один по принципу объединения более мелких интервалов:

par_struct_1 = [2, 5, 6, 8, 10, 12, ...]par_struct_2 = [2, 6, 8, 10, 11, 12, ...]res = [2, 6, 8, 10, 12, ...]

Сгенерируем книгу на основе новой разбивки, получим следующий результат:

Стало выглядеть лучше, теперь абзацы формируются относительно русского языка на единой основе.

Индекс

Абзацы починили, но обратим внимание на подсветку предложений и увидим, что во многих местах она разъехалась:

Причина этого в том, что разные тексты имеют разные тенденции по делению на предложения. Чтобы синхронизировать еще и их, придется немного повозиться со следующей сущностью, с индексом.

На архитектурном этапе я придумал хранить структуру выравнивания как индекс. После выравнивания он выглядит он так:

[    --первый батч    [        --первая пара предложений корпуса        [1, "[1,2]", 1, "[1]"],        --вторая и т.д.        [2, "[3]", 2, "[2]"],        [3, "[4,5]", 3, "[3]"],        [4, "[6]", 4, "[4,5,6]"],        ...    ],    --второй батч    [        [1, "[100]", 1, "[105]"],        ...    ],    ...]

В этом примере в первом элементе мы склеили два оригинальных предложения "левого" текста и сопоставили ему первое предложение "правого". Числа в кавычках ссылки на оригинальные предложения, вне кавычек ссылки на фактические данные, которые можно редактировать.

Такая структура дает много возможностей:

• сохраняется информация о слиянии оригинальных строк
• можно добавлять новые элементы в любое место без перезаписи идентификаторов фактических строк
• можно удалять элементы из параллельного корпуса, удалив только из индекса
• можно редактировать данные, не меняя оригинальные строки
• можно пересчитывать отдельные батчи, не затрагивая остальные

Главное для нас здесь то, что из индекса мы можем вытащить структуру элемента корпуса относительно русского языка. Сопоставляя абзацы друг другу, мы опять будем сливать по минимальному принципу. В результате получим разбивку такого типа:

[[1], [2], [3]] -> [[1, 2, 3], [4], [5]] -> [[1], [2], [3]][[4]] -> [[6]] -> [[4]][[5]] -> [[7]] -> [[5, 6]]...

Здесь каждая строка это абзац на трех языках, каждый подмассив а абзаце это номера строк из целевого текста. Таким образом мы поделили каждый набор абзацев на одинаковое число соответствующих друг другу частей.

После исправлений

Посмотрим, как станет выглядеть подсветка теперь:

Так как мы объединяем структуру по минимальному принципу (в данном примере в китайском было меньше всего предложений на абзац), то подсветка стала ровнее, но беднее. Если убрать китайский, то она станет выглядеть так:

Шаг 4. Создание многоязычной книги

В большинстве случаев будет достаточно создания двуязычной параллельной книги и методов get_paragraphs() и create_book(). Но если вы дочитали до этого момента, то самое время попробовать сделать многоязычную книгу.

Логика по выравниванию абзацев для многоязычных книг содержится в методе get_paragraphs_polybook(), в который мы передадим все наши файлы. Так как при выравнивании система опирается на номера исходных строк, то в файлах не должно остаться конфликтов, иначе абзацы не будут сгенерированы. Проверить на отсутствие конфликтов можно таким кодом (как их разрешать вы уже знаете):

from lingtrain_aligner import resolverconflicts_to_solve, rest = resolver.get_all_conflicts(db_path, min_chain_length=2, max_conflicts_len=20, batch_id=-1)#перед генерацией не должно остаться никаких конфликтовresolver.get_statistics(conflicts_to_solve)resolver.get_statistics(rest)

Далее получим набор подготовленных текстов на всех нужных языках:

from lingtrain_aligner import readerdb_path1 = "db/master_de.db"db_path2 = "db/master_uk.db"db_path3 = "db/master_be.db"db_path4 = "db/master_zh.db"db_path5 = "db/master_cz.db"db_path6 = "db/master_en.db"db_path7 = "db/master_hu.db"paragraphs, metas = reader.get_paragraphs_polybook(                        db_paths=[db_path1, db_path2, db_path3, db_path4, db_path5, db_path6, db_path7])

Теперь самое интересное, мы можем выбрать нужные нам языки и создать нашу книжку. Можно, например, взять английский и немецкий, многие учат эти языки в паре.

reader.create_polybook(                lang_ordered=["en", "de", "ru"],                paragraphs = paragraphs,                delimeters = delimeters,                metas = metas,                output_path = "lingtrain_master.tml",                template="none")

Параметр lang_ordered задает набор и порядок языков.

Можно сделать белорусско-китайскую версию:

reader.create_polybook(                lang_ordered=["be", "zh"],                paragraphs = paragraphs,                delimeters = delimeters,                metas = metas,                output_path = "lingtrain_master.html",                template="none")

Можно, конечно, и всё взять:

reader.create_polybook(                lang_ordered = ["ru", "en", "de", "be", "uk", "cz", "hu", "zh"],                paragraphs = paragraphs,                delimeters = delimeters,                metas = metas,                output_path = "lingtrain_master_total.html",                template="none")

Лучше оставлять те выравнивания (*.db файлы), языки которых, вам нужны. Это позволит сохранить как можно больше информации об абзацах. Со стилями все как раньше, можете задавать template (сейчас есть "pastel_fill", "pastel_start"), можете придумывать свои, примеры есть выше и в блокноте на Colab. Если задать template="none", получится чистая книга.

Планы и поддержка

• Дальше планируется поддержать fb2 формат для читалок и добавить подстрочный перевод. Также хочу расширить возможности разметки, добавить вставку картинок. Затем оформить это в виде веб-приложения, чтобы люди могли создавать книги без написания кода.

  
  

• Скидывать тексты для тестирования и выравнивания, делиться предложениями и багами можно в канале http://t.me/lingtrain_books.

  
  

• Подержать проект финансово можно переводом. Деньги пойдут на хостинг веб-приложения и ускорят его разработку.

  
  

Ссылки

Все упомянутые в статье ссылки:

[1] Первая часть статьи

[2] Код lingtrain-aligner на github

[3] Google Colab блокнот с выравниванием

[4] Кот Бегемот с обложки был найден здесь

[5] PDF. Семь параллельных книг "Мастер и Маргарита"

[6] Телеграм-группа

[7] Сбор средств на проект

Иллюстрация: Юлия Прокопова

Я программист. Я не занимаюсь цифровой живописью, обработкой фотографий, видеомонтажом. Меня действительно не волнует широкая гамма или даже правильная цветопередача. Я провожу большую часть своих дней в текстовом браузере, текстовом редакторе и текстовом терминале, глядя на едва движущиеся буквы.

Поэтому я оптимизирую настройки, чтобы показывать действительно, действительно хорошие буквы. Для этого необходим хороший монитор. Не просто нужен, а ОБЯЗАТЕЛЕН. А под хорошим я имею в виду настолько хороший, насколько это возможно. Это мои мысли, основанные на моём собственном опыте того, какие мониторы лучше подходят для программирования.

Дисплеи низкой плотности

Согласно моему опросу программистов, 43% всё ещё используют мониторы с плотностью пикселей на дюйм менее 150:


Какое разрешение dpi у вашего _основного_ монитора? Для вычисления используйте этот инструмент

Почему это проблема? Потому что единственный способ получить хорошие буквы это потратить больше пикселей на букву. Так просто. В прошлом количество пикселей на дисплеях было небольшим, поэтому мы научились жить с этим и даже изобрели несколько очень умных трюков, чтобы сделать нашу жизнь лучше. Две важные вещи, которые нужно понять::

• Времена дисплеев с низким разрешением прошли. Теперь в ходу дисплеи с высоким разрешением.
  
• Хитрости, разработанные для дисплеев с низким разрешением, не могли волшебным образом заставить текст выглядеть хорошо. Это всегда было и остаётся невозможным. Они просто сделали текст немного менее ужасным, но он всё ещё ужасен.

Если вы думаете, что каким-то образом можете сделать так, чтобы ваш дисплей 1080p отображал хороший текст, что ему просто нужно ещё несколько настроек, нет. Этого не случится. Чем скорее вы примете это, тем скорее сможете начать искать реальные решения.

Чтобы сделать мое утверждение более обоснованным, давайте подробно рассмотрим, как на самом деле выглядит текст на дисплее с низким разрешением и что с этим можно сделать (спойлер: не так уж много!).

Не хватает пикселей

Во-первых, для отрисовки символов просто не хватает пикселей. Возьмём шрифт Consolas, разработанный специально для программистов. Microsoft очень много работала, чтобы настроить его для рендеринга на дисплеях с низким разрешением. Мы установили его на 14px, что является значением по умолчанию в VS Code (и люди часто уменьшают его!):


Consolas на 14px, macOS

На таком размере заглавная буква В занимает на экране всего лишь 69 пикселей. У строчных букв только 7 (семь!) вертикальных пикселей. Это не так уж много. У меня больше пальцев на руках, чем здесь пикселей. Независимо от того, насколько хорошо разработан шрифт, трудно что-либо показать, когда всё, что у вас есть, это семь пикселей. Всё, что немного сложнее, чем Т или Н, становится неразборчивым пиксельным беспорядком.

Посмотрите на букву 'g' на картинке выше. Трудно сказать, где начинаются или заканчиваются штрихи, или даже сколько их там. Это просто случайный серый шум или шахматная доска, но не буква. Вот буква:


Consolas на 168px

Действительно, очень обидно наблюдать, как эти прекрасные мелкие детали сжимаются всего лишь в 710 пикселей.

Ужасный хинтинг

Чтобы бороться с проблемой серой мешанины, Windows использует довольно агрессивный хинтинг. По сути, она просто сгибает и перемещает черты букв до ближайшего пикселя, обеспечивая более чёткие границы.

И это работает! Шрифты действительно выглядят лучше с хинтингом, чем без него:


Нет хинтинга (macOS) есть хинтинг (Windows)

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

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


Verdana (k) и Times New Roman Italic (z) перед растеризацией в 13px. Источник

Идея заключается в том, что он будет выглядеть лучше, когда визуализируется в реальных пикселях.

Но даже если мы просто посмотрим на вертикальный хинтинг горизонтальных линий, это всё равно слишком сильно меняет шрифт:



Смотрите, как горизонтальные линии смещаются от их фактического положения в файле векторного шрифта? Ошибка здесь составляет целых пикселя!

Но эй! Если вы никогда не видели Consolas в высоком разрешении, кого волнует, имеет ли 'g' такую же форму или нет? Кого волнует, что линии находятся не в том месте, если вы не знаете, где они должны были быть изначально? Ну, иногда проблемы более очевидны: круги не являются кругами, равные расстояния становятся не равными, пропорции все неправильные, то, что должно быть маленьким, становится огромным и наоборот, и т. д. Здесь:



После перемещения горизонтальных линий в соответствии с пиксельной сеткой (путём смещения их до пикселя!), Windows с трудом разбивает 7 других пикселей на три равных промежутка. К сожалению, альтернатива не лучше:



Из моего личного опыта разработки Fira Code я видел слишком много способов, которыми простая идея просто приклейте края к ближайшему пикселю может пойти не так:





Это игра, в которой просто невозможно победить.

Дробление пикселя

Можете ли вы нарисовать идеальную линию, которая тоньше одного пикселя?

Да. Идея действительно проста. Пиксель вашего дисплея состоит из трёх вертикальных субпикселей, каждый из которых отвечает за свой цвет. Мы можем осветить их по отдельности, эффективно утроив горизонтальное разрешение!



Однако, на практике вы не можете реализовать его буквально, потому что вы просто закончите с рождественским цветным беспорядком:



Так что вам снова придётся идти на компромисс (внутри другого компромисса!), устанавливая предел, как далеко может отклоняться цвет от чёрного:



Это означает, что формы букв не втрое чётче, они, возможно, в полтора раза чётче, но в целом всё ещё довольно размыты.



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

Я пытаюсь сказать, что все эти уловки работают. Иметь их явно лучше, чем не иметь. Для дисплеев с низким DPI всё это просто необходимо. Но в то же время они представляют собой жёсткий компромисс, достигнутый во времена, когда у нас не было лучших дисплеев. Теперь, когда они у нас есть, время для этих трюков ушло.


Consolas 14px с ClearType и хинтингом Consolas 14px @2x

Макбуки с Retina

Макбук с Retina может заставить текст выглядеть хорошо. Однако есть две вещи, которые вы абсолютно должны сделать.

Отключить сглаживание шрифтов

Во-первых, отключите Сглаживание шрифтов в Системных настройках Общие настройки:



Я не уверен, какое сегодня там значение по умолчанию, но убедитесь, что оно выключено в любом случае.

UPD: судя по отзывам, похоже, что значение по умолчанию включено. Обязательно выключите его!

Это название настройки вводит в заблуждение. Раньше она называлась Сглаживание шрифтов на ЖК-экранах (LCD font smoothing), что предполагало субпиксельное сглаживание. Но Apple удалила субпиксельное сглаживание из macOS в 2018 году, в том же месяце, когда выпустила свой последний ноутбук без Retina.

Другое дело, что название предполагает, что ваши шрифты могут вообще не сглаживаться. Это тоже не так.

На самом деле она просто делает шрифт немного жирнее:



Так зачем его отключать? Потому что нет автоматизированного способа сделать шрифт жирнее. Обычно каждый вес шрифта тщательно разработан профессиональным дизайнером шрифтов. Это сложный процесс, который включает в себя миллионы ограничений. Если вы попытаетесь смоделировать его, например, добавив контур к букве, это будет выглядеть ужасно:


Настоящий жирный шрифт и поддельный, который имитируется с контуром

Но это именно то, что делает сглаживание шрифтов в macOS! Вот ещё один пример. MacOS размывает пиксельные границы с помощью сглаживания шрифтов:



Представьте себе дизайнера шрифтов, который тщательно сбалансировал каждую букву, поместил каждую точку с точностью до 1/100 пикселя, только чтобы его проигнорировало тупое программное обеспечение, которое думает, что оно знает лучше.

Что это значит для нас, программистов? Если вы возьмёте шрифт, оптимизированный вручную для определённого размера пикселя (каковыми являются многие программные шрифты, например Input на 11px или Monoid на 12px), он будет отображаться размытым, несмотря на все усилия.



И все остальные шрифты, включая системные, будут немного более размытыми, чем это необходимо.

UPD: Крис Морган упомянул в комментарии, что эта настройка может объяснить, почему так много дизайнеров используют font-weight: 300 в качестве шрифта веб-страницы по умолчанию. Они чрезмерно компенсируют шрифтовое утолщение macOS!

Целочисленное масштабирование

Когда я купил свой первый (и первый в мире) Retina Macbook Pro в 2012 году, это было именно то, что рекламировалось: масштабирование 2, каждый логический пиксель визуализируется на экране 22. Экран 28801800 визуализируется из логического источника 1440900.

К сожалению, с тех пор разум покинул Apple, и в какой-то момент MacBook начал получать странное нецелочисленное масштабирование по умолчанию. Например, экран 28801800 будет иметь логическое разрешение 16801050. Это коэффициент масштабирования 1,7142857143..., или 12/7.

Почему? Я думаю, кто-то в Apple решил, что больше экранной площади лучше продаётся. Проблема в том, что это не такой уж большой рост: всего лишь на 15%. Я имею в виду, что 15% это хорошо, но не принципиально. Самое ужасное, что это происходит ценой потери любого шанса отрисовать любое пиксельно-чёткое изображение вообще!

Давай посмотрим. Коэффициент масштабирования 12/7 означает, что на каждые 7 логических пикселей приходится 12 соответствующих пикселей экрана. Это означает, что каждые 7 пикселей у вас есть шанс нарисовать прямоугольник высотой 7 пикселей, и это ваш единственный шанс выровняться с сеткой пикселей.



Переместитесь на 1 пиксель вверх или вниз и вы проиграете. Сделайте его на 1px выше или короче вы проиграете.



Пиксельно-идеальная линия? Жаль, но нельзя указать 7/12 пикселя в качестве ширины линии. Ещё хуже, что каждая линия 1px выглядит по-разному в зависимости от её вертикального положения:



Неудивительно, что современные иконки в основном состоят из штрихов шириной в один пиксель:


Сверху: масштаб 2, снизу: то же самое после 12/7 даунсэмплинга

Трудно представить себе кого-то, кто специально хочет увидеть такое.

(понятия не имею, почему нижний правый пиксель отсутствует на всех иконках)

Что происходит с текстом? Ничего хорошего. Сначала он визуализируется чётко попиксельно с разрешением 2, затем масштабируется до 85,7142857143...%, чтобы вписаться в физические пиксели:


Monoid на 12px. Верхняя часть: масштаб 2, нижняя часть: то же самое после 12/7 нисходящего масштабирования

Правильно, пользовательский интерфейс даже не отображается в этом странном целевом разрешении. Каждое приложение Mac думает, что оно рендерит в 2, и только после этого ОС масштабирует его до целевого разрешения. Из-за этого двухэтапного процесса изменения размера теряется много точности и нюансов.

На мой взгляд, ничто не может нанести больше вреда внешнему виду пользовательского интерфейса, чем это. Даже старые UI с низким разрешением dpi лучше, так как их линии, по крайней мере, совпадают с пикселями!

И не забывайте: это по умолчанию. Каждый Macbook поставляется с этими настройками. Миллионы людей работают, не зная, что их лишили радости экрана ретина.

К счастью для нас, это легко исправить (по крайней мере, сейчас). Перейдите в раздел Системные настройки Дисплеи, снимите флажок по умолчанию и выберите вместо этого разрешение 2:



Это сделает все на экране немного больше, оставив на экране (немного!) меньше места. Это ожидаемо. Моё мнение таково: ноутбук это ограниченная среда по определению. Дополнительные 15% не превратят его волшебным образом в огромный удобный рабочий стол. Но, по крайней мере, вы можете наслаждаться этим великолепным экраном и чёткими пиксельными шрифтами. В противном случае, зачем вам вообще покупать экран ретина?

ClearType в Windows

Учитывая все эти разговоры о недостатках ClearType и о том, что он просто необходим на дисплеях с низкой плотностью пикселей, следует ли отключить его на дисплее 4k? Теоретически да. На практике нет.

Во-первых, у Windows даже нет пользовательского интерфейса, чтобы отключить его. Я имею в виду, там есть этот флажок:



Но даже если вы его выключите, вам все равно придётся пройти через настройку ClearType. Там просто нет кнопки OK \_()_/.

Если вы выключите его таким образом, он исчезнет в некоторых местах, но будет появляться в других. Я предполагаю, что эти места используют разные API, и одно учитывает эту настройку, а другое нет.



И самое главное, текст без ClearType выглядит как дерьмо. Это не обязательно должно быть так (он выглядит идеально на macOS, например), но особенно на Windows это невыносимо. Я думаю, что они даже не проверяют данную опцию:



Просто для удовольствия я перепечатал все текстовые метки, используя тот же шрифт, размер и цвет, но на macOS:



Но текст ClearType в Windows по-прежнему выглядит хорошо, даже на дисплее 4k. Жаль только, что мы пока не можем отключить ClearType.

Возьмите хороший монитор

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

После этого возникает вопрос, какой монитор вам нужен? Из того, что мы уже обсуждали, должны быть ясны две вещи:

• Это должен быть, по крайней мере, монитор 4k. И 5k, и 6k также великолепны, конечно (кроме LG 5к).
  
• Вам нужно использовать целочисленный коэффициент масштабирования.

Это означает, что если у вас есть монитор 4k (38402160) и вы используете масштабирование 2, вы получите эквивалент 19201080 логических пикселей. Таким образом, это базовый монитор 1080p с точки зрения того, сколько вы можете вместить, но с гораздо более чётким пользовательским интерфейсом и текстом везде.

Теперь может возникнуть соблазн использовать, например, масштабирование 1,5. Это даст вам эквивалент 25601440 логических пикселей, что, как вы можете подумать, намного лучше. Это неправильное использование! Идея монитора 4k заключается не в том, чтобы получить больше пикселей, а в том, чтобы получить идеальный пиксельный рендеринг с высокой плотностью пользовательского интерфейса. В противном случае обычный дисплей 1440p будет работать лучше. Простое правило, которое нужно запомнить: выравнивание пикселей перевешивает всё остальное. Дисплей 1440p лучше отображает контент 1440p, чем дисплей 2160p.

Кроме того, можно запустить дисплей 4k с собственным разрешением 38402160 пикселей. Конечно, это зависит от размера дисплея, но, по моему опыту, даже 27-дюймовые дисплеи 4k слишком малы, чтобы работать при 1. Пользовательский интерфейс будет слишком крошечным.

Миф о значении PPI, запатентованном Apple

Некоторые статьи предполагают, что компьютеры Apple должны использоваться только с дисплеями 220 PPI (пикселей на дюйм), потому что это число Apple сама использует на всех MacBook и iMac. Иногда люди заходят так далеко, что говорят, что дисплеи с другими PPI непригодны для использования в macOS.

Вот что я думаю. PPI определяет физический размер пикселя (220 PPI означает, что на дюйм приходится 220 пикселей, или 1 пиксель имеет ширину 1/220 дюйма). Таким образом, Apple гарантирует, что пиксели на всех её устройствах имеют одинаковый размер. Означает ли это, что элементы управления macOS имеют одинаковый физический размер? Больше нет, после того как Apple начала применять нецелочисленное масштабирование по умолчанию на MacBook.

Тогда почти невозможно гарантировать, что воспринимаемый размер или то, насколько большой пользователь видит элемент управления, является одним и тем же, потому что расстояние до дисплея отличается. Например, в среднем расстояние между моими глазами и экраном составляет 33 см с ноутбуком, но 68 см с монитором. Это двукратная разница!



Это означает, что угловой размер пикселя 1/220 Macbook эквивалентен пикселю монитора 1/110. На самом деле у меня меньше воспринимаемых пикселей на 27-дюймовом мониторе 4k, чем на 15-дюймовом Macbook Pro!

Даже сама Apple это понимает! Их айфоны имеют более высокий PPI, чем макбуки, потому что на них обычно смотрят с более близкого расстояния.

Подводя итог, я не вижу проблемы с 24-дюймовыми дисплеями 4k или даже 27-дюймовыми дисплеями. Я использую оба с macOS и люблю оба, никогда не было никаких проблем. Конечно, 5k или 6k были бы лучше, но они идут в категорию приятно иметь. 4K это обязательный, абсолютный минимум для всех, кто работает с текстом.

Переходите на 120 Гц

Раньше мир делился на два лагеря: дисплеи с высоким разрешением и дисплеи с высокой частотой кадров. Первое было хорошо для текста, второе для игр, и между ними не было середины. Если вы любите играть в экшн-игры, купите оба (и большой стол). Геймерам не нужны были 4K-дисплеи, поскольку ни одна разумная игра не работала бы при 4k @ 120 Гц, а творческие профессионалы не использовали 120 Гц для редактирования фотографий/текста. Конечно, я был в лагере высокого разрешения с 2014 года и никогда не променял бы рендеринг текста ретины на едва заметное обновление частоты обновления.


HP Z27 (4k) и LG 34GL750-B (120 Гц)

Что ж, раскола больше не существует. Поскольку с недавнего времени (да, я слишком ленив, чтобы проверить) вы можете получить и то, и другое! Вы можете найти монитор 4k, работающий на частоте 120 Гц. Собственно, это открытие и послужило главной мотивацией для данной статьи.

Почему 120 Гц?

Если вы, как и я, работаете с текстом, вы можете подумать, что вам не нужны 120 Гц. И были бы правы. Это относится к категории приятно иметь, но если вы ищете способы улучшить свой опыт, это отличный способ.

120 Гц даёт вам несколько существенных улучшений:

• Анимация становится более плавной, вплоть до того момента, когда она начинает казаться непрерывным движением вместо очень быстрого слайд-шоу.
  
• В частности, очень плавная прокрутка. Браузер, редактирование кода, среди прочего.
  
• Вся система чувствует себя гораздо более отзывчивой.
  
• Вы можете играть в игры и работать на одном дисплее.

Конечно, я не могу показать вам, что такое 120 Гц. Но вот что вы можете сделать, чтобы понять идею: переключитесь на 30 Гц и попробуйте работать так некоторое время.

Вы заметите, что всё плохо анимировано и менее отзывчиво. Это связано с тем, что время между обновлениями монитора теперь составляет 32мс вместо 16мс при частоте 60Гц. Это означает, что независимо от того, что вы делаете (нажимаете кнопку, перемещаете мышь), ближайший момент времени, когда компьютер может начать отображать результат, может быть на расстоянии 32мс.

32 мс это очень долго и хорошо заметно. На 60 Гц это время сокращается вдвое: самое долгое, что вам нужно ждать, всего 16мс. на 120Гц это время снова сокращается вдвое: с 16мс до 8мс. в абсолютных числах вы устраняете дополнительные 8мс, что означает, что переход 60 Гц 120 Гц примерно вдвое менее эффективен, чем переход 30 Гц 60 Гц. Но всё-таки стоит того, на мой взгляд.

Что купить?

На самом деле у нас нет особого выбора. Из того, что я могу найти, прямо сейчас на рынке есть только четыре (да, четыре!) дисплея 4k 120+Гц! Думаю, это потому, что спрос не так уж высок, но я рад, что у нас есть хотя бы такой выбор!

Первый Asus ROG SWIFT PG27UQ:



Второй Acer Predator X27:



Третий Acer ConceptD CP7:



Все они очень хорошие мониторы, я уверен. Но цена немного завышена (~2000 долларов), особенно для тех, для кого 120Гц не является вопросом жизни и смерти.

Есть ещё несколько мониторов с диагональю 55 дюймов и более, которые было бы трудно использовать на обычном рабочем столе.

Наконец, по какой-то невероятной удаче у нас действительно есть один недорогой, разумного размера монитор 4k 120 Гц. Это Acer Nitro XV273K:



И это единственное, что у меня есть.

Вещи, на которые стоит обратить внимание (Windows)

В Windows несложно запустить разрешение 4k на частоте 120 Гц. Убедитесь, что ваша видеокарта имеет DisplayPort 1.4, используйте его, вот и всё. Серьёзно, это просто работает.

Вещи, на которые стоит обратить внимание (macOS)

Поддержка MacOS отстой. Официально ни один из компьютеров Apple не поддерживает ничего выше 60 Гц, даже при нормальном разрешении:



Так что покупка этого дисплея была основана на чистой вере. Вот что я понял:

• 4k @ 120 Гц требует 3840 2160 3 bpp 120 Гц 8 = 24 Гбит/с. Чуть ниже 25,92 Гбит / с DisplayPort 1.3 / 1.4.
  
• HDMI 2.0 обеспечивает только 18,0 Гбит/с, поэтому нужно использовать DisplayPort.
  
• Thunderbolt 3 поддерживает DisplayPort 1.4, так что если найти адаптер, всё должно пойти.

Как определить, какой порт у моего Macbook? Легко! Используйте эту диаграмму, предоставленную Apple:



Итак, значок молнии означает Thunderbolt (не путать с портом Lighting!), а железнодорожная стрелка означает USB-C. Теперь просто посмотрите на свой Macbook:



Думаю, разобраться не так просто \_()_/. В качестве альтернативы можно посмотреть на страницу Apple с интуитивно понятным названием SP794:





Итак, прежде всего, что означает Thunderbolt 3 (USB-C)? Это Thunderbolt 3 или USB-C? Это может быть разница между работает безупречно и не работает вообще:



Затем упоминается DisplayPort over USB-C (но у нас есть Thunderbolt 3, а не USB-C!). Страница не указывает версию DisplayPort, и без неё она бесполезна. Она также говорит, что USB 3.1 Gen 2 ограничен 10 Гбит/с, но я думаю, что ограничения USB 3 не распространяются на USB-C? Кроме того, что это за название USB 3.1 Gen 2? Уже приняли USB 3.2?

Ну что ж, Википедия в помощь!

В октябре 2016 года Apple анонсировала обновлённый Macbook Pro с двумя или четырьмя портами Thunderbolt 3, в зависимости от модели. В июне 2017 года Apple анонсировала новые модели iMac с двумя портами Thunderbolt 3, а также iMac Pro с четырьмя портами был выпущен в декабре 2017 года.

8 января 2018 года Intel анонсировала обновление продукта (под кодовым названием Titan Ridge) с усиленной надёжностью и поддержкой DisplayPort 1.4. Новый контроллер периферии теперь может работать как USB sink (совместим с обычными портами USB-C).

Оказывается, Thunderbolt 3 может иметь или не иметь DisplayPort 1.4. Некоторые из них доходят только до DP 1.2. Статья Википедии предполагает, что всё, выпущенное до 2018 года, определённо не будет работать, но после 2018 года это может или не может работать, в зависимости от версии Thunderbolt. Чувствуешь себя потерянным? Используй мою схему:



Думаю, что мы все можем согласиться с тем, что вся эта ситуация Thunderbolt/USB-C является очень сильным претендентом на самый запутанный стандарт порта, когда-либо созданный человечеством.

Короче говоря, мне повезло. Мой Macbook Pro 2019 имел правильный порт, и с адаптером Thunderbolt 3 (USB-C) для DisplayPort всё заработало. Насколько я понимаю, версии портов на устройствах имеют значение, но кабели и адаптеры нет, пока они физически помещаются в отверстие. В моем случае это был конвертер Xiaomi USB-C miniDP и кабель miniDP DP кабель.



Будет ли это работать на вас? Понятия не имею! Надеюсь, что будет. Всё, что я знаю, это то, что вы должны убедиться, что ваш Thunderbolt 3 может нести DisplayPort 1.4. Это волшебное сочетание.

Вещи, на которые стоит обратить внимание (macOS) продолжение

Если до сих пор не было достаточно запутанно, есть ещё кое-что!

Думаю, ваш Macbook должен иметь дискретную видеокарту (На это могут влиять и другие причины, например, пересмотр Thunderbolt. У меня ограниченная тестовая база, но: Macbook Pro 15 2019 работает, Macbook Air 2018 нет, Mac mini 2018 работает только с eGPU). Различные графические карты Intel UHD/Iris не работают. eGPU работает.



Но даже если у вас есть совместимый Mac, с совместимыми портами, совместимыми кабелями, этого недостаточно. Каждый раз, когда я загружаю свой Mac, есть ритуал, который я должен выполнить, чтобы заставить мой дисплей переключиться в режим 120 Гц. Я называю это танец 120 Гц:

1. Полностью загрузить macOS. В этот момент дисплей обычно находится на частоте 60 Гц.
   
2. Перейдите в раздел Системные настройки Дисплеи.
   
3. Удерживая нажатой клавишу Alt/Option (которая с ), нажать на флажок Scaled в Разрешении.
   
   
   
4. Чтобы получить доступ к выбору частоты обновления, установите флажок Показывать режим низкого разрешения. Л логика.
   
   
   
5. Посмотрите селектор Частота обновления. Большую часть времени самый высокий вариант там 60 Гц.
   
   
   
6. Выключите дисплей.
   
7. Подождите пару секунд.
   
8. Включите дисплей.
   
9. Посмотрите ещё раз в разделе Частота обновления. Надеюсь, теперь есть вариант 119,88 герц.
   
   
   
10. Выберите 119,88 герц в разделе Частота обновления.
    
11. Вы великолепны.

Почему это 119,88 герц, а не 120 Гц? Без понятия. Похоже, это работает одинаково. Почему macOS не может вспомнить его? Я не знаю. Почему macOS не видит 120 Гц в качестве опции, пока я не выключу/не включу монитор? Кто знает! Главный вывод заключается в том, что опция 120 Гц может появиться не всегда, но после некоторого танца вокруг неё может появиться, и если это произойдёт, то она действительно работает, несмотря ни на что.

Вся эта ситуация напоминает мне покупку дисплея 4k в 2014 году: есть только пара моделей, порты сбивают с толку, поддержка Apple отстой. Надеюсь, через пять лет 120 Гц станет стандартом. До тех пор мы должны быть благодарны, что, при больших неудобствах, мы, по крайней мере, можем использовать современные дисплеи с macOS. Спасибо, Apple!

Что дальше?

Каждому человеку нужна мечта. В какой-то момент 4k @ 120 Гц станет обыденностью, и мы даже можем увидеть 5k @ 120 Гц и больше. Мы также можем видеть экраны ретина с соотношением 21:9 и даже 32:9 (больше горизонтального пространства), что всегда является желанным дополнением (на самом деле, есть впечатляющий 34WK95U-W, но вы также можете найти его как более короткую версию более традиционного 27MD5KL-B).

Но даже сегодня вы можете заглянуть в будущее, если у вас есть лишние 4000 долларов. Это Dell UP3218K, первый и единственный в мире монитор 8k:


Даже на промо-странице для дисплея 8k Dell публикует только его фотографии размером 1

Плотность пикселей на нём настолько высока (280 PPI), что его, вероятно, лучше всего использовать при масштабировании 300% (чего, конечно, нет в macOS, но есть в Windows). Он также требует двух одновременных кабелей DisplayPort для работы, что опять же не подходит для Mac.

Но даже при 300% он всё равно даст вам эффективное логическое разрешение 25601440, что существенно больше, чем 19201080 современных дисплеев 4k. Больше плотности пикселей и больше разрешения! Что ж, можно помечтать.

Заключение

Подводя итог, вот лучшая установка для программистов:

• Текст не может выглядеть хорошо на дисплеях с низким разрешением.
  
• Дисплеи с высоким PPI перестали быть экзотикой, пришло время переключиться.
  
• Ноутбуки это нормально, но автономный монитор всегда лучше.
  
• Монитор 4k имеет смысл только при масштабировании 2/ 200%.
  
• Если вы хотите пойти дальше, то теперь есть доступные варианты 4k @ 120 Гц.

Удачного кодирования!

Зрители CNN обратили внимание, что в выпуске новостей 12/11/2020 на их официальном YouTube-канале вместо субтитров какая-то каша из обрывков английских слов, сплошным капсом:



Как такое могло получиться? (По состоянию на 1/12/2020, субтитры на YouTube так и не исправлены.)

Stenotype

Американские стенографисты уже больше сотни лет как используют специальные устройства с минимальной 22-клавишной клавиатурой по две клавиши под каждый палец, чтобы минимизировать движения кистей:



Сто лет назад стенотайп был вариантом печатной машинки, и каждая клавиша оставляла оттиск на бумаге. Каретки не было: после каждого аккорда из одной или нескольких одновременно нажатых клавиш, бумага проматывалась на одну строчку вниз. Оттиск каждой литеры приходился всегда на одно и то же место в строке. Клавиши P, R, S, T присутствуют в двух экземплярах каждая под левой и под правой рукой.



Каждый аккорд, и каждая строчка в распечатке, соответствует одному слогу. Промежутков между словами нет, а сами слова передаются фонетически: на показанной выше распечатке застенографирована фраза You should be able to read these short words. Поскольку клавиш меньше, чем букв в английском алфавите, и тем более чем звуков в английской речи, то используется хитроумная система кодирования, например [n] записывается как PB, [l] как HR, дифтонг [e] как AEU, и т.п. При таком кодировании, например, слово gleam записывается как TKPWHRAOEPL аккорд из одиннадцати одновременно нажатых клавиш!

После заседания стенографист должен был сидеть и перепечатывать свою стенограмму на обычной печатной машинке, потому что прочесть её неподготовленному человеку решительно невозможно. В приведённом примере фраза absolutely one hundred percent записана как SHRAOUT HRAOE WOPB HUPBD PERS, что означает [sljutli wn hnd prs] пропущенные слоги должны восстанавливаться по контексту, а гласные не вполне соответствуют словарной транскрипции. Существуют разные системы обозначений и сокращений, так что даже самим стенографистам сложно читать записи один другого. Вот короткий отрывок из учебника стенографии, исправленного владельцем под другую систему:



Считается, что средний темп английской речи 130 слов в минуту, а стенографист со стенотайпом может печатать до 300 слов в минуту, что позволяет записывать разговор даже тогда, когда собеседники перебивают друг друга. Есть аналогичная система Velotype, ориентированная на побуквенную запись вместо фонетической; она позволяет печатать до 200 слов в минуту. Разница вызвана тем, что в английских словах почти всегда букв больше, чем звуков иногда вдвое, как в словах choose [tuz] или earth []. Велотайп был создан в 1939, когда расцвели табуляторы и автоматическая обработка данных; мотивацией для побуквенной записи была более простая расшифровка стенограмм, которую можно было бы поручить даже электромеханической машине. Вместе с прочей оргтехникой электрифицировались и сами стенографические машины: вместо механически соединённых клавиш и литер, печатающих на бумаге, с конца прошлого века используется электроника, удобные дисплеи, цифровое хранение и обработка стенограмм.



В начале этого века возможности компьютерной обработки естественных языков достигли того уровня, чтобы автоматически расшифровывать стенотайповые фонетические стенограммы и превращать SHRAOUT HRAOE в absolutely. Затем поддержка лиц с ограниченными возможностями достигла того уровня, чтобы телеканалы сопровождали прямой эфир субтитрами в реальном времени для тех, кому читать проще, чем слушать. Это значит, что за эфиром следит стенографист со стенотайпом, он записывает речь диктора и других участников передачи, его компьютер расшифровывает стенограмму, при необходимости автоматически переводит её на язык целевой аудитории, и передаёт получившийся текст в эфир и на YouTube.

Судя по всему, 12/11/2020 у CNN в этой сложной системе что-то засбоило, и вывод расшифровщика перемешался с кусками нерасшифрованной стенограммы. Даже если они во время передачи и обнаружили сбой, то решили ничего не трогать, чтобы не отломалось что-нибудь более важное. Случай на Fox News в 2013 наделал гораздо больше шума: в тот раз расшифровщик не справился с именем Джохара Царнаева, устроившего взрыв на Бостонском марафоне, и подставил вместо него в субтитры имя актрисы Зоуи Дешанель.