Если вы проводите большую часть дня в терминале и ведёте заметки в Markdown, то, наверняка, смотрели на Obsidian и думали: «Хороший инструмент, но не хочется покидать командную строку». Именно эту нишу и пытается закрыть Impactite. Это терминальный просмотрщик и редактор Markdown, написанный на Python. Основная идея проста: инструмент для заметок должен быть быстрым, управляемым с клавиатуры и удобным в том же окне, где уже работают оболочка, редактор и система контроля версий.

Репозиторий проекта: https://github.com/NeonSalamander/Impactite

Что это такое, простыми словами

Impactite — не веб-приложение, не расширение для браузера и не облачный сервис. Это одна программа на Python с текстовым интерфейсом (TUI). Вы указываете ей папку с Markdown-файлами — ваши заметки — и получаете рабочее пространство из трёх панелей: дерево файлов слева, отрендеренная или редактируемая заметка по центру, облако тегов или статусная панель снизу. Вы перемещаетесь по заметкам с клавиатуры, открываете файлы, редактируете их, ищете по тегам и создаёте ежедневные заметки, не прикасаясь к мыши, если не хотите.

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

Зачем терминальный инструмент?

Для рабочего стола есть хорошие Markdown-редакторы, а для ведения заметок — отличные программы с развитыми ссылками. Но у них свои недостатки: обёртки на Electron, проприетарная синхронизация, требование аккаунта, экосистемы плагинов, которые ломаются при обновлениях. У терминального приложения другие компромиссы.

- Оно запускается мгновенно.

- Работает по SSH.

- Использует ту же папку с обычными `.md`-файлами, которую вы уже храните в Git.

- Не лезет в интернет и не требует регистрации.

- Предсказуемо работает на маломощных машинах.

Impactite подойдёт тем, кто ценит эти качества и готов обойтись без встроенного просмотра изображений или drag-and-drop редактирования.

Что с ним можно делать:

Читать и редактировать Markdown

У каждой заметки в Impactite два режима: просмотр и редактирование. В режиме просмотра Markdown отрисовывается с заголовками, списками, блоками кода, таблицами и встроенным форматированием. В режиме редактирования вы видите исходный Markdown в области с подсветкой синтаксиса. Над редактором есть небольшая панель инструментов, которая одним сочетанием вставляет жирный текст, курсив, заголовки, списки, ссылки, задачи, блоки кода и горизонтальные линии. Если выделить текст перед нажатием кнопки — форматирование обернёт выделение, иначе вставится шаблон, а курсор встанет туда, куда нужно.

Интерактивные чекбоксы

Списки задач отображаются не просто как текст — по ним можно кликать. Щелчок по `- [ ]` в режиме просмотра переключает его в `- [x]`, и файл сразу сохраняется. Для быстрых обновлений статуса — список прочитанного, файл с задачами, чеклист проекта — это убирает лишние действия с переключением в режим редактирования.

Теги, поиск и граф связей

Теги распознаются либо из frontmatter заметки (`tags:`), либо из inline-`#хэштегов`. При запуске все теги индексируются в локальную базу данных и показываются в облаке тегов, каждый со своим устойчивым цветом. Клик по тегу запускает поиск по всем заметкам.

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

Ежедневные заметки и шаблоны

Одним сочетанием клавиш создаётся ежедневная заметка с заполненным frontmatter (`type: daily_note`, `date`), которая сохраняется в настраиваемую папку. Есть и шаблонный движок на основе Jinja2. Шаблоны живут в папке `templates/` внутри каталога заметок и могут использовать переменные вроде `{{title}}`, `{{date}}`, `{{time}}`, `{{author}}` и другие. Новую заметку по шаблону можно создать прямо из интерфейса.

Формы ввода внутри заметок

Заметка, у которой первый ключ frontmatter — `type: form`, в режиме просмотра превращается в интерактивную форму ввода данных. Поля задаются в frontmatter: строки, многострочный текст, целые числа, даты, переключатели, а также выпадающие списки и множественный выбор. При сохранении форма может либо создать новый Markdown-файл, либо сохранить запись в локальную базу данных. Это удобно для регулярных структурированных записей: обзоров книг, проектных задач, замеров веса, встреч с фиксированной структурой.

Псевдо-SQL запросы

Внутри любой заметки можно добавить блок кода с языком `query` или `dataview` и написать небольшой SQL-подобный запрос по заметкам или записям форм. Например:

