dom1n1k

Если работа мелкая, переписки достаточно.
Если проект мало-мальски объемный и хоть сколько-нибудь сложный, то голосовое общение несомненно нужно. Но не вместо, а дополнительно к переписке. Многие комментаторы выше почему-то их противопоставляют и с умным видом объясняют, почему это неправильно. Ясен пень неправильно заменять переписку болтологией, по которой потом концов не найдешь!
Но даже самое супер-подробное текстовое описание бывает понято неправильно. И, что самое неприятное, при этом обе стороны остаются уверенные в своей правоте, а выясняются нестыковки уже сильно позднее. А при живом разговоре есть возможность сразу же уточнить любой момент, любое сомнение. По тону собеседника даже часто видно, что например тут он запнулся, значит что-то ему не до конца понятно, надо переспросить и уточнить. Иногда полчаса разговора могут заменить неделю переписки.
Разумеется, это НЕ отменяет письма, которое играют роль документального лога. Ещё раз: проговаривать нужно, но в дополнение к переписке.
А вот расшаривать экран я не буду никому, это приватная информация.

Там наверное режимы смешивания задействованы.
Вероятнее всего Multiply, но могут быть и другие, типа Overlay, Color Burn и прочих.
А может быть ещё эффекты какие-то наложены, типа Pattern Overlay.
Как экспортировать? По отдельности - никак. Ну то есть в браузерах поддержка режимов смешивания формально есть, но кроссбраузерность неважная, да и просто геморно будет этот бутерброд поддерживать, смысла просто нет.
Надо экспортнуть уже готовый результат в виде простой однослойной картинки.

Все зависит от того, насколько эта штука должна быть адаптивной.
Если нет - то всё очень просто, граф рисуется картинкой (можно даже фоновой), иконки расставляются по этажам блоками равной ширины.
Если же оно должно тянуться... тогда вариантов намного больше и нельзя так вот заранее сказать, какой предпочтительный. Можно например вообще всё сделать в SVG. Или можно палки картинкой, а красные кружи флекс-блоками. А можно сделать несколько картинок и просто их менять медиа-запросами.
Зависит от ТЗ.

Чтобы заставить элемент наползти на соседа или вылезти за границы родителя.
Что именно непонятно?

В чем проблема-то понятно - в хинтинге. А вот как исправить - это сложнее.
Шрифты, подозреваю сделаны конвертером FontSquirrel, а он грешит подобными делами. И как поправить непонятно - я экспериментировал с его опциями, перебрал кучу вариантов, и в части случаев не удавалось исправить ни при каком сочетании опций.
Попробуйте по возможности альтернативные шрифты с Google Fonts и с Fontstorage.com

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

Насчет CMYK - для визитки он не обязателен.

Вероятно, это леттеринг

Исторически сложилось.
Предполагалось, что веб-сервер - лишь один из серверов, которые висят на вашем доменном имени.
Например, есть компания с доменом company.com
www.company.com - веб-сайт компании
smtp.company.com и pop.company.com - почтовый сервер компании
ftp.company.com - файловый сервер компании
ns.company.com, jabber.company.com, irc.company.com и так далее - куча разных других сервисов у той же самой компании.
На практике же сегодня большинство сайтов - это только сайты, у них нет никаких других сервисов. Очень мало кто держит свой публичный почтовый или файловый свервер. Поэтому company.com === www.company.com

Sublime, Notepad++. Первый погламурнее, второй покондовее.

Как я понимаю, в обоих названных областях если ты занимаешься исследованиями - Python, если пишешь боевой продукт - C++. Всё остальное на порядки реже.

Да, у Яндекса другая проекция - тоже Меркатор, но эллиптическая, а не сферическая.
https://tech.yandex.ru/maps/doc/theory/concepts/co...
Она более точная, но мало распространена и вот есть нюансы с совместимостью.
Конкретно с OL плотно дел не имел, но полагаю ответ надо искать где-то тут:
https://openlayers.org/en/latest/apidoc/ol.proj.html
Если бы использовался Leaflet, тогда
leafletjs.com/reference-1.0.3.html#projection
leafletjs.com/reference-1.0.3.html#crs

Вероятно, шрифт происходит из CD-сборников "1000 шрифтов" времен 90-х годов. Похоже на кустарную солянку.

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

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

Верстать резиново/адаптивно.
Ведь может же на сайт прийти человек, у которого монитор реально 1600? Может. И 1440 может. И ещё куча вариантов.
Верстальщик вообще не должен привязываться к какой-то фиксированной ширине.