От Markdown към PDF и обратно: какво запазва преобразуването на формати

Markdown и PDF са оптимизирани за различни договори. Markdown е структура, удобна за контрол на версиите. PDF е фиксирано описание на страница. Преобразуването в едната посока и обратно е полезно; то не е цикъл за архивиране без загуби.

Markdown към PDF: структурата става страници

Markdown to PDF (POST /api/v1/convert/markdown/pdf) приема .md файл или ZIP, който съдържа Markdown. Качвания, които не са Markdown или ZIP, се отхвърлят. За обикновен .md вход се изисква UTF-8. Процесът изобразява Markdown към HTML с включени таблици, зачертаване и списъци със задачи, обвива този HTML в CSS, ориентиран към печат (включително набори от шрифтове за няколко писмености и RTL, когато бъде открит арабски), после отпечатва към PDF с WeasyPrint.

Какво обикновено оцелява при прехода напред:

• Заглавия, абзаци, списъци и прости Markdown таблици
• Текст на няколко писмености, който HTML пътят може да подреди (CJK, латиница и други писмености, покрити от CSS за печат)
• PDF за печат и споделяне за работни процеси тип docs-as-code

Какво не оцелява:

• Шрифтовете на темата на вашия редактор като гарантирано съвпадение във всяка програма за преглед
• Точните пренасяния на редове от екрана в .md файла
• Интерактивните функции на Markdown, които нямат еквивалент в PDF (живи отметки, свиващи се секции, wiki връзки)

Входът ZIP е за групиране на Markdown с ресурси, които HTML пътят може да намери до документа. Третирайте го като удобство за опаковане, а не като гаранция, че всяко относително изображение или CSS препратка ще изглежда еднакво във всяка програма за преглед.

PDF към Markdown: текстовият слой влиза, Markdown излиза

PDF to Markdown (POST /api/v1/convert/pdf/markdown) извлича текстовото съдържание в Markdown чрез pdf-inspector. Отговорът е text/markdown, изтеглян като .md файл. Цифрово създадените PDF с чист текстов слой се преобразуват най-добре. Сканираните страници без текстов слой дават празен или безполезен Markdown, докато не ги прекарате първо през OCR; а OCR на този сайт също връща Markdown, а не PDF с търсим слой.

Очаквайте:

• Заглавия и абзаци, когато евристиките за размер на шрифта сработят правилно (може пак да преномерирате нивата на # на ръка)
• Таблици като Markdown таблици, когато разпознаването работи; оформленията с много колони може да се изправят в различен ред на четене
• Повтарящи се колонтитули на всяка страница (подрязвайте след това)
• Изображения и уравнения като картинки, които не стават автоматично локални ресурси или LaTeX

Ако ви трябва чист текст без евристики за заглавия, PDF to Text е по-плоското извличане. Експорти с форма на таблица, които връщат HTTP 204, означават, че не са открити колонни блокове; вижте Празен експорт на таблица (204).

Какво всъщност доказва един цикъл напред и назад

Преминаването два пъти ще се разминава. Markdown→PDF се пренарежда през WeasyPrint; PDF→Markdown възстановява структурата чрез евристики за извличане. Нито една стъпка не пази междинно представяне без загуби на модела на оформление на другия формат.

Изберете канонична посока

Ако ви трябва печатното оформление като система от записи, пазете PDF и третирайте Markdown като експорт или поток за агенти. Ако ви трябват разлики, преглед на код и поглъщане от агенти, предпочитайте Markdown и третирайте PDF като стъпката за публикуване. Не пазете и двете като равностойни „източници на истина“ и не очаквайте да останат идентични след редакции.

Практичен цикъл тип docs-as-code: редактирайте Markdown в Git → Markdown to PDF за артефакта за споделяне → избягвайте PDF→Markdown→PDF като ежедневен навик. Използвайте PDF→Markdown, когато сте наследили цифрово създаден PDF и ви трябва текст за агент, после третирайте този Markdown като нова чернова, а не като гаранция за първоначалната разбивка на страници.

Шифрованите файлове се нуждаят от разрешено Unlock преди всяко от двете преобразувания. Повредените файлове, които няма да се анализират, трябва да минат първо през Get Info / Repair. За същите крайни точки по HTTP вижте Developers.