```query

FROM notes/books

WHERE read = true

SELECT title, author, rating

ORDER BY rating DESC

```

Движок запросов поддерживает `WHERE`, `GROUP BY`, `HAVING`, `SELECT`, `ORDER BY`, `LIMIT` и агрегатные функции `COUNT`, `SUM`, `MIN`, `MAX`, `AVG`. Можно запрашивать frontmatter Markdown-файлов или JSON-записи, сохранённые формами. Если вы пользовались плагином Dataview для Obsidian, концепция покажется знакомой, хотя синтаксис здесь проще.

Избранное, темы и локализация

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

Табличные формулы в духе электронных таблиц

Для тех, кто ведёт структурированные таблицы в заметках, Impactite включает небольшой движок табличных формул, вдохновлённый TBLFM из Emacs Org-mode. После Markdown-таблицы можно добавить комментарий и вычислять суммы столбцов, произведения, средние значения и выражения по ячейкам. Это специфическая функция, но она по-настоящему полезна, если вы отслеживаете бюджеты, часы или баллы прямо в заметках.

Технологический стек

Impactite написан на Python и рассчитан на Python 3.14 и новее. Он построен поверх двух известных библиотек:

- Textual — для текстового интерфейса, виджетов, обработки событий и тем.

- Rich — для рендеринга Markdown, подсветки синтаксиса, таблиц и стилизованного текста.

Среди прочих зависимостей:

- `markdown` и `PyYAML` — для разбора Markdown и frontmatter.

- `Pygments` — для подсветки блоков кода.

- `Jinja2` — для шаблонного движка.

- `ladybug` — для локального индекса тегов и базы записей форм.

Проект использует `uv` для управления зависимостями и сборки, а также стандартный `pyproject.toml`. Установить как самостоятельную команду можно через `uv tool install .`.

Установка и первый запуск

После клонирования репозитория:

```bash

uv sync

uv run impactite

```

Или установить как системную команду:

```bash

uv tool install .

impactite

```

Настройки хранятся в `config.yaml`. В нём указывается путь к заметкам, язык интерфейса, горячие клавиши, настройки редактора и тема. Относительный `notes_path` разрешается относительно файла конфигурации, а не текущей директории, поэтому Impactite можно запускать откуда угодно — он всё равно откроет тот же блокнот.

Кому это подойдёт

Impactite будет хорошим выбором, если:

- Вы уже храните заметки как Markdown-файлы в папке, которую контролируете.

- Много времени проводите в терминале и предпочитаете работу с клавиатуры.

- Хотите теги и ссылки в духе Obsidian, но без полноценного настольного приложения.

- Нужен небольшой самодостаточный способ собирать структурированные данные через формы.

- Хотите, чтобы заметки оставались обычными файлами, которые открываются любым текстовым редактором или Git.

Скорее всего, это не подойдёт, если вы активно используете изображения, PDF, Canvas-доски или совместное редактирование в реальном времени. Инструмент ориентирован на текст и терминал.

Вместо заключения

Impactite — это практичный и предсказуемый Markdown-блокнот для терминала. Он не обещает «изменить ваше мышление»; он просто даёт чистый и быстрый способ читать, писать, организовывать и запрашивать ваши Markdown-заметки, не покидая командной строки. Если такой подход вам близок — попробуйте.

Репозиторий проекта: https://github.com/NeonSalamander/Impactite

Сначала была просто большая карта

В проекте карта живет как мир 20000 на 20000 условных пикселей. Есть тайлы, метаданные, слой POI и координаты маркеров. Фронтенд показывает нужный кусок карты, сервер знает базовые параметры.

Параметры карты в сервере

MAP_ID = 481
DEFAULT_LAYER_ID = 760
MIN_ZOOM, MAX_ZOOM = 12, 18
TILE_SIZE = 256
MAP_WIDTH, MAP_HEIGHT = 20000, 20000

POI - отдельная приятная часть. markers.json хранит точки интереса, а поиск работает по названию, категории и описанию. Если уже есть координаты машины, результаты можно отсортировать по расстоянию. Не нейросеть, не магия, просто нормальная инженерная польза.

Поиск POI с учетом расстояния от машины

def search_markers(query: str, limit: int = 25):
terms = [t for t in query.strip().lower().split() if t]
snap = STATE.get_snapshot()
px, py = snap.get("map_x"), snap.get("map_y")

