v0.5.3
- Мелкие исправления увеличивающие работу конвертера
This commit is contained in:
Igor20264
+186
@@ -0,0 +1,186 @@
|
||||
# Незакрытые задачи после аудита
|
||||
|
||||
Состояние на 10 сентября 2026. Всё перечисленное — то, что осталось после прохода по плану оптимизации. Что уже сделано, см. [audit-report.md](audit-report.md).
|
||||
|
||||
Тесты сейчас: **320 passed, 1 skipped, 174 subtests**, полный прогон 11.85 с. Ничего не закоммичено — всё лежит в staging и рабочем дереве.
|
||||
|
||||
---
|
||||
|
||||
## P0 — сломает сборку, если не сделать
|
||||
|
||||
### `mdexport/` не добавлен в git
|
||||
|
||||
Пакет `mdexport/` (общий обходчик AST для `md2latex` и `md2fodt`) создан, но остался **untracked**, при этом на него уже завязаны:
|
||||
|
||||
- `pyproject.toml` — перечислен в `[tool.hatch.build.targets.wheel].packages`
|
||||
- `md2latex/emitter.py`, `md2latex/escape.py`
|
||||
- `md2fodt/emitter.py`, `md2fodt/escape.py`
|
||||
|
||||
На свежем клоне оба конвертера упадут с `ModuleNotFoundError`, сборка колеса тоже. Локально работает только потому, что файлы лежат на диске.
|
||||
|
||||
```powershell
|
||||
git add mdexport/blocks.py mdexport/inline.py mdexport/labels.py mdexport/__init__.py
|
||||
git status --short mdexport
|
||||
```
|
||||
|
||||
Скомпилированные `.pyc` внутри уже покрыты правилом `__pycache__/`, добавлять их не нужно.
|
||||
|
||||
---
|
||||
|
||||
## P1 — найденный баг, теряет данные
|
||||
|
||||
### `word2md` выбрасывает пункты списка при смене его типа
|
||||
|
||||
Найден при разборе `_handle_paragraph`. Баг **существовал и до рефакторинга**, его сохранили намеренно, чтобы правка осталась поведенчески нейтральной.
|
||||
|
||||
`word2md/walker.py`, строки 406-429. Оба обработчика списков заканчиваются на `return []`, выбрасывая накопленный `out` — притом что `_flush_code(out)` и `_flush_list(out)` внутри уже успели в него дописать:
|
||||
|
||||
```python
|
||||
def _as_numbered_list_item(self, para: _Para, out: list[Block]) -> list[Block] | None:
|
||||
if not paragraph_has_numpr(para.paragraph):
|
||||
return None
|
||||
self._flush_code(out) # может дописать в out
|
||||
...
|
||||
self._append_list_item(ordered, body, out) # внутри вызывает _flush_list(out)
|
||||
return [] # <- out выброшен
|
||||
```
|
||||
|
||||
`_append_list_item` (строки 431-437) при смене типа списка вызывает `_flush_list(out)`, который сбрасывает накопленные пункты в `out`. После чего `return []` их теряет. Соседний `_as_plain_paragraph` (строка 439) в такой же ситуации корректно делает `return out`.
|
||||
|
||||
Воспроизведение: два упорядоченных пункта с `numPr`, за ними пункт-буллет. Оба упорядоченных пропадают из результата. Тот же механизм теряет и забуференный код, если он был.
|
||||
|
||||
Порядок работ: сначала красный тест на исчезающие пункты, потом замена `return []` на `return out` в обоих обработчиках, потом проверка, что побайтовая сверка вывода на остальных документах не поехала (она поедет только там, где баг срабатывал).
|
||||
|
||||
---
|
||||
|
||||
## P1 — решено, но не выполнено
|
||||
|
||||
### Калибровка Courier New 10 пт
|
||||
|
||||
Ты выбрал вариант «10 пт канон по табл. 4.1, добавить калибровку и перевести тест-фикстуру». **Не сделано** — я не успел запустить задачу до конца сессии.
|
||||
|
||||
Что именно нужно, в `md2gost/renderable/paragraph_sizer.py`, метод `Font.get_line_height` (строки 78-83):
|
||||
|
||||
```python
|
||||
# TODO: make it work for all fonts
|
||||
if "Times" in str(self._face.family_name) and self._freetypefont.size == 14:
|
||||
return Pt(16.05)
|
||||
if "Courier" in str(self._face.family_name) and self._freetypefont.size == 12:
|
||||
return Pt(13.61)
|
||||
```
|
||||
|
||||
Сейчас калиброванная ветка есть только для Courier 12 пт. Замеры, снятые в ходе аудита:
|
||||
|
||||
| Размер | Возвращает сейчас | Фактическая высота |
|
||||
|---|---|---|
|
||||
| Courier 10 пт | 11.000 | ≈ 11.34 |
|
||||
| Courier 11 пт | 12.000 | — |
|
||||
| Courier 12 пт | 13.610 (калибровка) | 13.61 |
|
||||
| Courier 14 пт | 16.000 | — |
|
||||
|
||||
Целые числа выдаёт округление FreeType; калибровочные ветки существуют ровно затем, чтобы подменить округление реальным значением Word. Пропорция от 13.61 при переходе 12 → 10 пт даёт примерно 11.34.
|
||||
|
||||
Итог: пока ветки для 10 пт нет, **каждая строка листинга меряется примерно на 3% короче**, и на длинных листингах разъезжаются разрывы страниц.
|
||||
|
||||
Порядок работ:
|
||||
|
||||
1. Добавить ветку `Courier` + размер 10 → `Pt(11.34)`. Лучше сначала подтвердить число замером в Word через COM, а не принимать пропорцию на веру.
|
||||
2. Перевести `tests/__init__.py` (строка 27) с `Pt(12)` на `Pt(10)`, чтобы фикстура совпадала с `style_config.py:305` и табл. 4.1.
|
||||
3. Прогнать `tests/test_paragraph_sizer.py` — серия `test_count_lines_courier1..10` завязана на текущую высоту, ожидаемые значения поедут.
|
||||
|
||||
Не делай пункт 2 без пункта 1 — иначе калиброванная ветка перестанет срабатывать, и замер станет хуже, чем сейчас.
|
||||
|
||||
### `Other_Code/` — 59 файлов, 1158 КБ
|
||||
|
||||
Это была Фаза 4.2 плана, и я её просто не назначил ни одному исполнителю при раскладке работ. Каталог до сих пор полностью в git.
|
||||
|
||||
Ни одного импорта из `md2gost`, `word2md`, `md2latex`, `md2fodt`, `tests/`; не упоминается в `.spec`, `.bat`, `.github/workflows/`, `pyproject.toml`. Единственные ссылки — раздел 12 в `PROJECT.md` и внутренние перекрёстные ссылки самого каталога.
|
||||
|
||||
Команды и три варианта действий расписаны в [git-cleanup.md](git-cleanup.md), раздел 1.
|
||||
|
||||
### Личные документы в корне
|
||||
|
||||
`ТарасовИА_КР_v3.docx` (2326 КБ) и `Практическая_работа_6.docx` (42 КБ) — ФИО прямо в имени файла. Ты сказал, что уберёшь руками; команды и предупреждение про ловушку с `md2gost/Template.docx` в [git-cleanup.md](git-cleanup.md), раздел 2.
|
||||
|
||||
---
|
||||
|
||||
## P2 — открытые вопросы по методичке
|
||||
|
||||
### «С новой страницы» для надписи листинга
|
||||
|
||||
Табл. 4.1 (`docs/reference/method-mirea-2022.txt`, строки 714-715) в блоке «Положение на странице» перечисляет и «Не отрывать от следующего», и «С новой страницы».
|
||||
|
||||
В `md2gost/style_config.py` у стиля `Caption Listing` (строки 278-291) есть `keep_with_next=True`, но нет `page_break_before=True`. Вопрос не праздный: в репозитории есть целая система режимов `--listing-continuation`, так что отсутствие разрыва может быть осознанным выбором. Плюс `Caption.__init__` теперь явно ставит `page_break_before = False`, чтобы не плодить пустые страницы при сочетании с `keep_with_next` — то есть менять придётся согласованно в двух местах.
|
||||
|
||||
Решение нужно принять до того, как кто-то «починит» это по табл. 4.1 в лоб.
|
||||
|
||||
### Правило `heading.empty` ложно срабатывает внутри листингов
|
||||
|
||||
Новое правило в `md2gost/checker/__init__.py` не вырезает fenced-блоки, поэтому одинокая строка `#` внутри блока кода будет засчитана как пустой заголовок. Поведение консистентно с уже существующим `HEADING_RE` в том же файле, то есть это общая для checker'а проблема, а не привнесённая. Чинить имеет смысл сразу для всех проверок заголовков.
|
||||
|
||||
---
|
||||
|
||||
## P3 — не начатое из Фазы 6
|
||||
|
||||
Всё это помечено в плане как опциональное. Ничего из перечисленного не сделано, кроме общего обходчика AST и разбора `word2md/_handle_paragraph`.
|
||||
|
||||
### Разбиение `idef0.py`
|
||||
|
||||
1935 строк (сейчас 74 КБ). God-функции: `_parse_arrow_line` (~177 строк), `_draw_kit_form` (~121), `_route_icom` (~110), `_draw_arrow` (~83), `_layout_arrow_label` (~80).
|
||||
|
||||
Предлагаемая раскладка в пакет `idef0/`: `model.py`, `parse.py`, `layout.py`, `routing.py`, `scene.py`, `draw.py`, `render.py`, с реэкспортом публичного API из `__init__.py` ради тестов. Выигрыша в скорости не даёт, только читаемость.
|
||||
|
||||
Отдельно там же: `_Scene.to_png()` и `_Scene.to_svg()` дважды обходят один и тот же список операций. Можно сгенерировать SVG и растеризовать его в PNG.
|
||||
|
||||
### Разбиение `gui.py`
|
||||
|
||||
1695 строк (82 КБ) в одном классе `Md2GostApp`: главное окно, шесть диалогов, редактор UML-схем на ~270 строк, композер промптов, логика перезаписи файлов, потоки конвертации, загрузка ассетов.
|
||||
|
||||
Раскладка: `gui/windows/`, `gui/widgets.py`, `gui/convert_runner.py`, а `Md2GostApp` оставить тонкой оболочкой.
|
||||
|
||||
### Ленивые импорты
|
||||
|
||||
`md2gost/pipeline.py` (строки 15-19) и `md2gost/gui.py` (строки 11-32) тянут весь конвейер на старте: `docx`, pygments, PIL, lxml. `python -m md2gost --help` платит за это полную цену. Matplotlib и playwright уже ленивые — сделать так же с остальным.
|
||||
|
||||
### Общий сборщик `ConvertRequest`
|
||||
|
||||
`gui.py` (строки 1730-1760) и `__main__.py` (строки 272-317) дублируют маппинг примерно двадцати полей и уже разошлись: дефолт типа документа в GUI `coursework`, в CLI `practice`.
|
||||
|
||||
### Флаг `--open`
|
||||
|
||||
`__main__.py` строки 315-316: `open_when_done=bool(args.debug)`. Открытие готового файла привязано к дебагу, отдельного флага нет, хотя в GUI есть галочка.
|
||||
|
||||
### Скачивание PlantUML блокирует Tk
|
||||
|
||||
`gui.py` строка 1537 — синхронный вызов `fetch_plantuml_jar`, тогда как Graphviz (1576) и Chromium (1622) рядом уже качаются в отдельном потоке.
|
||||
|
||||
---
|
||||
|
||||
## P3 — документация не догоняет код
|
||||
|
||||
### Таблицы модулей в `PROJECT.md` не знают про `mdexport`
|
||||
|
||||
Новый пакет `mdexport` не попал в разделы с картой репозитория и перечнем модулей — исполнитель не владел этим файлом и намеренно его не трогал. Заодно стоит убрать оттуда упоминания удалённых прототипов, если раздел 12 их ещё перечисляет.
|
||||
|
||||
---
|
||||
|
||||
## P4 — замечания исполнителей, оставленные как есть
|
||||
|
||||
- **`uv.lock` в порядке.** `uv lock` отработал с сетью, добавил matplotlib 3.11.1 с транзитивными зависимостями, `uv lock --check` проходит. Лок синхронен и по matplotlib, и по `pywin32` — пересобирать не нужно.
|
||||
- **Playwright закрывается в конце `convert()`.** Это и было целью Фазы 3.4, но у GUI-сценария появилась плата: при каждой следующей конвертации браузер поднимается заново вместо переиспользования. Если mermaid-диаграммы конвертируются часто, стоит подумать про пул с таймаутом.
|
||||
- **Кастомный `--plantuml-jar` другой версии не отражается в ключе кэша.** Префикс использует прибитую константу `PLANTUML_VERSION`. Фингерпринт самого файла закрыл бы дыру, но заставлял бы кэш протухать при каждом появлении и исчезновении jar.
|
||||
- **Версия jar в ключе кэша задевает и Kroki-рендеры**, потому что не-mermaid типы делят один путь кэша между бэкендами. Бамп версии обесценит и записи, отрисованные через Kroki. Это лишняя перерисовка, не более.
|
||||
- **Если одна диаграмма роняет батч-JVM, отбрасывается вся пачка** и каждая диаграмма уходит на свою JVM. Корректно, но стоит одной впустую потраченной JVM.
|
||||
- **`--syntax-highlighting --strict --check` теперь завершается с кодом 1**, потому что новое правило `listing.syntax_highlighting` под `--strict` становится ошибкой. Это ровно то поведение, которое закладывалось, но про него надо помнить в скриптах.
|
||||
- **Playwright изредка печатает `Task was destroyed but it is pending`** на выходе интерпретера при большом комбинированном прогоне. Не воспроизвелось повторно, все тесты проходят, тот же путь закрытия вызывался и до правок.
|
||||
- **Правила игнора `/tmp_*.png` и `/tmp_*.puml`** захватили рабочие черновики `tmp_org_full.*`, `tmp_org_uml.*`, `tmp_arch.*`. Файлы на диске целы, но из `git status` пропали.
|
||||
- **`todo.txt` в корне** остался нетронутым — это твой личный блокнот, я его не трогал и не сливал с этим файлом.
|
||||
|
||||
---
|
||||
|
||||
## Что стоит сделать перед коммитом
|
||||
|
||||
1. `git add mdexport/` — иначе всё сломается на свежем клоне.
|
||||
2. Просмотреть `git diff --cached` и `git diff` — там 34 файла изменений плюс 8095 удалённых строк.
|
||||
3. Прогнать `.venv\Scripts\python.exe -m pytest -q` ещё раз после `git add`.
|
||||
4. Собрать exe одним из `build-exe*.bat` — ни один из билд-скриптов в ходе аудита не проверялся, а `pyproject.toml` и состав пакетов поменялись.
|
||||
@@ -0,0 +1,243 @@
|
||||
# Отчёт по аудиту и оптимизации
|
||||
|
||||
Проведён 9-10 сентября 2026. Незакрытые задачи — в [TODO.md](TODO.md), команды ручной чистки git — в [git-cleanup.md](git-cleanup.md).
|
||||
|
||||
**Ничего не закоммичено.** Всё лежит в staging и рабочем дереве под ревью.
|
||||
|
||||
## Итог одной таблицей
|
||||
|
||||
| | Было | Стало |
|
||||
|---|---|---|
|
||||
| Замер страницы из 5 абзацев | 80.06 мс | 18.08 мс |
|
||||
| Конструирований `Font` за проход | 19 | 0 |
|
||||
| Вызовов `get_text_width` за проход | 814 | 114 |
|
||||
| Конвертация формулы | 13.29 мс | 0.66 мс |
|
||||
| PlantUML, 4 диаграммы, PNG | 4.99 с | 1.25 с |
|
||||
| PlantUML, 4 диаграммы, SVG | 9.02 с | 2.33 с |
|
||||
| Запусков JVM на документ | N (2N в SVG) | 1 (2 в SVG) |
|
||||
| Сквозная конвертация документа | — | на 10-23% быстрее |
|
||||
| Тесты | 54 passed | 320 passed, 174 subtests |
|
||||
|
||||
Объём изменений: 34 файла правок (+1552 / −698), плюс 34 файла удалений (−8095 строк).
|
||||
|
||||
---
|
||||
|
||||
## 1. Исправлено три бага вывода
|
||||
|
||||
Работа шла строго по TDD: сначала три падающих теста, прогон с 9 падениями по ожидаемым причинам, затем правки. Каждый фикс привязан к пункту методички МИРЭА (`docs/reference/method-mirea-2022.txt`).
|
||||
|
||||
### Гиперссылка дублировала свой текст
|
||||
|
||||
`md2gost/renderable/paragraph.py`, строка 44. В `Link.add_run` цикл по сегментам присваивал `docx_run.text = text` вместо `part`, поэтому ссылка с дефисом выводилась полным текстом столько раз, сколько в ней сегментов.
|
||||
|
||||
Красный тест показал это нагляднее всего на интервале: `['100', '150'] != ['100-150', '100-150']`. На сложном слове: `'вопервых' != 'во-первыхво-первых'`.
|
||||
|
||||
Опечатка при копировании из `Paragraph.add_run`, где на строке 104 тот же цикл написан правильно.
|
||||
|
||||
Обоснование: строки 373-376 методички — дефис не отделяется пробелами и используется в сложных словах («во-первых», «физико-математический») и интервалах («100-150 Мб»), поэтому слово не должно рваться при переносе. Ради этого и вставляется отдельный элемент `w:noBreakHyphen` вместо текстового дефиса.
|
||||
|
||||
### Курсив в подсветке синтаксиса не доезжал до XML
|
||||
|
||||
`md2gost/renderable/listing.py`, строка 36. Выражение `style["italic"] in style or None` проверяло, есть ли значение `True`/`False` среди **ключей** словаря стиля. Всегда ложно, курсив не применялся никогда.
|
||||
|
||||
Здесь пришлось разбираться, что вообще считать правильным поведением. Табл. 4.1 методички (строки 716-721) требует для содержимого листинга `Courier New / Начертание Обычный / 10 пт / Цвет Авто (чёрный)`. Стили в `style_config.py:303-314` этому соответствуют, но `DocxParagraphPygmentsFormatter` перекрывает их на уровне run'а, навешивая полужирный и цвет. То есть подсветка как таковая противоречит методичке, а сломанный курсив лишь случайно оказывался ближе к требованию.
|
||||
|
||||
Решение в два шага: выражение исправлено на `style.get("italic") or None`, чтобы флаг делал то, что обещает, и добавлено правило `listing.syntax_highlighting` в checker — предупреждение по умолчанию, ошибка под `--strict`. Флаг выключен по умолчанию, так что это осознанное отклонение, но пользователь узнаёт о нём из отчёта, а не из замечаний преподавателя.
|
||||
|
||||
Заодно добавлен регрессионный страж: при выключенном флаге ни один run в стиле `Code` не должен задавать `w:b`, `w:i` или `w:color`.
|
||||
|
||||
### Пустой заголовок ронял парсер
|
||||
|
||||
`md2gost/extended_markdown/heading.py`, строка 23. `inline_body[0] == "*"` давал `IndexError` на строке `#` без текста. Заменено на `startswith`.
|
||||
|
||||
Плюс правило `heading.empty` в checker'е: пустой заголовок дал бы пронумерованный безымянный раздел в автособираемом содержании. Обоснование — строка 156 методички: «разделы, подразделы, пункты имеют заголовки, четко и кратко отражающие их содержание».
|
||||
|
||||
Побочно выяснилось расхождение в постановке: я просил проверить форму `#*`, но такая строка регуляркой заголовка вообще не матчится — после `#` обязателен пробел или конец строки. Заголовком является только `# *`, эта форма и покрыта тестом.
|
||||
|
||||
---
|
||||
|
||||
## 2. Горячий путь измерения текста ускорен в 4.4 раза
|
||||
|
||||
### Кэш объектов `Font`
|
||||
|
||||
Замер показал, что один `Font()` конструируется 2.62 мс: открывает FreeType `Face`, грузит `ImageFont.truetype` и аллоцирует PIL-канвас 1000×1000. При этом он создавался дважды за вызов `calculate_height` плюс по разу на каждый run.
|
||||
|
||||
Добавлен модульный `_get_font(name, bold, italic, size_pt)` под `lru_cache(maxsize=256)`, все три места конструирования переведены на него. Сам класс `Font` оставлен публичным — существующие тесты создают его напрямую.
|
||||
|
||||
### Скрытая мина в `is_mono`
|
||||
|
||||
Попутно нашлось то, чего в плане не было. Ветка `get_text_width` для моноширинных шрифтов читала `self._face.glyph.advance.x` — то есть тот глиф, который последним оставил в слоте `load_char`. Всегда оказывался `"m"`, потому что единственные вызовы `load_char` живут в `is_mono`. Значение было верным, но верным по случайности: любое постороннее обращение к face молча его сломало бы.
|
||||
|
||||
`is_mono` заменён на свойство `_metrics`, которое снимает и флаг моноширинности, и advance за один проход. Результат теперь не зависит от порядка обращений к слоту глифа. Есть тест, который долбит `load_char` посторонними символами и проверяет, что ширина не поехала.
|
||||
|
||||
### Квадратичный пересчёт ширины слова
|
||||
|
||||
`count_lines` пересчитывал ширину префикса слова после каждого символа, хотя результат читается только в ветке `if c == " "`. Вызов перенесён в две точки: на пробеле и один раз в конце каждого run.
|
||||
|
||||
Вторая точка — та, которую легко пропустить: слово может пересекать границу run'ов, а следующая итерация добавляет свежий слот в `word_parts_widths`, поэтому фрагмент нужно померить до этого.
|
||||
|
||||
Намеренно сохранено одно неочевидное поведение оригинала: `word_part` не сбрасывается после замера на пробеле, потому что исходный код сбрасывал его только внутри ветки `if any(word_parts_widths)`, и фрагмент нулевой ширины продолжал накапливаться через пробел.
|
||||
|
||||
### Синглтон XSLT
|
||||
|
||||
`md2gost/latex_math.py` парсил `mml2omml` с диска и компилировал `etree.XSLT` заново на каждую формулу. Вынесено в ленивый `_mml2omml_transform()`. Оставлено внутри `try`, чтобы битый или отсутствующий stylesheet по-прежнему давал тот же `ValueError` при каждом вызове.
|
||||
|
||||
### Как доказана эквивалентность
|
||||
|
||||
Не чтением кода. Пять эталонных тестовых файлов прогнаны до и после, verbose-вывод сдиффен построчно — идентичен. Плюс `tests/test_paragraph_sizer_cache.py` содержит дословные копии дооптимизационных `Font` и `count_lines` и сверяет с ними новый код на 158 случаях: одиночные и многорановые абзацы, разрыв слова на границе run'а, пустые run'ы, `w:noBreakHyphen`, смешанные полужирный с курсивом, кириллица, длинные неразрывные слова, сдвоенные и хвостовые пробелы, три ширины колонки, оба значения `is_mono`.
|
||||
|
||||
Чтобы убедиться, что корпус не вырожденный, замер в конце run'а был временно отключён — тесты упали в 5 местах.
|
||||
|
||||
---
|
||||
|
||||
## 3. Диаграммы: одна JVM на документ вместо одной на диаграмму
|
||||
|
||||
Перед проектированием было проверено фактическое поведение jar: PlantUML принимает много входных файлов за запуск, но только один флаг `-t<fmt>` (передача `-tpng -tsvg` молча отдаёт только SVG), а относительный `-o` резолвится от каталога каждого входного файла.
|
||||
|
||||
Отсюда конструкция: каждый источник получает свой подкаталог `NNNN/src.puml` с `-o out`. Это заодно решает коллизию двух источников, объявляющих `@startuml SameName`.
|
||||
|
||||
`DiagramFigure.__init__` регистрирует свой блок через `register_pending_diagram()`. Поскольку `Converter.convert()` полностью материализует `list(self.parser.parse())` до рендера, к моменту первого вызова `render_diagram()` очередь содержит весь документ. Первый вызов запускает одноразовый предпроход: готовит все источники, отбрасывает попавшие в кэш, остальные рендерит одной JVM.
|
||||
|
||||
Всё, что упало в предпроходе, остаётся промахом кэша и идёт обычным путём, так что цепочка PlantUML jar → локальный Kroki → удалённый Kroki и режимы `--diagram-fallback` не тронуты. `_render_plantuml_jar_one` теперь обёртка на одну задачу поверх того же батч-раннера, чтобы одиночный и пакетный пути не разъехались.
|
||||
|
||||
### Найденный попутно баг
|
||||
|
||||
Старый код писал `diagram.puml` и искал `diagram.{fmt}`. Любой источник с `@startuml SomeName` производил `SomeName.png`, считался провалом jar и молча уезжал на Kroki. Новая логика забирает то, что jar реально положил в выходной каталог этой диаграммы, и рендерит локально.
|
||||
|
||||
### Остальное по диаграммам
|
||||
|
||||
- Версия jar добавлена в ключ кэша: `PLANTUML_CACHE_PREFIX = f"plantuml-{PLANTUML_VERSION}\n"`. Раньше для plantuml префикс был пустой, и обновление jar отдавало старые PNG.
|
||||
- `ensure_user_schemes()` убран из `render_diagram` — он мигрировал `md2gost.schemes.json` на каждую диаграмму. Безопасно: `load_merged_schemes()` его и так вызывает.
|
||||
- Добавлен `shutdown_diagrams()`, закрывающий сессию Playwright, вызывается из существующего `finally` в `pipeline.convert()`.
|
||||
- Graphviz для DFD теперь отдаёт PNG и SVG из одного процесса `dot`. Проверяет наличие и непустоту каждого выхода и повторяет недостающий формат старым путём, если сборка Graphviz не поддерживает пары.
|
||||
|
||||
Что проверено вживую: путь через jar целиком, включая батч, попадания в кэш, источники с `@startuml Name`, полный прогон `pipeline.convert()`. Graphviz тоже оказался установлен — комбинированный запуск реально произвёл оба файла, и на этом всплыло, что существующий DFD-тест тянулся мимо своего мока.
|
||||
|
||||
Что не проверено: локальный и удалённый Kroki (сервера нет, сетевых вызовов не делалось) — только моки; закрытие браузера в реальной mermaid-конвертации, потому что здешние тесты идут через QuickJS.
|
||||
|
||||
---
|
||||
|
||||
## 4. Двойная работа при рендере убрана
|
||||
|
||||
Все три места сначала обвешаны замерами, потом правлены. Доказательство для каждого — матрица из 4 документов на 7 наборов опций, 28 конвертаций, и побайтовое сравнение `word/document.xml` со снимком, снятым до любых правок. **28 из 28 идентичны.** В матрице `examples/example.md`, `examples/pis_custom.md`, синтетический стресс-документ (многостраничная дробящаяся таблица со слитыми ячейками, многостраничный листинг, три фигуры) и документ с альбомной ориентацией, каждый в режимах продолжений off / legacy / caption / soft, плюс ручное содержание, тип `PIS_custom` и авто-нумерация заголовков.
|
||||
|
||||
### Повторный рендер на границе страницы
|
||||
|
||||
`md2gost/renderer.py`. Раньше: отрендерить блок, померить первый `RenderedInfo`, и если не влезает — выбросить генератор и вызвать `render()` заново. Для таблицы или листинга это пересборка всего поддерева DOCX и повтор всех замеров.
|
||||
|
||||
Решение оказалось точнее, чем «разделить measure и emit», и это выяснилось именно замером. Повтор нужен только когда в `self._to_new_page` реально что-то стоит в очереди: отложенные фигуры вставляются первыми и двигают границу страницы, поэтому блок приходится раскладывать заново уже против оставленного ими состояния. Если очередь пуста, `_flush_to_new_screen()` — no-op, и повторный рендер строит то же поддерево против того же состояния.
|
||||
|
||||
Инструментирование показало, что **во всех срабатываниях на всей матрице очередь была пуста**, то есть второй проход был чистой потерей всегда. Триггером почти везде оказывались заголовки с `page_break_before` и одна фигура — ни разу таблица или листинг.
|
||||
|
||||
Условие дополнено проверкой `and self._to_new_page`. Структура render → measure → flush → re-render сохранена ровно для того случая, когда flush действительно меняет состояние.
|
||||
|
||||
### Подпись рисунка мерилась дважды
|
||||
|
||||
`md2gost/renderable/image.py`. Предложенный в плане `Image.estimate_height()` **не понадобился**: замер показал, что геометрия считается дёшево, а реальная стоимость сухого прохода — построение свежего `Caption` и прогон сайзера по нему. Поэтому подпись создаётся один раз и переиспользуется (сбрасывается в `set_number()`), а сама структура «сухой проход плюс настоящий рендер» не тронута. Именно поэтому вывод и смог остаться идентичным.
|
||||
|
||||
### Кэш замеров абзаца
|
||||
|
||||
Строки таблицы мерились до трёх раз. Теперь `_peek_row_height` и `_build_docx_row` идут через один мемоизированный замер, а выбрасываемый сухой `Caption` в `_start_block_height` убран — `render()` строит подпись один раз и передаёт её внутрь.
|
||||
|
||||
Общий хелпер `measure_paragraph()` в `paragraph_sizer.py` мемоизирует `calculate_height()` в разрезе владеющего renderable. Ключ собран так, чтобы это было безопасно в коде, решающем разрывы страниц:
|
||||
|
||||
- сериализованный XML измеряемого абзаца, а **не** идентичность объекта — правка между двумя вызовами тогда даёт промах кэша вместо устаревшей высоты;
|
||||
- сериализованный `w:pPr` предшественника, а не он целиком — сайзер читает только `pPr`, а привязка `w:p` к телу документа заставляет lxml поднять на него объявления пространств имён, из-за чего полная сериализация выглядела бы как правка и молча промахивалась;
|
||||
- ширина.
|
||||
|
||||
Сверх побайтового сравнения был прогнан «паранойяльный» режим, пересчитывающий значение на каждом попадании в кэш и сверяющий с сохранённым. Вся матрица прошла без единого устаревшего попадания. Строительные леса убраны, а `tests/test_paragraph_sizer_cache.py` получил семь регрессионных тестов: попадание равно свежему расчёту, инвалидация при правке текста и при правке интервалов, ширина и интервалы предшественника как части ключа, контракт приватной копии (вызывающий обнуляет `.before` на новой странице), случай с привязкой предшественника.
|
||||
|
||||
Попутно `page_break_before = False` перенесён из конца `render()` в `__init__`, чтобы оба замера подписи видели один и тот же абзац.
|
||||
|
||||
**Сквозное время конвертации упало на 10-23%** в зависимости от документа.
|
||||
|
||||
---
|
||||
|
||||
## 5. Удалено 6777 строк мёртвого кода
|
||||
|
||||
Больше моей исходной оценки в 5646. Для каждого файла искались импорты модуля, все top-level символы (извлечены через `ast`) и имя файла в `*.spec`, `*.bat`, `*.toml`, `.github/workflows/`, `tests/` и всех живых пакетах.
|
||||
|
||||
| Файл | Строк | Чем был |
|
||||
|---|---|---|
|
||||
| `mm3.py` | 2210 | Монолит + matplotlib-графики |
|
||||
| `mm2.py` | 1551 | Монолитный сборщик DOCX, версия 2 |
|
||||
| `main12.py` | 915 | Ранний `MarkdownGostDocument` |
|
||||
| `font.py` | 860 | Своя реализация Font API |
|
||||
| `parser.py` | 340 | Песочница на mistune |
|
||||
| `asd.py` | 317 | Эксперимент со стилями ГОСТ |
|
||||
| `mm5.py` | 284 | Прототип на mistune |
|
||||
| `mm4.py` | 241 | Построчный прототип |
|
||||
| `main.py` | 32 | Hello-world на python-docx |
|
||||
| `_audit_tmp.py` | 27 | Разовый инспектор DOCX |
|
||||
|
||||
Проверены две ловушки: корневой `parser.py` мёртв, а `md2gost/parser_.py` живой и импортируется в `converter.py`; корневой `font.py` мёртв, а `md2gost/renderable/find_font.py` живой. Единственное вхождение `font` в импортах живых пакетов — `from docx.text.font import Font as DocxFont`, то есть сторонняя библиотека.
|
||||
|
||||
Мёртвый код внутри пакета: убраны `APPENDIX_RE` в `renderer.py` (дублировал константу из `label_pass.py`), `Listing._create_table`, `Converter._output_path`, no-op ветка `isinstance(r, Paragraph): pass` в `label_pass.py`, `_BrowserSession.render_svg()`, `_draw_purpose()` в `idef0.py`, плюс осиротевший `import os` в `paragraph_sizer.py`.
|
||||
|
||||
Две поправки к моему списку. **`gui.main()` оказался живым** — это консольный скрипт `md2gost-gui` в `pyproject.toml`, я ошибочно записал его в мёртвые; оставлен как есть. И комментарий у `Listing._create_table`, утверждавший, что метод держат ради тестов, не подтвердился: тесты ссылаются на модульную функцию `create_table`, а не на метод.
|
||||
|
||||
У `Converter._output_path` заодно убран и параметр конструктора — оставлять параметр, который класс игнорирует, смысла нет. `pipeline.py` был единственным вызывающим, его вызов переведён на именованные аргументы, чтобы остальные позиционные не съехали.
|
||||
|
||||
---
|
||||
|
||||
## 6. Гигиена репозитория
|
||||
|
||||
Снято с отслеживания, файлы остались на диске: `ReadMe.docx`, `md2gost/README.docx`, `tmp_*.docx`, `README.md1`, `examples/example_out.docx`, `examples/toc_*.docx`, `tests/_idef0_preview*`, `latex/mirea/Settings/FiraCode-Regular.otf` (220 КБ, ни одной ссылки в `.tex`), каталог `ad/`, `md2gost.user.json`.
|
||||
|
||||
Перенесено с сохранением истории: `_method_extract.txt` → `docs/reference/method-mirea-2022.txt`, `tests/extended_mardown/` → `tests/extended_markdown/`.
|
||||
|
||||
`md2gost.user.json` содержал реальные ФИО и группу. Убран из индекса, файл на диске остался рабочим, рядом появился `md2gost.user.json.example` с пустыми полями — структура сгенерирована из `UserProfile()` и `DocumentMetadata()`, так что совпадает с тем, что пишет `save_user_profile`.
|
||||
|
||||
### Зависимости
|
||||
|
||||
Легаси-секции `[tool.poetry]`, `poetry.lock` и `requirements.txt` удалены, канон — `[project]` плюс `uv.lock`.
|
||||
|
||||
При этом выяснилось, что `matplotlib` был объявлен **только** в удаляемой Poetry-секции, хотя импортируется в рантайме из `find_font.py` на всех платформах кроме Linux. Добавлено `matplotlib>=3.7; sys_platform != 'linux'` в `[project].dependencies`. Также поправлен `pywin32` — он был добавлен без маркера платформы, что ломало бы `pip install .` на Linux-CI, теперь `pywin32; sys_platform == 'win32'`.
|
||||
|
||||
Поле `readme` исправлено с `README.md` на фактическое `ReadMe.md` — расхождение регистра сломало бы сборку колеса на Linux.
|
||||
|
||||
### CI
|
||||
|
||||
`example-generator.yml` не запускался ни разу: триггер стоял на ветку `main`, а репозиторий на `master`. Исправлено в обоих триггерах. Артефакт грузился из `example.docx`, тогда как `default_output_path` кладёт файл рядом с входным — путь исправлен на `examples/example.docx`. Имя воркфлоу совпадало с `pytest.yml`, переименовано в `Example document`. Обновлены `upload-artifact@v3` → `v4`, `checkout@v3` → `v4`, `setup-python@v3` → `v5`, добавлен `apt-get update` перед установкой шрифтов.
|
||||
|
||||
### Тесты
|
||||
|
||||
Два метода с именем `test_count_lines_courier7` затирали друг друга — второй переименован, расшадоуенный первый **проходит**, латентного бага не вскрылось. Голые `return` в двух win32-тестах `test_pipeline.py` заменены на `@pytest.mark.skipif` (раньше они проходили без единой проверки). Опечатка в имени каталога `extended_mardown` исправлена.
|
||||
|
||||
Кстати про нумерацию: `test_count_lines_courier7` — это индекс 7 в серии от `courier1` до `courier10`, а не размер 7 пт. Третьего размера шрифта не существует, есть только 10 в `style_config` и 12 в фикстуре и калибровке.
|
||||
|
||||
---
|
||||
|
||||
## 7. Дедупликация сиблинг-конвертеров
|
||||
|
||||
`md2latex/emitter.py` и `md2fodt/emitter.py` содержали примерно 150-200 строк почти идентичного обхода AST: диспетчер блоков, инлайн-обходчик, детектор строк библиографии, машина состояний `pending_caption`, словарь русских подписей ссылок.
|
||||
|
||||
Создан отдельный верхнеуровневый пакет `mdexport` — внутрь `md2gost` его класть было нельзя, а размещение в одном из экспортёров сделало бы один бэкенд зависимым от другого. Три модуля:
|
||||
|
||||
- `blocks.py` — `walk_blocks`, `walk_paragraph`, ABC `BlockVisitor`, кортеж отложенной подписи и `take_caption()`, детектор строк библиографии, парсинг заголовка картинки `%id Подпись`, `is_contents_heading`
|
||||
- `inline.py` — `render_inline`, ABC `InlineRenderer`, таблица русских названий ссылок
|
||||
- `labels.py` — `sanitize_label`, параметризованный разделителем: `:` для LaTeX, `-` для XML `NCName`
|
||||
|
||||
`escape_text` остался в бэкендах — там разные задачи, карта символов LaTeX против `saxutils` для XML.
|
||||
|
||||
Эмиттеры сократились на 119 строк, сам общий пакет занял 309, из которых около 120 — новый интерфейсный каркас: объявления абстрактных методов, докстринги, реэкспорты. По суммарному LOC выигрыш скромный, реальный смысл в том, что перечень типов узлов и порядок элементов теперь существуют в одном месте. Раньше новый тип узла приходилось добавлять в две цепочки `if/elif`, которые уже разъехались: в `md2latex` жил мёртвый словарь `cat`, которого на стороне FODT не было вовсе.
|
||||
|
||||
Побайтовая сверка: шесть снимков (`example.tex`, `example.fodt`, `example_emdash.fodt`, `pis_custom.tex`, `pis_custom.fodt`, `pis_custom_emdash.fodt`) совпали по SHA-256. Но образцы не дотягиваются до курсива, полужирного, кодовых вставок, ссылок, разрывов строк, цитат, вложенных списков, отсутствующих файлов картинок и экранирования специальных символов LaTeX — поэтому дооптимизационные эмиттеры были дополнительно выкачены из `HEAD` в temp и прогнаны на стресс-документе, покрывающем эти пути. `stress.tex`, `stress.fodt`, `stress_emdash.fodt` тоже идентичны.
|
||||
|
||||
`word2md/walker.py`: функция `_handle_paragraph` на 207 строк превращена в тело из 27 строк — собирается неизменяемая запись `_Para` с четырьмя фактами, нужными всем ветвям, затем прогоняется кортеж из одиннадцати обработчиков до первого, вернувшего не `None`. Возврат `None` означает «не мой случай, идём дальше», что сохранило два исходных сквозных пути: подпись со стилем подписи, чей текст не парсится, и строку со стилем библиографии без маркера `[n]`.
|
||||
|
||||
Тем же способом проверено и здесь: восемь конвертаций (синтетический DOCX с титульной частью, стилем и полем содержания, подписями продолжений, неразбираемой подписью, кодовыми абзацами, списками через `numPr` и через отступ, разрывами страниц, строкой библиографии без маркера, плюс полный круг `example.md` → DOCX → Markdown, каждая с переключением `keep_toc_pages` и `emit_page_breaks`) дают побайтово идентичный Markdown против дорефакторного обходчика.
|
||||
|
||||
Попутно убраны три мёртвых фрагмента: повторный вызов чистой функции при `parsed is None and kind`, no-op `if kind and parsed.kind != kind: pass` (из-за которого весь поиск `caption_kind_from_style` оказывался мёртвым, вместе с импортом), и `try/except` вокруг `re.match` по значению, которое всегда строка.
|
||||
|
||||
**Два следствия, требующие внимания.** `mdexport/` остался untracked, при этом уже прописан в `pyproject.toml` и импортируется обоими конвертерами — это пункт P0 в [TODO.md](TODO.md). И при разборе обнаружился реальный баг потери данных в обработчиках списков `word2md`, существовавший и до правок: он сохранён намеренно ради поведенческой нейтральности и описан в [TODO.md](TODO.md) с механизмом и порядком починки.
|
||||
|
||||
Спецификации PyInstaller править не пришлось — они идут по статическим импортам.
|
||||
|
||||
---
|
||||
|
||||
## Как это делалось
|
||||
|
||||
Работа шла шестью параллельными исполнителями, разведёнными по владению файлами, чтобы не наступать друг другу на правки. Волна 1: фиксы багов, кэш горячего пути, диаграммы, чистка репозитория. Волна 2: двойной рендер вместе с мёртвым кодом внутри пакета, поскольку они делят `renderer.py`. Отдельным потоком шли сиблинг-конвертеры — единственная область, не пересекавшаяся ни с чем.
|
||||
|
||||
Три требования, заданных жёстко всем исполнителям: правки, меняющие раскладку страницы, доказываются побайтовым сравнением вывода, а не чтением кода; вопросы Фазы 1a не трогаются без решения владельца; коммиты и деструктивные git-команды запрещены.
|
||||
@@ -0,0 +1,205 @@
|
||||
# Ручная чистка git
|
||||
|
||||
Команды для удаления мусора из репозитория. Всё под PowerShell — помни, что `&&` там не работает как разделитель, используй `;` или отдельные вызовы.
|
||||
|
||||
Файл описывает то, что осталось сделать руками. То, что уже сделано агентами и лежит в staging, перечислено в конце для сверки.
|
||||
|
||||
---
|
||||
|
||||
## 0. Подготовка
|
||||
|
||||
Чтобы git печатал кириллические имена читаемо, а не как `\320\242...`:
|
||||
|
||||
```powershell
|
||||
git config core.quotepath false
|
||||
```
|
||||
|
||||
Снимок текущего состояния — на случай, если захочется откатиться:
|
||||
|
||||
```powershell
|
||||
git status --short > ..\git-status-before.txt
|
||||
git stash list
|
||||
```
|
||||
|
||||
Ничего из перечисленного ниже не переписывает историю и не трогает remote, так что откат всегда возможен через `git restore --staged <path>`.
|
||||
|
||||
---
|
||||
|
||||
## 1. `Other_Code/` — 59 файлов, 1158 КБ
|
||||
|
||||
Что это: схемы OOXML (`*.xsd`), скрипты pack/unpack/validate, `document.py`, `utilities.py`, `docx-js.md`, `SKILL.md`. Справочный материал.
|
||||
|
||||
Почему можно убирать: ни одного импорта из `md2gost`, `word2md`, `md2latex`, `md2fodt`, `tests/`, ни упоминания в `.spec`, `.bat`, `.github/workflows/`, `pyproject.toml`. Единственные ссылки — раздел 12 в `PROJECT.md` и внутренние перекрёстные ссылки самого каталога.
|
||||
|
||||
Проверь сам, прежде чем удалять:
|
||||
|
||||
```powershell
|
||||
git grep -n "Other_Code" -- ':!Other_Code' ':!PROJECT.md'
|
||||
git grep -nE "^\s*(import|from)\s+(scripts|validation)\b" -- 'md2gost' 'word2md' 'md2latex' 'md2fodt' 'tests'
|
||||
```
|
||||
|
||||
Ожидаемый результат обеих команд — пусто.
|
||||
|
||||
### Вариант А: снять с отслеживания, файлы оставить на диске
|
||||
|
||||
Подходит, если хочешь держать схемы под рукой локально.
|
||||
|
||||
```powershell
|
||||
git rm -r --cached Other_Code
|
||||
Add-Content -Path .gitignore -Value "`n# Справочные схемы OOXML (не часть продукта)`n/Other_Code/"
|
||||
```
|
||||
|
||||
### Вариант Б: удалить полностью
|
||||
|
||||
```powershell
|
||||
git rm -r Other_Code
|
||||
```
|
||||
|
||||
### Вариант В: вынести в отдельную ветку и потом удалить
|
||||
|
||||
Если материал ценен, но не должен висеть в основной ветке:
|
||||
|
||||
```powershell
|
||||
git subtree split --prefix=Other_Code -b reference/ooxml-schemas
|
||||
git rm -r Other_Code
|
||||
```
|
||||
|
||||
Ветка `reference/ooxml-schemas` останется локально с полной историей каталога.
|
||||
|
||||
После любого варианта подчисти упоминание в `PROJECT.md`, раздел 12.
|
||||
|
||||
---
|
||||
|
||||
## 2. Личные документы в корне
|
||||
|
||||
```
|
||||
Практическая_работа_6.docx 42 КБ
|
||||
ТарасовИА_КР_v3.docx 2326 КБ
|
||||
```
|
||||
|
||||
Та же категория, что и `md2gost.user.json`: персональные данные, причём ФИО прямо в имени файла. Ни одной ссылки из кода, тестов или сборочных скриптов.
|
||||
|
||||
Снять с отслеживания, файлы оставить на диске:
|
||||
|
||||
```powershell
|
||||
git rm --cached "Практическая_работа_6.docx"
|
||||
git rm --cached "ТарасовИА_КР_v3.docx"
|
||||
```
|
||||
|
||||
Если кириллица в аргументах ломается, обойди её через pathspec по расширению и отбери нужное вручную:
|
||||
|
||||
```powershell
|
||||
git ls-files "*.docx"
|
||||
```
|
||||
|
||||
Правило в `.gitignore`, чтобы не вернулись:
|
||||
|
||||
```powershell
|
||||
Add-Content -Path .gitignore -Value "`n# Личные документы (ФИО в имени файла)`n/*.docx`n!md2gost/Template.docx`n!md2gost/TitleTemplate.docx"
|
||||
```
|
||||
|
||||
**Осторожно с этим правилом.** `md2gost/Template.docx` и `md2gost/TitleTemplate.docx` — живые файлы, они force-include в колесо через `pyproject.toml` и попадают в exe через `.spec`. Правило выше их исключает, но проверь результат:
|
||||
|
||||
```powershell
|
||||
git check-ignore -v md2gost/Template.docx md2gost/TitleTemplate.docx
|
||||
```
|
||||
|
||||
Обе строки должны вернуть пусто (то есть файлы НЕ игнорируются). Если вернули правило — убери `/*.docx` и перечисли два личных файла поимённо.
|
||||
|
||||
---
|
||||
|
||||
## 3. Проверка результата
|
||||
|
||||
```powershell
|
||||
git status --short
|
||||
git ls-files | Measure-Object | Select-Object -ExpandProperty Count
|
||||
```
|
||||
|
||||
Размер отслеживаемого дерева до и после:
|
||||
|
||||
```powershell
|
||||
(git ls-files | ForEach-Object { (Get-Item -LiteralPath $_).Length } | Measure-Object -Sum).Sum/1MB
|
||||
```
|
||||
|
||||
Убедись, что ничего живого не выпало:
|
||||
|
||||
```powershell
|
||||
.venv\Scripts\python.exe -c "import md2gost, word2md, md2latex, md2fodt; print('ok')"
|
||||
$env:PYTHONIOENCODING="utf-8"; .venv\Scripts\python.exe -m md2gost --help
|
||||
.venv\Scripts\python.exe -m pytest -q
|
||||
```
|
||||
|
||||
Переменная `PYTHONIOENCODING` нужна из-за cp1251 в консоли — без неё `--help` падает на символе `→`, хотя код в порядке.
|
||||
|
||||
---
|
||||
|
||||
## 4. Про историю: снятие с отслеживания её не чистит
|
||||
|
||||
Это важно понимать. `git rm --cached` убирает файл из индекса и будущих коммитов, но все прошлые коммиты остаются нетронутыми. То есть:
|
||||
|
||||
- `md2gost.user.json` с твоими ФИО и группой **по-прежнему лежит в истории**
|
||||
- `ТарасовИА_КР_v3.docx` тоже, все 2.3 МБ, в каждом коммите, где он менялся
|
||||
- удалённые прототипы `mm2.py`/`mm3.py` и `Other_Code/` продолжают занимать место в `.git`
|
||||
|
||||
Если репозиторий приватный и таким останется — этого достаточно, дальше можно не читать.
|
||||
|
||||
Если планируешь публиковать, историю надо переписывать. Инструмент — `git filter-repo` (BFG устарел):
|
||||
|
||||
```powershell
|
||||
uvx git-filter-repo --path md2gost.user.json --invert-paths
|
||||
uvx git-filter-repo --path "ТарасовИА_КР_v3.docx" --invert-paths
|
||||
uvx git-filter-repo --path Other_Code --invert-paths
|
||||
```
|
||||
|
||||
Перед этим обязательно:
|
||||
|
||||
1. Сделай полную копию каталога `.git`, а лучше всего репозитория — операция необратима.
|
||||
2. Учти, что все хеши коммитов сменятся. Если репозиторий уже где-то запушен, всем придётся клонировать заново.
|
||||
3. Прогони `git reflog expire --expire=now --all; git gc --prune=now --aggressive`, иначе объекты останутся в паке.
|
||||
|
||||
Я специально не делал это автоматически: перезапись истории — необратимая операция, её стоит запускать осознанно и на копии.
|
||||
|
||||
---
|
||||
|
||||
## Приложение: что уже сделано агентами
|
||||
|
||||
Всё перечисленное лежит в staging, **не закоммичено**. Просмотри `git diff --cached` перед коммитом.
|
||||
|
||||
Удалено с диска (мёртвые прототипы, 6777 строк):
|
||||
|
||||
```
|
||||
mm2.py mm3.py mm4.py mm5.py main12.py main.py
|
||||
asd.py parser.py font.py _audit_tmp.py
|
||||
poetry.lock requirements.txt
|
||||
```
|
||||
|
||||
Снято с отслеживания, файлы остались на диске:
|
||||
|
||||
```
|
||||
ReadMe.docx md2gost/README.docx
|
||||
tmp_listing_word.md/.docx tmp_readme_word.docx
|
||||
tmp_readme_word2.docx README.md1
|
||||
examples/example_out.docx examples/toc_manual.docx
|
||||
examples/toc_native.docx tests/_idef0_preview*.png/.svg
|
||||
latex/mirea/Settings/FiraCode-Regular.otf
|
||||
ad/ (4 файла) md2gost.user.json
|
||||
```
|
||||
|
||||
Перенесено с сохранением истории:
|
||||
|
||||
```
|
||||
_method_extract.txt -> docs/reference/method-mirea-2022.txt
|
||||
tests/extended_mardown/ -> tests/extended_markdown/
|
||||
```
|
||||
|
||||
Добавлено: `md2gost.user.json.example` с пустыми полями.
|
||||
|
||||
### Побочный эффект правил игнора, о котором стоит знать
|
||||
|
||||
Новые правила `/tmp_*.png` и `/tmp_*.puml` захватили рабочие черновики `tmp_org_full.*`, `tmp_org_uml.*`, `tmp_arch.*` — они пропали из `git status`, хотя на диске целы. Если какой-то из них нужен под версионным контролем, добавь исключение:
|
||||
|
||||
```powershell
|
||||
Add-Content -Path .gitignore -Value "!/tmp_arch.puml"
|
||||
```
|
||||
|
||||
Каталог `ai/` не тронут и остаётся untracked.
|
||||
+2
-2
@@ -5,9 +5,9 @@
|
||||
Нужен Python 3.10+.
|
||||
|
||||
```bash
|
||||
pip install -e .
|
||||
uv sync # окружение по uv.lock (канонический lock-файл)
|
||||
# или
|
||||
poetry install
|
||||
pip install -e .
|
||||
```
|
||||
|
||||
Для продолжения таблиц/листингов через Word COM (режим `word` по умолчанию) на Windows:
|
||||
|
||||
@@ -0,0 +1,988 @@
|
||||
УДК 378
|
||||
ББК 65
|
||||
К 43
|
||||
Кириллина Ю.В. Требования к оформлению отчетов по практикам, курсовых работ и
|
||||
ВКР бакалавров и магистров [Электронный ресурс]: Методические указания / Кириллина
|
||||
Ю.В., Лагунова А.Д., Бергер Е.Г. — М.: МИРЭА – Российский технологический
|
||||
университет, 2022. — 1 электрон. опт. диск (CD-ROM)
|
||||
Методические указания знакомят студентов с требованиями по оформлению учебных
|
||||
работ, таких как курсовые работы, отчеты по практикам, выпускная квалификационная
|
||||
работа. Использование методических указаний позволит студентам грамотно оформлять
|
||||
учебные работы, которые они выполняют согласно учебному плану в процессе обучения.
|
||||
Данные методические указания основаны на ГОСТ 7.32 – 2017 Система стандартов по
|
||||
информации, б иблиотечному и издательскому делу. Отчет о научно -исследовательской
|
||||
работе. Структура и правила и оформления.
|
||||
Предназначено для студентов по направлени ям подготовки 09.03.03 Прикладная
|
||||
информатика, 09.0 4.03 Прикладная информатика , а также может быть использовано
|
||||
студентами других направлений подготовки для получения навыков грамотного оформления
|
||||
учебных работ.
|
||||
Методические указания издаются в авторской редакции.
|
||||
Авторский коллектив: Кириллина Юлия Владимировна, Лагунова Анна Дмитриевна, Бергер
|
||||
Екатерина Геннадьевна
|
||||
Рецензенты:
|
||||
Одинцова Мария Александровна , к.т.н., доцент, доцент кафедры «Предметно -
|
||||
ориентированные информационные системы» Института кибербезопасности и
|
||||
цифровых технологий РТУ МИРЭА
|
||||
Системные требования:
|
||||
Наличие операционной системы Windows, поддерживаемой производителем.
|
||||
Наличие свободного места в оперативной памяти не менее 128 Мб.
|
||||
Наличие свободного места в памяти постоянного хранения (на жестком диске) не менее 30 Мб.
|
||||
Наличие интерфейса ввода информации.
|
||||
Дополнительные программные средства: программа для чтения pdf-файлов (Adobe Reader).
|
||||
Подписано к использованию по решению Редакционно-издательского совета
|
||||
МИРЭА — Российский технологический университет.
|
||||
Обьем: 5.39 мб
|
||||
Тираж: 10
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
© Кириллина Ю.В., Лагунова А.Д.,
|
||||
Бергер Е.Г., 2022
|
||||
© МИРЭА – Российский
|
||||
технологический университет, 2022
|
||||
3
|
||||
СОДЕРЖАНИЕ
|
||||
|
||||
ПРЕДИСЛОВИЕ ...................................................................................................... 4
|
||||
1. СТРУКТУРА УЧЕБНОЙ РАБОТЫ .................................................................... 5
|
||||
2. ОФОРМЛЕНИЕ ТЕКСТА ДОКУМЕНТА ........................................................ 12
|
||||
3. ОФОРМЛЕНИЕ ИЛЛЮСТРАЦИЙ И ТАБЛИЦ В УЧЕБНОЙ РАБОТЕ ....... 17
|
||||
4. ОФОРМЛЕНИЕ ТЕКСТА (ЛИСТИНГА) ПРОГРАММЫ В УЧЕБНОЙ
|
||||
РАБОТЕ .................................................................................................................. 27
|
||||
5. ОФОРМЛЕНИЕ СПИСКА ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ В
|
||||
УЧЕБНОЙ РАБОТЕ ............................................................................................... 30
|
||||
6. ОФОРМЛЕНИЕ ПРИЛОЖЕНИЙ В УЧЕБНОЙ РАБОТЕ .............................. 34
|
||||
СПИСОК ИСТОЧНИКОВ И ЛИТЕРАТУРЫ ...................................................... 37
|
||||
ПРИЛОЖЕНИЕ А .................................................................................................. 38
|
||||
ПРИЛОЖЕНИЕ Б................................................................................................... 39
|
||||
ПРИЛОЖЕНИЕ В .................................................................................................. 41
|
||||
ПРИЛОЖЕНИЕ Г................................................................................................... 42
|
||||
ПРИЛОЖЕНИЕ Д .................................................................................................. 44
|
||||
ПРИЛОЖЕНИЕ Е .................................................................................................. 45
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
4
|
||||
ПРЕДИСЛОВИЕ
|
||||
|
||||
В процессе обучения студентам направлений подготовки 09.03.03, 09.04.03
|
||||
Прикладная информатика необходимо писать и оформлять курсовые работы, от-
|
||||
четы по различным видам и типам практик, а также выпускную квалификацион-
|
||||
ную работу (далее по тексту — учебные работы). Данные методические указания
|
||||
предназначены для студентов вышеуказанных направлений подготовки.
|
||||
Целью данных методических указаний является поддержка грамотного
|
||||
оформления текстовых документов студентами.
|
||||
Задачами методических указаний являются:
|
||||
• ознакомление студентов с общей структурой учебных работ, таких как
|
||||
курсовая работа, отчет по практике, выпускная квалификационная ра-
|
||||
бота (ВКР);
|
||||
• ознакомление студентов с правилами оформления учебных работ.
|
||||
Основой для создания методических указаний является ГОСТ 7.32 — 2017
|
||||
Система стандартов по информации, библиотечному и издательскому делу.
|
||||
Отчет о научно-исследовательской работе. Структура и правила и оформления.
|
||||
Методические указания составлены в соответствии с:
|
||||
• СМКО МИРЭА 7.5.1/03.П.67- 18 Положение о выпускной квалифика-
|
||||
ционной работе студентов, обучающихся по образовательным про-
|
||||
граммам подготовки бакалавров;
|
||||
• СМКО МИРЭА 7.5.1/03.П.68- 18 Положение о выпускной квалифика-
|
||||
ционной работе студентов, обучающихся по образовательным про-
|
||||
граммам подготовки магистров;
|
||||
• СМКО МИРЭА 7.5.1/04.И.05- 18 Инструкция по организации и прове-
|
||||
дению курсового проектирования.
|
||||
|
||||
|
||||
5
|
||||
1. СТРУКТУРА УЧЕБНОЙ РАБОТЫ
|
||||
|
||||
Учебная работа студента должна иметь определенную структуру.
|
||||
Структура конкретной учебной работы регламентируется методическими
|
||||
указаниями по написанию курсовой работы, методическими указаниями по
|
||||
написанию отчета по практике, методическими указаниями по написанию ВКР,
|
||||
которые разрабатываются преподавателями выпускающей кафедры и издаются
|
||||
редакционно-издательским отделом университета. В се изданные методически е
|
||||
указания выпускающей кафедры студент может найти на сайте университет а в
|
||||
разделе Студентам, далее Библиотека.
|
||||
В тоже время общая структура учебной работы включает в себя:
|
||||
• ый лист;
|
||||
• ие;
|
||||
• ие;
|
||||
• ие;
|
||||
• ием;
|
||||
• ие;
|
||||
• иков;
|
||||
• ия.
|
||||
Титульный лист учебной работы имеет утвержденную форму , выдается
|
||||
преподавателем, который руководит курсовой работой/практикой/ВКР.
|
||||
На титульном листе в обязательном порядке проставляется подпись
|
||||
руководителя учебной работы и студента. В случае, если в кач естве учебной
|
||||
работы выступает курсовая работа, то на не м необходима подпись второго
|
||||
преподавателя, участвующего в процедуре защиты курсовой работы. В слу чае,
|
||||
если в качестве учебной работы выступает ВКР, то на титульном листе
|
||||
необходима подпись заведующего выпускающей кафедрой. Примеры титульных
|
||||
листов различных учебных работ приведены в Приложении А .
|
||||
му и выдается
|
||||
преподавателем, который руководит курсовой работой/практикой/ВКР.
|
||||
аботы) — т, в
|
||||
яется абота). ие подписывается
|
||||
аботы. совых
|
||||
абот, а т а к ж е о т ч е т о в п о п р а к т и к е ие обязательно ждается
|
||||
ой. абот
|
||||
дополнительно согласуется с директор ом института. Факт принятия
|
||||
студентом задания к работе подтверждается подписью студента на задании.
|
||||
6
|
||||
Кроме подписей в задании должны быть указаны дата утверждения задания
|
||||
заведующим кафедрой, дата выдачи задания, дата принятия задания к
|
||||
исполнению. Примеры заданий различных учебных работ приведены в
|
||||
Приложении Б.
|
||||
афической
|
||||
частей в учебной работе устанавливаются методическими указаниями по
|
||||
написанию курсовой работы, методическими указаниями по написанию отчета
|
||||
по практике, методическими указаниями по написанию ВКР .
|
||||
авливается методическими
|
||||
указаниями по написанию курсовой работы, методическими указаниями по
|
||||
написанию отчета по практике, методическими указаниями по написанию ВКР ,
|
||||
а также положениями, приведенными в предисловии данного пособия.
|
||||
Текст основной части учебной работы еобходимости а азделы,
|
||||
азделы, пункты . кты имеют заголовки, четко и
|
||||
ктов.
|
||||
а листе, который расположен ого листа и
|
||||
ия, азделов,
|
||||
иц. иц
|
||||
а быть
|
||||
ая.
|
||||
ия заголовков:
|
||||
• аздела — я;
|
||||
• аздела — я;
|
||||
• ктов — ей.
|
||||
та,
|
||||
ые с абзацевого отступа.
|
||||
аков
|
||||
ия пишется заголовок.
|
||||
а б ы т ь в
|
||||
ﮦ ﮦ аздела,
|
||||
ых точками.
|
||||
Параметры оформления заголовков в учебной работе представлены в табл.
|
||||
2.1. Важно обратить внимание на то, что интервалы между заголовками
|
||||
выставляются в единицах измерения — мм, а не пт.
|
||||
На рис. 2.1 представлен пример внешнего вида заголовков выпускной
|
||||
квалификационной работы и курсовой работы с учетом установленных
|
||||
параметров страниц для учебной работы.
|
||||
7
|
||||
Таблица 2.1. Параметры оформления заголовков в учебной работе
|
||||
Параметр Заголовок
|
||||
первого урﮦовнﮦя
|
||||
Заголовок
|
||||
второго уровня
|
||||
Заголовок
|
||||
третьего уровня
|
||||
ифт
|
||||
Шрﮦифт Times New Roman
|
||||
Нﮦачерﮦтанﮦие полужирﮦнﮦый
|
||||
Подчерﮦкиванﮦие нﮦет
|
||||
Видоизменﮦенﮦие все прﮦописнﮦые нﮦет нﮦет
|
||||
Рﮦазмерﮦ 18 пт 16 пт 14 пт
|
||||
Цвет текста Авто (черﮦнﮦый)
|
||||
Абзац
|
||||
Вырﮦавнﮦиванﮦие По левому крﮦаю
|
||||
Перﮦвая стрﮦока нﮦет
|
||||
Отступ слева 1,25 см
|
||||
Отступ спрﮦава 0 мм
|
||||
Инﮦтерﮦвал перﮦед 0 мм 15 мм 15 мм
|
||||
Инﮦтерﮦвал после 10 мм 10 мм 10 мм
|
||||
Междустрﮦочнﮦый
|
||||
инﮦтерﮦвал
|
||||
Полуторﮦнﮦый
|
||||
Положенﮦие нﮦа
|
||||
ице
|
||||
Не отрывать от
|
||||
следующего
|
||||
С новой страницы
|
||||
Не отрывать от
|
||||
следующего
|
||||
Запрет висящих строк
|
||||
Нﮦе отрывать от
|
||||
следующего
|
||||
Запрет висящих строк
|
||||
|
||||
|
||||
Рисунок 2.1. Пример внешнего вида заголовков
|
||||
|
||||
8
|
||||
азделы «СОДЕРЖАНИЕ», «ВВЕДЕНИЕ», «ЗАКЛЮЧЕНИЕ», «СПИСОК
|
||||
ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ », «П РИЛОЖЕНИЕ»/«ПРИЛОЖЕНИЯ»
|
||||
уются.
|
||||
Разделы «СОДЕРЖАНИЕ» и «СПИСОК ИСПОЛЬЗОВАННЫХ
|
||||
ИСТОЧНИКОВ» выравниваются по центру страницы.
|
||||
ие
|
||||
азделяют точкой.
|
||||
е Word используется
|
||||
вкладка «Стили» (рис. 2.2). ﮦ ов
|
||||
о
|
||||
ить азу
|
||||
ия.
|
||||
|
||||
|
||||
Рисунок 2.2. Использование вкладки «Стили» в текстовом редакторе Word
|
||||
|
||||
ить
|
||||
а «Стили» ять
|
||||
овые стили (рис. 2.3).
|
||||
ые соответствующими стилями, позволяют
|
||||
ие.
|
||||
ктов должны
|
||||
ии, и
|
||||
соответственно наоборот. Для обеспечения этого содержание учебной работы
|
||||
должно формироваться с помощью встроенной функции Оглавление.
|
||||
ИЕ»,
|
||||
ием по
|
||||
у. Важно обратить внимание на значения интервала перед самим
|
||||
заголовком и после него для того, чтобы обеспечить нужные интервалы между
|
||||
заголовков и последующими пунктами самого содержания учебной работы.
|
||||
ю
|
||||
«Ссылки» → а ю и с
|
||||
ителя строки «. . . . . . . .» ( рис. 2.4).
|
||||
|
||||
9
|
||||
ить и
|
||||
овать.
|
||||
|
||||
|
||||
Рисунок 2.3. Редактирование заголовков в текстовом редакторе Word с
|
||||
использование диалогового окна «Стили»
|
||||
|
||||
|
||||
Рисунок 2.4. Формирование содержания через Автособираемое оглавление
|
||||
|
||||
иц,
|
||||
ом
|
||||
овить поле».
|
||||
|
||||
10
|
||||
При создании содержания слово ОГЛАВЛЕНИЕ заменяется в ручном
|
||||
режиме на СОДЕРЖАНИЕ с выставлением необходимых параметров,
|
||||
характерных для заголовков первого уровня.
|
||||
ой
|
||||
текст» без отступа первой строки аю.
|
||||
я,
|
||||
ии
|
||||
ыми буквами (рис. 2.5), аналогично тому, как они
|
||||
оформлены в учебной работе за исключением того, что полужирное начертание
|
||||
не применяется.
|
||||
|
||||
|
||||
Рисунок 2.5. Пример оформления содержания в ВКР
|
||||
|
||||
11
|
||||
ии текст попадает иц
|
||||
кте отсутствует отточие ицы, то часть
|
||||
очку.
|
||||
|
||||
12
|
||||
2. ОФОРМЛЕНИЕ ТЕКСТА ДОКУМЕНТА
|
||||
|
||||
ты учебной работы ой
|
||||
е листа.
|
||||
В случае представления учебной работы в бумажном виде она а быть
|
||||
мата А4.
|
||||
Учебная работа ых
|
||||
ﮦ илами.
|
||||
Учебная работа проверяется руководителем на соблюдение правил
|
||||
оформления, в случае несоответствия работы она не допускается до защиты и
|
||||
выставления оценки, и направляется на доработку.
|
||||
Текст документа должен быть кратким, четким и не допускать различных
|
||||
толкований. В докуме нтах должны применяться научно-технические те рмины,
|
||||
обозначения и определен ия общеп ринятые в научно-технической лите ратуре
|
||||
Стиль изложения текста в учебной работе строго нау чный, подстиль —
|
||||
собственно-научный. е допускается:
|
||||
• ицизмы,
|
||||
ализмы;
|
||||
• ия;
|
||||
• усской
|
||||
тами и
|
||||
ая
|
||||
овка;
|
||||
• и
|
||||
ﮦ .
|
||||
Текст учебной работы печатается, соблюдая следующие размеры полей:
|
||||
левое — 30 мм, правое — 10 мм, верхнее и нижнее — 20 мм. Абзацный отступ
|
||||
должен быть одинаковым по всему тексту и равен 1,25 см [1].
|
||||
а листах в рамках еще
|
||||
незаконченного раздела (см. Приложение В).
|
||||
иц.
|
||||
Не допускается размещать заголовки в кон це страницы, а основной текст
|
||||
переносить на следующую страницу.
|
||||
Текст ифтом
|
||||
ого цвета , размер шрифта — 14 пт, тип шрифта для основного текста
|
||||
учебной работы — Times NewтRoman.
|
||||
ой текст» (табл. 2.1).
|
||||
13
|
||||
ифт»,
|
||||
а знаков абзаца и других скрытых знаков
|
||||
форматирования ца абзаца и
|
||||
аки» (ая» →
|
||||
ифт» → ¶).
|
||||
|
||||
Таблица 2.1. Параметры оформления основного текста учебной работы
|
||||
Параметр Значение
|
||||
ифт
|
||||
Шрﮦифт Times New Roman
|
||||
Нﮦачерﮦтанﮦие Обычнﮦый
|
||||
Подчерﮦкиванﮦие нﮦет
|
||||
Видоизменﮦенﮦие нﮦет
|
||||
Рﮦазмерﮦ 14 пт
|
||||
Цвет текста Авто (черный)
|
||||
Абзац
|
||||
Выравнивание По ширине
|
||||
Первая строка 1,25 см.
|
||||
Отступ слева нет
|
||||
Отступ справа нﮦет
|
||||
Интервал перﮦед нﮦет
|
||||
Интервал после нет
|
||||
Междустрочный интервал Полуторный
|
||||
Положение на странице Запрет висящих строк
|
||||
|
||||
Пробел ставится после любого знака пунктуации, но не перед ним. При этом
|
||||
не ставятся п робелы после отк рывающих скобок и кавычек, так же как и пе ред
|
||||
закрывающими скобками и кавычками.
|
||||
Кавычки в русском тексте (включая список использова нных источ ников)
|
||||
имеют форму «…», а в английском — "…".
|
||||
ая.
|
||||
ицы учебной работы оставляемыми по
|
||||
ифт — ﮦ12 пт).
|
||||
ﮦ ицы
|
||||
е ставится:
|
||||
• титульный лист;
|
||||
• ие;
|
||||
• ие.
|
||||
е
|
||||
аки, такие как
|
||||
«+», «–», «=», «>», «<» и так далее. В тексте их следует писать словами: «плюс»,
|
||||
ьше».
|
||||
аки:
|
||||
14
|
||||
1. ак дефиса «-» обелами и используется:
|
||||
• жащих дефисы (во-первых,
|
||||
физико-математический, кто-либо);
|
||||
• валов (100-150 Мб).
|
||||
2. уса «–» ия.
|
||||
3. е «—обелами и используется в соответствии с
|
||||
ктуации (Классификаторﮦ —это
|
||||
систематизированный …).
|
||||
абские
|
||||
талов, полугодий,
|
||||
ами.
|
||||
ами, ы
|
||||
иями (… в начале XXI века).
|
||||
ых
|
||||
ий (… во 2 разделе, … характерно для середины 1980 годов).
|
||||
ﮦ ой и той же
|
||||
его числа
|
||||
(…составляет 200, 250, 300 руб.)ица
|
||||
ﮦ е (… длиной 20-25 см).
|
||||
ﮦ иц
|
||||
ﮦ ами, а числа без
|
||||
ﮦ ицы до девяти
|
||||
— словами (провести испытан ия семи т руб, каждая дли ной 5 м) . ые
|
||||
обей с ипользованием
|
||||
запятой при написании (20,5 см).
|
||||
ый и ый спис ки уются стилем
|
||||
ой текст».
|
||||
|
||||
Таблица 2.2. Параметры оформления списков
|
||||
Параметр Значение
|
||||
Марﮦкирﮦованﮦнﮦый список –, ―, ●, ■, ○
|
||||
Нﮦумерﮦованﮦнﮦый список 1.
|
||||
а)
|
||||
Положенﮦие марﮦкерﮦа (нﮦомерﮦа) Отступ 1,25 см
|
||||
Положенﮦие текста Табуляция после 2,25 см
|
||||
Отступ 2,25 см
|
||||
|
||||
ﮦ а во всем
|
||||
ькой
|
||||
15
|
||||
чивается — кт в
|
||||
чивается точкой).
|
||||
ﮦ ой буквы и
|
||||
чиваться точкой (рис. 2.1-2.3).
|
||||
|
||||
|
||||
Рисунок 2.1. Пример 1 оформления списка в учебной работе
|
||||
|
||||
|
||||
Рисунок 2.2. Пример 2 оформления списка в учебной работе
|
||||
|
||||
16
|
||||
|
||||
Рисунок 2.3. Пример 3 оформления списка в учебной работе
|
||||
|
||||
В случае необходимости применения для нумерованного списка строчных
|
||||
букв русского алфавита, список начинают с буквы «а» (за исключением букв ё,
|
||||
з, й, о, ч, ъ, ы, ь) [1].
|
||||
Внутри списка не могут располагаться иллюстрации и таблицы.
|
||||
При выполнении учебной работы необходимо соблюдать равномерную
|
||||
плотность и четкость изображения по все й работе. Все линии, буквы, цифры и
|
||||
знаки должны иметь одинаковую контрастность по всему тексту.
|
||||
|
||||
|
||||
17
|
||||
3. ОФОРМЛЕНИЕ ИЛЛЮСТРАЦИЙ И ТАБЛИЦ В
|
||||
УЧЕБНОЙ РАБОТЕ
|
||||
|
||||
Количество иллюстраций в учебной работе должно быть достаточ ным для
|
||||
пояснения излагаемого текста, в некоторых случаях обязательные иллюстрации
|
||||
регламентируются методическими указаниями по написанию курсовой работы,
|
||||
методическими указаниями по написанию отчета по практике, методическими
|
||||
указаниями по написанию ВКР.
|
||||
о после
|
||||
ице (по
|
||||
возможности ближе к соответствующим частям текста учебной работы) с
|
||||
у без абзацного отступа и первой строки.
|
||||
ами.
|
||||
аздела —
|
||||
ﮦ ﮦ азделяются точкой.
|
||||
ации
|
||||
ации (табл. 3.1).
|
||||
|
||||
Таблица 3.1. Параметры оформления подписи иллюстраций
|
||||
Параметр Значение
|
||||
ифт
|
||||
Шрифт Times New Roman
|
||||
Начертание Полужирﮦнﮦый
|
||||
Подчеркивание нет
|
||||
Видоизменﮦение нет
|
||||
Размер 12 пт
|
||||
Цвет текста Авто (черﮦнﮦый)
|
||||
Абзац
|
||||
Выравнивание По центру
|
||||
Первая строка 0 см
|
||||
Отступ слева 0 см
|
||||
Отступ спрﮦава нет
|
||||
Интервал перﮦед 0 мм
|
||||
Интервал после 6 мм
|
||||
Междустрочный интервал Одинарный
|
||||
Положение на странице Запрет висящих строк
|
||||
|
||||
ия
|
||||
е ставится . Предложение, в котором автор ссылается на
|
||||
рисунок, должно заканчиваться точкой, а не двоеточие м, т а к к а к э т о является
|
||||
нарушением правил пунктуации. (рис. 3.1).
|
||||
ием
|
||||
а.
|
||||
|
||||
18
|
||||
|
||||
Рисунок 3.1. Пример оформления рисунка с учетом установленных параметров
|
||||
страниц учебной работы
|
||||
|
||||
углых скобках или
|
||||
ﮦ :
|
||||
• план проекта иллюстрирует диаграмма Ганта (Рисунок 1.1);
|
||||
• дерево функций представлено на Рисунке 1.1.
|
||||
о
|
||||
ия по часовой
|
||||
а 90 яется с
|
||||
ую с помощью команды главного меню «Макет» . При
|
||||
размещении рисунка на отдельной странице с альбомной ориентацией
|
||||
необходимо установить в Параметрах страницы вертикальное выравнивание
|
||||
по центру.
|
||||
Страницы с альбомной ориентацией предназначены только для
|
||||
рисунков и таблиц, нельзя размещать на них основной текст (Приложение Г,
|
||||
рис. Г.1-Г.2).
|
||||
|
||||
19
|
||||
Сначала устанавливаются разрывы страницы, начиная со следующей
|
||||
страницы, а потом меняется ориентация с книжной на альбомную (рис. 3.2-3.3).
|
||||
|
||||
|
||||
Рисунок 3.2. Переход от книжной ориентации к альбомной
|
||||
|
||||
|
||||
Рисунок 3.3. Пример оформления рисунка на странице с альбомной ориентацией
|
||||
|
||||
20
|
||||
В случае, если рисунок завершает раздел, подраздел или пункт
|
||||
рекомендуется после него сформулиро вать заключительное предложение. Для
|
||||
раздела это будет заключительное предложение, подводящее итоги по
|
||||
выполненной работе в соответствующем разделе. Для подраздела или пункта это
|
||||
будет завершающее предложение, обеспечивающее переход к следующему
|
||||
подразделу или пункту (рис. 3.4-3.5).
|
||||
|
||||
|
||||
Рисунок 3.4. Пример завершения раздела и переход к следующему
|
||||
|
||||
Все иллюстрации должны иметь границы четко по представляемому
|
||||
рисунку, схеме и т.д., и не допускается пустая, неинформативная часть в
|
||||
иллюстрации, занимающая место, предназначеннное для основного текста.
|
||||
На рис. 3.6 представлена правильная и неправильная обрезка границ
|
||||
иллюстрации.
|
||||
Вне зависимости от того, каков формат представления учебной работы:
|
||||
распечатанная бумажная версия или электронный файл, все иллюстрации
|
||||
должны удовлетворять требованию их четкого воспроизведения, то есть должна
|
||||
быть обеспечена читабельность иллюстраций без необходимости прибегать к
|
||||
увеличению масштаба представленного материала.
|
||||
|
||||
|
||||
21
|
||||
|
||||
Рисунок 3.5. Пример завершения подраздела и переход к следующему подразделу в
|
||||
курсовой работе
|
||||
|
||||
|
||||
Рисунок 3.6. Пример правильной обрезки границ иллюстрации (левая часть) и
|
||||
неправильной обрезки границ илллюстрации (правая часть)
|
||||
|
||||
22
|
||||
Кроме того, рисунки, представляющие собой чертежи, графики, диаграммы,
|
||||
схемы, помещаемые в учебной работе , должны соответствовать требованиям
|
||||
стандартов Единой системы конструкторской документации (ЕСКД) .
|
||||
ия
|
||||
показателей.
|
||||
ие таблицы атким.
|
||||
ад таблицей.
|
||||
ие таблицы пишется без абзацного отступа и первой строки у
|
||||
це
|
||||
е ставится.
|
||||
ами аздела —
|
||||
ﮦ ﮦ азделяются точкой.
|
||||
ом
|
||||
еобходимости,
|
||||
ту.
|
||||
ﮦ ие ячеек
|
||||
е допускается.
|
||||
ед
|
||||
е Word).
|
||||
Параметры оформления таблицы в учебной работе представлены в табл. 3.2.
|
||||
|
||||
Таблица 3.2. Параметры оформления таблицы
|
||||
Параметр Надпись таблицы Текст таблицы
|
||||
ифт
|
||||
Шрифт Times New Roman
|
||||
ие Курсив Обычный, полужирный,
|
||||
курсив
|
||||
Подчеркиванﮦие нет
|
||||
Видоизменение нет
|
||||
Размер 12 пт
|
||||
Цвет текста Авто (черный)
|
||||
Абзац
|
||||
Выравнивание По левому краю По центру, по левому
|
||||
краю
|
||||
Первая стрﮦока 0 см
|
||||
Отступ слева 0 см
|
||||
Отступ справа нет
|
||||
Интервал перед 6 мм 0 мм
|
||||
Интервал после 0 мм
|
||||
Междустрочный интервал Одинﮦарный
|
||||
Положение нﮦа странице Запрет висящих строк
|
||||
|
||||
23
|
||||
а все таблицы учебной работы ы ссылки в тексте.
|
||||
углых скобках или включаются в
|
||||
ие. Если ссылка на таблицу завершает предложение, то в конце
|
||||
предложения ставится точка.
|
||||
ием
|
||||
углых скобках
|
||||
ﮦ :
|
||||
• далее представлен планﮦпроекта (Таблица 3.1);
|
||||
• планﮦпроекта представлен в Таблице 3.1 (рис. 3.7).
|
||||
|
||||
|
||||
Рисунок 3.7. Пример представления таблицы
|
||||
|
||||
ие
|
||||
ую
|
||||
угими частями пишется
|
||||
адпись таблицы»
|
||||
(рис. 3.8).
|
||||
Не допускаются таблицы в одну строчку, а также не допускается оставлять
|
||||
на странице только заголовок к таблице или заголовок с заголовками граф
|
||||
(Приложение Г, рис. Г.3).
|
||||
ации
|
||||
ед их
|
||||
ием.
|
||||
Все таблицы в учебной работе должны быть оформлены единообразно с
|
||||
точки зрения применяемого стиля для оформления заголовков и подзаголовков
|
||||
граф, а также строк таблицы.
|
||||
|
||||
|
||||
|
||||
24
|
||||
|
||||
Рисунок 3.8. Пример оформления переноса таблицы в учебной работе
|
||||
|
||||
ия,
|
||||
ия
|
||||
е
|
||||
о под
|
||||
мулой.
|
||||
ием
|
||||
мул Microsoft Equation или MathType.
|
||||
а вкладке «Вставка» →«Уравнение» (рис.
|
||||
3.9).
|
||||
|
||||
|
||||
Рисунок 3.9. Возможности контекстного меню «Уравнение»
|
||||
|
||||
|
||||
25
|
||||
Не допускается формулы оформлять как основной текст, основным
|
||||
шрифтом.
|
||||
мулы, ивается по
|
||||
у. а
|
||||
ока.
|
||||
а ака
|
||||
ус ( –ия (×) или
|
||||
ия яется.
|
||||
ию.
|
||||
тов следует
|
||||
ости, в какой
|
||||
муле.
|
||||
ают без абзацного отступа со слова «где»
|
||||
его.
|
||||
Значение каждого символа и числового коэффицие нта следует давать с
|
||||
новой строки, располагая символы один под другим (рис. 3.10).
|
||||
|
||||
|
||||
Рисунок 3.10. Пример оформления последовательности формул в учебной работе
|
||||
|
||||
|
||||
26
|
||||
Если формула является концом предложения, то ставится точка, если после
|
||||
формулы предложение продолжается — запятая.
|
||||
Формулы нумеруются последовательно в пределах раздела арабскими
|
||||
цифрами в круглых скобках, выровненных по правому краю. Нумеруются только
|
||||
те формулы, на которые имеются ссылки в тексте.
|
||||
Ссылки в тексте на номер формулы даются в круглых скобках.
|
||||
Вне зависимости от способа выполнения учебной работы качество
|
||||
напечатанного текста и оформления иллюстраций, таблиц, распечаток программ
|
||||
должно удовлетворять требованию их четкого воспроизведения.
|
||||
27
|
||||
4. ОФОРМЛЕНИЕ ТЕКСТА (ЛИСТИНГА) ПРОГРАММЫ В
|
||||
УЧЕБНОЙ РАБОТЕ
|
||||
|
||||
В учебной работе могут содержаться отдельные фрагменты программ (ли-
|
||||
стинг), разработанных студентом.
|
||||
Название листинга пишется в одну строку с номером, через тире, с большой
|
||||
буквы, перед листингом. Точка в конце не ставится. Пример, «Листинг 1.7 —
|
||||
Процедура открытия программы».
|
||||
При ссылке на отдельные строки программы они нумеруются в порядке воз-
|
||||
растания с шагом 10. После ссылки на листинг в фигурных скобках привод ятся
|
||||
номера строк. Пример «Листинг 3.2 {30, 50, 140}», «Листинг 3.2 {20- 80}».
|
||||
Листинг оформляется в рамку (рис. 4.1-4.2).
|
||||
|
||||
|
||||
Рисунок 4.1. Пример 1 оформления листинга
|
||||
|
||||
|
||||
Рисунок 4.2. Пример 2 оформления листинга
|
||||
|
||||
28
|
||||
Параметры оформления листинга представлены в табл. 4.1.
|
||||
|
||||
Таблица 4.1. Параметры оформления листинга
|
||||
Листинг
|
||||
Надпись листинга
|
||||
Шрифт Шрифт
|
||||
Шрифт Times New Roman
|
||||
Начертание Курсив
|
||||
Размер 12 пт
|
||||
Цвет текста Авто (черный)
|
||||
Подчеркивание нет
|
||||
Видоизменение нет
|
||||
Интервал
|
||||
Масштаб 100%
|
||||
Интервал Обычный
|
||||
Смещение Нет
|
||||
Анимация Вид Нет
|
||||
Абзац Отступы и интервалы
|
||||
Выравнивание По левому краю
|
||||
Отступ слева 0 см
|
||||
Отступ справа 0 см
|
||||
Первая строка нет
|
||||
Интервал перед 6 мм
|
||||
Интервал после 0 мм
|
||||
Междустрочный Одинарный
|
||||
Положение на странице Разбивка на страницы Не отрывать от следующего
|
||||
С новой страницы
|
||||
Содержание листинга
|
||||
Шрифт Шрифт
|
||||
Шрифт Courier New
|
||||
Начертание Обычный
|
||||
Размер 10 пт
|
||||
Цвет текста Авто (черный)
|
||||
Подчеркивание Нет
|
||||
Видоизменение нет
|
||||
Интервал
|
||||
Масштаб 100%
|
||||
Интервал Обычный
|
||||
Смещение Нет
|
||||
Анимация Вид Нет
|
||||
Абзац
|
||||
Отступы и интервалы
|
||||
Выравнивание По левому краю
|
||||
Отступ слева 0 см
|
||||
Отступ справа 0 см
|
||||
Первая строка 0 см
|
||||
Интервал перед 0 мм
|
||||
Интервал после 0 мм
|
||||
Междустрочный Одинарный
|
||||
|
||||
29
|
||||
Основной текст (строка) после листинга печатается с интервалом перед 6
|
||||
мм.
|
||||
Весь текст программы целесообразно выносить в приложени е.
|
||||
|
||||
30
|
||||
5. ОФОРМЛЕНИЕ СПИСКА ИСПОЛЬЗОВАННЫХ
|
||||
ИСТОЧНИКОВ В УЧЕБНОЙ РАБОТЕ
|
||||
|
||||
Все заимствованные части учебной работы (автором которых не является
|
||||
студент) должны быть сопровождены ссылкой на источник , тип ссылки —
|
||||
затекстовая (см. ГОСТ Р 7.0.5- 2008). Список должен содержать сведения об
|
||||
источниках, использованных при составлении учебной работы [1].
|
||||
Список использованных источников должен включать библиографические
|
||||
записи на документы, использованные при составлении учебной работы, ссылки
|
||||
на которые оформляют арабскими цифрами в квадратных скобках.
|
||||
Сведения об источниках следует располагать в порядке появления ссылок
|
||||
на источники в тексте учебной работы и нумеровать арабскими цифрами с
|
||||
точкой и печатать с абзацного отступа в 1,25 см.
|
||||
При оформлении раздела СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
|
||||
на первой строке листа печатается соответствующее наименование р аздела,
|
||||
отформатированное по параметрам для заголовка первого уровня.
|
||||
Для учебных работ вида курсовой работы или отчета по практике список
|
||||
использованных источников делить на разделы не требуется. Требованиями к
|
||||
источникам в данном случае являются следующие:
|
||||
• количество источников от 5 до 7;
|
||||
• год издания источника — за последние 5 лет к моменту написания и
|
||||
представления учебной работы (Приложение Д, рис. Д.1).
|
||||
В случае выпускной квалификационной рабо ты список использованных
|
||||
источников делится на разделы, в каждом и которых должно быть представлено
|
||||
не менее 10 источников, годом издания не больше, чем 5 лет к моменту защиты
|
||||
выпускной квалификационной работы.
|
||||
Параметры оформления заголовков разделов в списке использованных
|
||||
источников представлены в табл. 5.1.
|
||||
Внутри раздела источники распределяются в порядке упоминания их в
|
||||
выпускной квалификационной работе и нум еруются (рис. 5.1). В данном случае
|
||||
номер источника будет состоять из номера разд ела, к которому он относится, и
|
||||
номера по порядку.
|
||||
ики следует давать в виде
|
||||
арабских цифр, заключенных в квадратные скобки, указывающих порядковый
|
||||
номер источника по списку, например, [1], [2, 3], [1.5], [2.18].
|
||||
В случае цитирования указываются страницы книги, статьи или другого
|
||||
источника, из которых взята цитата, например, [2.18, c. 21-25].
|
||||
|
||||
31
|
||||
Таблица 5.1. Параметры оформления заголовков разделов
|
||||
в списке использованных источников
|
||||
Параметр Значение
|
||||
Шрифт
|
||||
Шрифт Times New Roman
|
||||
Начертание Обычный
|
||||
Подчеркивание нет
|
||||
Видоизменение Все прописные
|
||||
Размер 14 пт
|
||||
Цвет текста Авто (черный)
|
||||
Абзац
|
||||
Выравнивание По центру
|
||||
Первая строка нет
|
||||
Отступ слева 1,25 см.
|
||||
Отступ справа нет
|
||||
Интервал перед 6 мм
|
||||
Интервал после 6 мм
|
||||
Междустрочный интервал Полуторный
|
||||
Положение на странице Не отрывать от следующего
|
||||
|
||||
|
||||
Рисунок 5.1. Пример оформления списка использованных источников с делением на
|
||||
разделы
|
||||
|
||||
32
|
||||
На рис. 5. 2 приведен пример основного текста учебной работы со ссылкой
|
||||
на источник.
|
||||
|
||||
|
||||
Рисунок 5.2. Пример оформления ссылок в тексте учебной работы
|
||||
|
||||
На рис. 5. 3 приведен пример основного текста учебной работы со ссылкой
|
||||
на источник при цитировании. При цитировании цитируемая фраза ставится в
|
||||
кавычки.
|
||||
|
||||
|
||||
Рисунок 5.3. Пример оформления ссылок в тексте при цитировании.
|
||||
|
||||
33
|
||||
В основном тексте ВВЕДЕНИЯ и ЗАКЛЮЧЕНИЯ ссылки на
|
||||
источники не указываются.
|
||||
Более подробно порядок оформления различных источников представлен в
|
||||
ГОСТ 7.32 — 2017 Система стандартов по информации, библиотечному и
|
||||
издательскому делу. Отчет о научно -исследовательской работе. Структура и
|
||||
правила и оформления. Приложение Е на странице 26 указанного документа.
|
||||
34
|
||||
6. ОФОРМЛЕНИЕ ПРИЛОЖЕНИЙ В УЧЕБНОЙ РАБОТЕ
|
||||
|
||||
яющий текст учебной работы, допускается помещать в
|
||||
ие учебной работы а
|
||||
последующих ее листах.
|
||||
иложения могут выноситься:
|
||||
• ом, так и
|
||||
ия;
|
||||
• уемого объекта
|
||||
ия;
|
||||
• асчеты;
|
||||
• сложные алгоритмы;
|
||||
• аботы;
|
||||
• тов;
|
||||
• тов;
|
||||
• экранные формы инормацинной системы;
|
||||
• листинги программ;
|
||||
• оизводство
|
||||
ии).
|
||||
мата А4. Допускается
|
||||
мата A3 по ГОСТ 2.301.
|
||||
В учебной работе приложение может быть одно или несколько.
|
||||
В случае, если в учебной работе будет только одно приложение , т о н а
|
||||
следующем листе после списка использованных источников заголовком первого
|
||||
уровня оформляется заголовок ПРИЛОЖЕНИЕ. И на этом же листе размещается
|
||||
необходимый дополняющий материал (рис. Д.1, Приложение Д).
|
||||
В случае необходимости оформить несколько приложений в учебной работе
|
||||
их а я с А , з а
|
||||
ﮦ «Приложение А».
|
||||
ь
|
||||
ия в
|
||||
ой текст» (рис.
|
||||
6.1).
|
||||
ием
|
||||
ого стилем
|
||||
я».
|
||||
35
|
||||
|
||||
Рисунок 6.1. Пример оформления раздела ПРИЛОЖЕНИЯ
|
||||
|
||||
а
|
||||
ﮦ «Приложение А.1», «Приложение А.2», если они связаны по
|
||||
смыслу.
|
||||
ый по
|
||||
ой текст» (рис. 6.2).
|
||||
|
||||
|
||||
Рисунок 6.2. Пример оформления отдельного приложения в составе раздела
|
||||
ПРИЛОЖЕНИЯ
|
||||
|
||||
36
|
||||
Таблицы и иллюст рации, соде ржащиеся в п риложении, нумеруются
|
||||
аналогично таблицам и рисунк а м в о сновном тексте учебной работы.
|
||||
Иллюстрации каждого пр иложения обоз начают отдель ной нумерацией
|
||||
арабскими циф рами с добавлен ием пе ред циф рой обоз начения приложе ния,
|
||||
например, «… представлено на Рисунке Б.1», «… отражен в таблице В.1».
|
||||
В тексте докумен та на все п риложения должн ы быть да ны ссылки.
|
||||
Приложения располагают в порядке ссылок на них в тексте учебной работы.
|
||||
При ссылке следует писать слово «П риложение» с большой буквы с
|
||||
указанием порядкового номера, например «…представлено в Приложении Б».
|
||||
Перечень материала, оформляемого в виде приложения, определяется
|
||||
обучающимся совместно с руководителем на основе методических
|
||||
рекомендаций по курсовой работе, методических рекомендаций по подготовке
|
||||
отчета по практике, методических рекомендаций по написанию ВКР.
|
||||
Применительно к ВКР бакалавра или магистра обязательным приложением
|
||||
к ней является приложение под названием Графический материал, который
|
||||
представляет собой слайды презентации с основными результатами,
|
||||
полученными в ходе написания ВКР.
|
||||
|
||||
37
|
||||
СПИСОК ИСТОЧНИКОВ И ЛИТЕРАТУРЫ
|
||||
|
||||
1. ГОСТ 7.32 — 2017 Система стандартов по информации,
|
||||
библиотечному и издательскому делу. Отчет о научно- исследовательской
|
||||
работе. Структура и правила и оформления — URL:
|
||||
https://www.rea.ru/ru/org/managements/orgnirupr/Documents/gost_7.32 -2017.pdf
|
||||
(дата обращения 20.11.2022)
|
||||
|
||||
38
|
||||
ПРИЛОЖЕНИЕ А
|
||||
|
||||
|
||||
Рисунок А.1. Общий вид титульного листа ВКР
|
||||
|
||||
|
||||
Рисунок А.2. Общий вид титульного листа курсовой работы
|
||||
|
||||
39
|
||||
ПРИЛОЖЕНИЕ Б
|
||||
|
||||
|
||||
Рисунок Б.1. Общий вид одностороннего задания на курсовую работу
|
||||
|
||||
|
||||
Рисунок Б.2. Общий вид двустороннего задания на практику
|
||||
|
||||
40
|
||||
|
||||
Рисунок Б.3. Общий вид двустороннего задания на ВКР (лицевая сторона)
|
||||
|
||||
|
||||
Рисунок Б.4. Общий вид задания на ВКР (оборотная сторона и окончание задания )
|
||||
|
||||
41
|
||||
ПРИЛОЖЕНИЕ В
|
||||
|
||||
|
||||
Рисунок В.1. Пример недопустимой ситуация в учебной работе, полупустая страница при условии,
|
||||
что подраздел еще не закончился
|
||||
|
||||
42
|
||||
ПРИЛОЖЕНИЕ Г
|
||||
|
||||
|
||||
Рисунок Г.1. Пример 1 неправильного использования страницы с альбомной
|
||||
ориентацией
|
||||
|
||||
|
||||
Рисунок Г.1. Пример 2 неправильного использования страницы с альбомной
|
||||
ориентацией
|
||||
|
||||
43
|
||||
|
||||
Рисунок Г.3. Неверное представление таблицы в учебной работе
|
||||
|
||||
|
||||
44
|
||||
ПРИЛОЖЕНИЕ Д
|
||||
|
||||
|
||||
Рисунок Д.1. Пример оформления списка использованных источников без деления на
|
||||
разделы
|
||||
|
||||
|
||||
|
||||
|
||||
45
|
||||
ПРИЛОЖЕНИЕ Е
|
||||
|
||||
|
||||
Рисунок Е.1. Оформление ПРИЛОЖЕНИЯ в учебной работе
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
46
|
||||
СВЕДЕНИЯ ОБ АВТОРАХ
|
||||
|
||||
Бергер Екатерина Геннадьевна, к.э.н., доцент кафедры практической и при-
|
||||
кладной информатики Института информационных технологий
|
||||
Кириллина Юлия Владимировна, к.э.н., доцент, доцент кафедры практиче-
|
||||
ской и прикладной информатики Института информационных технологий
|
||||
Лагунова Анна Дмитриевна, к.э.н., доцент кафедры практической и при-
|
||||
кладной информатики Института информационных технологий
|
||||
|
||||
Reference in New Issue
Block a user