DollyPapper, да не нужно ничего этого для того, чтобы просто работать в Линуксе. У меня он 10 лет рабочей системой, так не то что что-то пересобирать - разобраться с теми юнитами в системд руки не дошли, хоть и приходится админить пару серверов. Не добавляйте страшилок, ТС и так запуган. И в интернете такого треша про Линукс тоже куда больше, чем в реальности. У меня пара отделов филологов сидят в Линуксе не первый год, никакой консоли слыхом не слыхивали - и чем их система отличается от Виндов, просто НЕ ЗНАЮТ.
Собрать генту или арч - это таки один из способов возненавидеть линукс.
И требуется это примерно стольким же пользователям, сколько автомобилистов каждые выходные проводят в гараже.
Гриша Надежин, да хрен с ним, с хэштегом. В вопросе нужно рассказать, на чем и как вообще стоит этот сайт. Без этой информации вопрос просто бессмысленен.
KPOT1987, вообще-то такая хрень может появляться, если у шрифта нет курсивного начертания или оно криво сделано - без пересчета "очка" глифа.
Я тоже попробовал у себя в Линуксе Sans - и не смог воспроизвести баг.
F1eex, зачем же растровой-то? А4 в растре, да с нормальным разрешением - это хренова туча мегабайт.
Для аккуратной печати есть прекрасный формат PDF, а у Питона есть библиотеки для его формирования.
Ben L, если это не Hello world, грамотное применение ООП как раз позволяет написать основную логику почти человеческим языком, а вот уже в названных по-человечески методах нужных классов опускаться до реального перемешивания байтиков. Здесь у ТС половина проблемы в том, что задача зациклена на одних и тех же данных, и разделять их интерфейсами тупо незачем.
domanskiy, как - сделал? это сделанное - такое же, как то, что надо разбирать?
В PDF кодировка текста зависит от использованного шрифта. Криво локализованный шрифт может выдавать вот такие кракозябры вечно.
Ben L, например, может быть известная обоим классам структура, которую класс, имеющий приватные поля, умеет заполнять, а тот, которому понадобились данные - разбирать. Так она не завязана напрямую на приватные данные класса и может быть более абстрактной. Впрочем, для функций, которым все равно нужен весь кубик, этот вариант не особенно подходит.
lipa44, по описанию - вы мечетесь с несколькими довольно разными вопросами.
Насчет архитектуры - правильное использование ООП именно в том, чтобы давать классам ровно столько данных, сколько им реально нужно для работы, и не давать им никакой информации о том, как реализованы внутри другие классы.
У вас, как я понимаю, главная проблема в том, что все эти решатели и поворачиватели все равно работают со всеми данными состояния, влезая в них по локоть. Не получается инкапсуляция, не работает логика ООП. Так может, вам и не нужно делить эту общую работу с едиными данными на разные классы?
lipa44, вам не нужны геттеры и сеттеры.
Например, для поворота грани вам не нужны цвета всех сторон кубика. Нужна только таблица цветов 5x5 с пустыми углами. В результате получится другая таблица, которую можно вернуть классу состояния кубика. А еще получится, что логика настолько элементарна, что создавать под нее целый класс плюс геттер с сеттером бессмысленно, достаточно создать метод поворота грани. А классу решения уже не потребуются сеттеры для того, чтобы повернуть грань, не так ли?
Валентин, например, потому, что с тех пор, как написан этот скрипт, у Убунты сменилась старшая LTS-версия. А он по-прежнему делает нужную настройку системы под работу в офисе.
И нет, если бы я делал это действительно часто, это доросло бы до Анзибла. А раз в полгода - достаточно простого скриптика.
Валентин, вы это рассказываете человеку, у которого скрипт начальной настройки нового компьютера для офиса включает прописывание MIME-типов для двух типов файлов. Именно по расширению, потому что по содержимому один из этих форматов система считает бинарным файлом, а второй - распространенным графическим, но при этом слегка ошибается.
Пакеты не знают, в которую из них идти, и ничего не работает.