results = []
for marker in load_markers_data():
hay = " ".join(str(marker.get(k, "")) for k in (
"title", "category", "parent_category", "description", "desc"
)).lower()
if not all(term in hay for term in terms):
continue
item = dict(marker)
if px is not None and py is not None:
item["distance_px"] = round(math.hypot(
float(marker.get("map_x", 0)) - float(px),
float(marker.get("map_y", 0)) - float(py),
), 2)
results.append(item)
return results[:limit]

Дороги пришлось добывать из картинки

Вот тут началась та часть, которую нормальный человек, вероятно, назвал бы “а может, ну его”.

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

На словах это звучит как компьютерное зрение. На практике - как спор с картинкой, которая очень не хочет становиться JSON.

Первый заход был через OpenCV. Я не пытался “понять” карту как человек - я пытался вытащить из изображения схему дорог: белые линии, оранжевые магистрали, пунктир, разрывы. OpenCV делал черновую маску: фильтр по цвету, морфологическая очистка, склейка близких участков, потом скелетизация. Звучит умно, но на практике алгоритм с одинаковой уверенностью находил дорогу, подпись на карте и какой-нибудь декоративный пиксель, которому просто повезло быть нужного цвета.

Поэтому после распознавания пришлось сделать отдельный HTML-редактор карты. Не красивый “редактор уровней”, а рабочую утилиту для ремонта: открыть маску, стереть мусор распознавания, дорисовать недостающие проезды, заштриховать разрывы, сохранить ручные штрихи в JSON и заново собрать road_graph. В этот момент проект окончательно перестал быть “сейчас OpenCV все сам поймет” и стал нормальной инженеркой: автомат нашел основу, человек добил то, что без глаза и здравого смысла не чинится.

Фрагмент из build_road_graph_from_manual_mask.py - выделение дорожного цвета

def classify_pixels(base_rgb: np.ndarray) -> np.ndarray:
hsv = cv2.cvtColor(base_rgb, cv2.COLOR_RGB2HSV)
h, s, v = hsv[..., 0], hsv[..., 1], hsv[..., 2]
r, g, b = base_rgb[..., 0], base_rgb[..., 1], base_rgb[..., 2]

orange = (
(h >= 2) & (h <= 28) & (s >= 35) & (v >= 70) &
(r.astype("int16") - b.astype("int16") >= 35) &
(r.astype("int16") >= g.astype("int16") - 12)
)
return cv2.dilate(
orange.astype("uint8"), np.ones((5, 5), np.uint8), iterations=1
).astype(bool)

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

В итоговом графе в метаданных остался след этой возни: 1387 ручных штрихов, из них 1153 draw, 155 erase, 79 erasePatch. Это не “я нажал одну кнопку и получил навигацию”. Это скорее “я убедил карту сотрудничать”.

Маска дороги -> скелет -> граф

После очистки маска превращается в скелет. Толстая линия дороги становится тонкой ниткой по центру. Потом эта нитка режется на узлы и ребра. Узел - точка на дороге. Ребро - проезд между двумя точками. У ребра есть длина и класс дороги.

Очистка маски и skeletonize

raw_mask = np.asarray(Image.open(args.mask).convert("L")) > 127
count, labels, stats, _ = cv2.connectedComponentsWithStats(
raw_mask.astype("uint8"), 8
)

mask = np.zeros_like(raw_mask, dtype=bool)
for label in range(1, count):
area = int(stats[label, cv2.CC_STAT_AREA])
if area >= args.min_component_area:
mask[labels == label] = True

skeleton = skeletonize(mask)
paths, skeleton_points, key_points = build_skeleton_paths(skeleton)

Узел и ребро - уже не картинка, а данные для навигации

COST = {
"white": 1.00,
"orange": 1.08,
"orange_dashed": 2.60,
"unknown": 9.50,
}


def add_edge(a: int, b: int, length: float, cls: str) -> None:
edges.append({
"from": nodes[a]["id"],
"to": nodes[b]["id"],
"length": round(length, 3),
"cost": round(length * COST.get(cls, COST["unknown"]), 3),
"road_class": cls,
})

Итоговый road_graph.json получился вполне взрослый: 14561 узел, 18612 ребер, шаг сжатия скелета около 6.595 px. Внутри есть классы дорог: white и orange, есть веса, компоненты связности и данные для runtime-достройки разрывов.

То есть когда на телефоне появляется синяя линия маршрута, за ней не CSS и не SVG-фокус. За ней лежит нормальный граф.

A*: потому что маршрут должен думать

Когда граф появился, понадобился поиск пути. Здесь используется A*. Алгоритм не просто ползает по всем дорогам, а идет по графу с учетом уже накопленной стоимости и примерного расстояния до цели.

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

Укороченный A* по дорожному графу

def shortest_graph_path(graph, start_idx, goal_idx, profile=None):
coords = graph["coords"]
adjacency = graph["adjacency"]
gx, gy = coords[goal_idx]

def heuristic(node_idx: int) -> float:
ax, ay = coords[node_idx]
return math.hypot(ax - gx, ay - gy)

heuristic_weight = float((profile or {}).get("heuristic_weight", 1.0))
open_heap = [(heuristic(start_idx) * heuristic_weight, 0.0, start_idx)]
came_from = {start_idx: None}
best_cost = {start_idx: 0.0}

while open_heap:
_priority, cost_so_far, current = heapq.heappop(open_heap)
if current == goal_idx:
path = [current]
while came_from[path[-1]] is not None:
path.append(came_from[path[-1]])
path.reverse()
return path, cost_so_far

for neighbor, _stored_edge_cost in adjacency[current]:
edge_cost = _route_edge_cost(graph, current, neighbor, profile)
new_cost = cost_so_far + edge_cost
if new_cost < best_cost.get(neighbor, float("inf")):
best_cost[neighbor] = new_cost
came_from[neighbor] = current
heapq.heappush(open_heap, (
new_cost + heuristic(neighbor) * heuristic_weight,
new_cost,
neighbor,
))

Почему веса важнее, чем кажется

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

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

Стоимость разных типов дорог

ROAD_CLASS_MULTIPLIERS = {
"white": 1.00,
"orange": 1.08,
"orange_dashed": 2.60,
"synthetic_short": 2.40,
"synthetic_medium": 7.00,
"synthetic_bridge": 34.00,
"unknown": 9.50,
}

Итог серии

На этом этапе проект перестал быть “картой с живой точкой” и стал навигатором. Он умеет искать POI, понимать позицию машины, приклеивать старт и цель к дорожной сети и строить маршрут по графу.

Но дальше вскрылся главный враг. Не UDP, не JavaScript, не телефон. Развязки.

Потому что в 2D две дороги могут пересекаться, а в игре одна идет сверху, другая снизу, третья уходит рампой, и граф такой: “ну вроде все рядом, поехали”.

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

• Задача 1: Генерация документов Word из шаблонов

• Задача 2: Извлечение структурированных данных из файлов Word

• Задача 3: Сравнение двух документов Word на предмет изменений

• Задача 4: Конвертация документов Word в PDF

• Задача 5: Объединение нескольких документов Word в один

• Заключение

Задача 1: Генерация документов Word из шаблонов

Зачем это автоматизировать?

Многие приложения нуждаются в создании динамических документов, таких как:

• Счета и квитанции

• Трудовые договоры

• Сертификаты о завершении

• Ежемесячные клиентские отчёты

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

Рекомендуемый инструмент: python-docx-template

Эта библиотека построена на основе python-docx и интегрирует шаблонизатор Jinja2. Вы просто размещаете заполнители вида {{ customer_name }} внутри шаблона .docx, а затем визуализируете его с вашими данными.

Преимущества:

• Открытый исходный код (лицензия MIT)

• Сохраняет всё форматирование шаблона

• Поддерживает циклы и условия (используя синтаксис Jinja2)

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

Пример кода

Сначала установите библиотеку:

pip install python-docx-template

Создайте файл шаблона invoice_template.docx с заполнителями:

Счёт для {{ customer_name }}

Дата: {{ date }}

Итоговая сумма: ${{ total }}

Затем сгенерируйте итоговый документ:

from docxtpl import DocxTemplate

doc = DocxTemplate("invoice_template.docx")

context = {

"customer_name": "Алиса Джонсон",

"date": "2026-06-03",

"total": "1299.99"

}

doc.render(context)

doc.save("invoice_alice.docx")

Лучшие сценарии использования

• Автоматизированные системы выставления счетов

• Генерация кадровых документов

• Создание сертификатов для онлайн-курсов

Задача 2: Извлечение структурированных данных из файлов Word

Зачем это автоматизировать?

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

Рекомендуемый инструмент: python-docx

python-docx — это фактический стандарт для чтения и записи файлов .docx. Он предоставляет доступ к абзацам, таблицам, элементам форматирования (runs) и стилям. Хотя он не поддерживает файлы .doc (старый двоичный формат), они становятся всё более редкими.

Ограничения, о которых следует знать:

• Библиотека сначала читает все абзацы, затем все таблицы — вы не можете легко восстановить смешанный макет (текст → таблица → текст).

• Для сложных манипуляций со стилями часто приходится работать на уровне XML.

Пример кода

from docx import Document

doc = Document("survey_results.docx")

# Извлечение всех данных из таблиц

for idx, table in enumerate(doc.tables):

print(f"--- Таблица {idx+1} ---")

for row in table.rows:

row_data = [cell.text.strip() for cell in row.cells]

print(", ".join(row_data))

Если вам нужно экспортировать данные в CSV-файл:

import csv

with open("extracted_data.csv", "w", newline="", encoding="utf-8") as f:

writer = csv.writer(f)

for table in doc.tables:

for row in table.rows:

writer.writerow([cell.text.strip() for cell in row.cells])

Лучшие сценарии использования

• Перенос устаревших данных из форм Word в базу данных

• Агрегация финансовых данных из нескольких ежемесячных отчётов

• Анализ содержимого больших коллекций документов

Задача 3: Сравнение двух документов Word на предмет изменений

Зачем это автоматизировать?

Когда контракт, политика или спецификация пересматриваются, вам нужен быстрый способ увидеть, что изменилось. Ручное сравнение «бок о бок» ненадёжно, особенно для длинных документов. Автоматизированное сравнение может мгновенно выделить добавления, удаления и изменения.

Рекомендуемый инструмент: difflib + python-docx

Поскольку создать чистое open-source решение для получения вывода Word с отслеживанием изменений очень сложно, мы будем использовать встроенный в Python модуль difflib для сравнения необработанного текста двух документов. Это даёт вам быстрый, поддающийся скриптованию способ обнаружения различий.

Ограничения:

• Он не создаёт документ Word с отметками о правках (красной строкой).

• Он сравнивает абзацы, а не символы (но вы можете его адаптировать).

• Старые файлы .doc не поддерживаются.

Для юридически значимого сравнения (отслеживание изменений внутри файла Word) вам понадобится коммерческая библиотека, такая как Aspose.Words. Однако для большинства внутренних проверок и обнаружения изменений подхода на основе текста вполне достаточно.

Пример кода

from docx import Document

import difflib

def get_paragraph_texts(docx_path):

doc = Document(docx_path)

return [p.text for p in doc.paragraphs if p.text.strip()]

original = get_paragraph_texts("contract_v1.docx")

revised = get_paragraph_texts("contract_v2.docx")

diff = difflib.unified_diff(

original, revised,

fromfile="Оригинал",

tofile="Изменённый",

lineterm=""

)

for line in diff:

print(line)

Чтобы сделать вывод более читаемым, вы можете записать его в HTML-отчёт:

html_diff = difflib.HtmlDiff()

with open("diff_report.html", "w") as f:

f.write(html_diff.make_file(original, revised, "Оригинал", "Изменённый"))

Лучшие сценарии использования

• Аудит изменений в юридических контрактах

• Отслеживание обновлений в нормативных документах

• Сравнение студенческих работ с эталонным документом

Задача 4: Конвертация документов Word в PDF

Зачем это автоматизировать?

PDF — это универсальный формат для распространения, печати и архивирования. Ручная конвертация (открыть Word → Сохранить как PDF) становится узким местом, когда вам нужно ежедневно конвертировать десятки или сотни файлов. Автоматизация устраняет этот шаг и встраивает конвертацию в ваш конвейер обработки.

Основная рекомендация: docx2pdf (бесплатное, наивысшее качество)

docx2pdf — это не парсер, а тонкая обёртка, которая использует сам Microsoft Word для выполнения конвертации — точно так же, как операция «Сохранить как PDF», которую вы делаете вручную. Поэтому макет, шрифты, таблицы, колонтитулы воспроизводятся идеально.

Требования:

• Microsoft Word должен быть установлен на компьютере (Windows или macOS).

• Скрипт запускается в той же операционной системе, где доступен Word.

Ограничения:

• Не работает на Linux-серверах (нет Word).

• Головные серверные среды (например, Docker без графического интерфейса) не могут надёжно запускать эту библиотеку.

Если вы соответствуете требованиям, это лучшее бесплатное решение из доступных.

Пример кода

pip install docx2pdf

from docx2pdf import convert

# Конвертация одного файла

convert("report.docx", "report.pdf")

# Конвертация всех .docx файлов в папке

convert("input_folder/", "output_folder/")

Запасное решение: Spire.Doc для Python (когда Word недоступен)

Если вы работаете на Linux-сервере или в среде, где Microsoft Office не может быть установлен, вы можете использовать коммерческую библиотеку, такую как Spire.Doc. Она не зависит от Word и работает полностью автономно.

Примечание: Бесплатная версия имеет ограничения — она обрабатывает только первые 500 абзацев и 25 таблиц, а сконвертированные PDF могут содержать водяной знак. Для промышленного использования требуется лицензия.

pip install Spire.Doc

from spire.doc import Document, FileFormat

doc = Document()

doc.LoadFromFile("report.docx")

doc.SaveToFile("report.pdf", FileFormat.PDF)

doc.Close()

Альтернатива (полностью открытый исходный код, кросс-платформенная): Вы можете вызвать LibreOffice из командной строки, используя subprocess:

import subprocess

subprocess.run(["libreoffice", "--headless", "--convert-to", "pdf", "report.docx"])

Это работает на Linux, Windows и macOS, но требует отдельной установки LibreOffice.

Итоги по задаче 4

Задача 5: Объединение нескольких документов Word в один

Зачем это автоматизировать?

Типичные сценарии включают:

• Объединение ежемесячных финансовых отчётов в квартальную сводку

• Слияние отдельных разделов контракта в основной договор

• Сборка пакета документации из нескольких глав

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

Рекомендуемый инструмент: docxcompose

docxcompose принимает один документ в качестве «основного» и добавляет к нему другие, сохраняя базовое форматирование. Библиотека легковесна и проста в использовании.

Ограничения (важно):

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

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

• Проект не поддерживался активно с 2018 года.

Для простых документов (обычный текст, простые таблицы, немного стилей) библиотека работает удивительно хорошо. Для сложных отчётов с разными колонтитулами для каждой главы потребуется более надёжное (скорее всего, коммерческое) решение, или вы можете вручную копировать элементы с помощью python-docx — это больше работы, но полностью контролируемо.

Пример кода

pip install docxcompose

from docxcompose.composer import Composer

from docx import Document

master = Document("chapter1.docx")

composer = Composer(master)

composer.append(Document("chapter2.docx"))

composer.append(Document("chapter3.docx"))

composer.save("full_report.docx")

Если docxcompose не работает с вашими документами, вот более надёжный (но более длинный) подход: перебрать все элементы каждого документа и добавить их в новый основной документ, используя чистый python-docx. Упрощённый фрагмент:

from docx import Document

master = Document()

for file in ["part1.docx", "part2.docx"]:

doc = Document(file)

for element in doc.element.body:

master.element.body.append(element)

master.save("merged.docx")

Имейте в виду, что эта низкоуровневая манипуляция XML может нарушить стили, если выполнять её неаккуратно.

Лучшие сценарии использования

• Объединение простых отчётов с большим объёмом текста

• Добавление приложений к основному документу

• Сборка наборов документации из Markdown, сконвертированных в Word

Заключение

В таблице ниже обобщены рекомендуемые инструменты и их компромиссы.

Автоматизируя эти пять задач, вы можете сэкономить часы повторяющейся ручной работы. Начните с решений с открытым исходным кодом — они покроют большинство повседневных потребностей. Для критически важного форматирования корпоративного уровня (юридически значимое сравнение, идеальная конвертация в PDF на Linux, безупречное слияние) рассмотрите коммерческие библиотеки, такие как Aspose.Words. Но для большинства Python-разработчиков код, показанный выше, уже преобразит то, как вы работаете с документами Word.

Так что вперёд, автоматизируйте генерацию счетов, извлечение данных или конвертацию отчётов — ваш будущее «я» скажет вам спасибо.

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

Зачем?

Уже года полтора загоняю тексты в Suno. Самым мучительным казалось расставлять ударения над сложными словами, которые нейронка коверкает. В соседнем окне открыт текстовый документ с набором гласных под ударением.

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

Но в какой-то момент вспомнил, что яж программист, понял, что хватит это терпеть, и написал плагин под текстовый редактор sublime text. Идея простая — выделил букву, нажал сочетание клавиш — всё, она под ударением. Если тупанул и ударил не ту букву, повторил сочетание или нажал ctrl+z — всё, ударение убрано.

Очень удобно, в особенности для таких суноводов как я.

Давно хотел поделиться, вроде вещь простая, но полезная. Отталкивало то, что непрограммистам оно нафиг не нужно: сперва объясни как установить этот текстовый редактор, потом как добавить скрипт, настроить горячие клавиши, вот это вот всё. Сразу предвижу "Ой, всё! Сделаю по старинке".

НО!

Если вдруг.... ЕСЛИ... Если вам надоело расставлять ударения, копируя их из заготовленного файла, то это реально спасение.

Как сделать?

1. Установить sublime text. Вот официальный сайт: https://www.sublimetext.com/download_thanks?target=win-x64

2. Запустить. Вставить текст.

3. Сделать регистр маленьким (чтобы suno не воспринимала заглавные буквы как ударение). Для этого нужно нажать сочетание клавиш Ctrl+Shift+P и вписать команду Lower Case.

4. В главном меню выбрать пункт Preferences->Browse Packages. Откроется директория с плагинами.

5. Войти в директорию Users и положить туда скрипт AccentLetter.py. Можно также положить файл настроек горячих клавиш:

Вот содержимое файла настроек для вызова команды на Ctrl+shift+U:

[
{ "keys": [ "ctrl+shift+u" ], "command": "accent_letter" }
]

Содержимое самого скрипта не выкладываю -- его можно взять на https://github.com/CJayM/AccentLetters/blob/master/AccentLetter.py

После этого если нажать сочетание клавиш ctrl+shift+u, то выделенная гласная буква станет ударной/безударной.

P.S.

Описанные действия, вроде просты, но кто-то может запутаться. Для упрощения попробовал опубликовать этот скрипт в репозитории с плагинами sublime. Если/когда его примут, то процедура станет сильно проще, так как он станет доступен через Package Control. Но пока можно и на GitHub взять.

P.S.S.

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

Одна из проблем была в том, что система слишком активно пыталась искать скрытый смысл в неоднозначных фразах.

Например:раньше ты лучше помогала. молодец, не тупишь сегодня. ну наконец-то.

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

Поэтому я решил упростить базовую версию:если событие явное - меняем состояние если фраза неоднозначная - не трогаем mood

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

Проверял реакцию на грубость

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

Тут важно было не уйти в крайности: Я больше не могу с тобой говорить... или Ахаха, всё хорошо 😊

В итоге поведение стало ближе к нормальному.

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

Мне кажется, это правильная середина. Близость не должна означать, что можно говорить как угодно.

Починил извинения

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

Исправил логику так, чтобы явное извинение обрабатывалось раньше offended/recovering режимов.

Поймал проблему старого контекста

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

Сначала казалось, что проблема в числах mood-state. Но потом стало похоже, что дело может быть в старом контексте.

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

Из этого появился важный вывод: Nova должна помнить, что произошло, но не должна каждый раз жить в старом prompt-контексте.

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

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

Обдумал будущую систему событий

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

Например, Nova может “посмотреть” фильм и сохранить впечатление. Но это не значит, что она должна вспоминать этот фильм в каждом диалоге.

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

Короткий итог

За эти дни я не делал “вау-фичу”, зато сильно поправил основу эмоционального поведения.

Сейчас стало лучше вот с чем:

меньше ложных обид на неоднозначные фразы прямые оскорбления дают мягкий love_offended извинения получили приоритет извинение + “как ты?” работает естественно старая обида не должна бесконечно возвращаться из prompt будущая система событий будет отдельно от Memory 3.0
Самый главный вывод этого этапа:

AI-компаньон должен помнить прошлое, но не должен быть заложником старого контекста.

И вот это оказалось важнее, чем просто “написать красивый ответ”. Потому что живое поведение - это не только стиль текста. Это ещё и умение правильно решать, что сейчас важно, что уже прошло, а что должно остаться просто частью опыта.