Комментарии 62
Надо только понимать, что PDF это скорее формат изображения, чем документа. И если уж захочется перевести его обратно в редактируемый вид, то OCR будет чуть ли не проще, чем попытка анализировать содержимое.
Если повезёт, то внутри будет нормальный текст целиком или блоками. В моём случае внутри оказались слова и слоги, не по порядку, с абсолютными координатами в пикселях от угла страницы. Могло быть и в относительных от другого слова.
Есть такая вероятность как данность формата. :)
P.S. Живой топик на ru-board форуме Редактирование PDF файлов
PDF - это контейнер, а внутри контейнера адок. Может быть все что угодно. И текст, и картинка, и картинка, которая выглядит как текст. А еще есть XFA формы. И PDF портфолио.А еще есть аннотации - это когда поверх текста что-то нарисовано, или вставлен комментарий.
Это из опыта создания софта для извлечения текста (capturing). У PDF документа может быть текст в виде картинки, а у картинки подложка, на которой текст в виде текста. И он отличается от картинки. А сверху еще комментарий сделан.
Это просто был не True PDF
и даже встраивает шрифты, используемые в самом документе, поэтому любой компьютер в любом месте может просматривать и распечатывать PDF-файл, и он будет выглядеть именно так, как задумано.
Ага, а еще тот кто создает pdf может забыть встроить шрифты, и тогда документ будет выглядеть не совсем так как задумано.
Всё-таки считаю, что pdf часто используется избыточно или даже во вред. В большинстве личных или рабочих документов не нужно и даже вредно соблюдать точную вёрстку того, кто документ создавал. Примеров тысячи - рабочие документы, письма, различные руководства, справочники, резюме и прочее. Везде идеально подходит верстка на лету - под устройство, на котором документ смотрят. Не знаю, насколько хорош Liquid Mode, но пока не видел ни одного такого документа (и мало кто из пользователей вообще о нем знает). Всегда матерюсь, когда вижу, как на многих сайтах простую информацию дают в виде pdf-файлов вместо того, чтобы просто отобразить то же самое прямо на странице сайта. На телефонах, которыми пользуются в 95% случаев, это особенно больно.
На телефонах, которыми пользуются в 95% случаев, это особенно больно.
Что у вас за работа такая? Наоборот, радуюсь, когда что-то доступно в пдф и его можно скачать. Телефоном пользуюсь для коммуникаций.
За много лет на многих работах ни разу не было нужды создать или принять что-то именно в pdf-формате. Почти всегда хватает функционала Аутлука - форматирование и таблицы. Изредка, если что-то забористое, то Word или Excel. И никогда pdf.
А с телефона я делаю все, в том числе смотрю руководства для домашней техники и прочую инфу. И когда это в формате pdf, то бесит страшно.
У меня нет аутлука, ворда и винды и не было последние лет 15 ни на одном месте работы, ни дома. Поэтому ваши таблицы я не прочитаю, шлите pdf. А уж сканированные документы в виде кучи картинок в ворде давно уже анекдотом стали..
А с телефона я делаю все, в том числе смотрю руководства для домашней техники и прочую инфу.
Могу только сказать, что мне вас искренне жаль, но я так страдать не согласен и предпочитаю экраны нормального размера. Телефон дома я в принципе в руки не беру, кроме случаев когда кто-то звонит по сотовой сети. Даже современные лопаты абсолютно нефункциональны для того, чтобы удобно что-то читать и нужен экран не менее 10-12 дюймов, имхо, на которых pdf тоже нормально читаются.
Ни разу в жизни не получал и не отправлял сканированные документы внутри Ворда. Мне вас искренне жаль (с)
А дома пользуюсь компом почти только для просмотра видео. Всё остальное на телефоне и реже на планшете.
А чем сканированные документы в виде кучи картинок в pdf радикально лучше того же самого в ворде? Кроме ощущения, что отправитель рукожопый чайник?
Видимо вы просто никогда не сталкивались с ситуациями, когда крайне важно соблюсти форматирование документа.
У авторов конкретного документа могут быть специфические вкусы. Например, выберут вырвиглазный шрифт (учёные это иногда любят), или сверстают буклет, чтобы в коробке с товаром красивенько смотрелось.
Или понапихают this page is intentionally left blank. Сиди, скролли.
Даже на компе читать неприятно, а на телефоне - тем паче.
Тут не всегда вопрос в точной верстке элементов. У нас был один случай, который до сих пор вспоминаем с содроганием. Клиент прислал вордовский документ, договор, с приложениями, красивый, шрифты, все дела. Мы его прочитали, ништяк всё, распечатали, подписали и отправили бумажную версию ему. А потом выяснился нюансик, ворд у нас был то ли немного устаревший, то ли шрифтов не было, то ли еще чего, но на компьютере съехало форматирование и часть пунктов просто не была видна (и да, это не злой замысел клиента, просто он не заморачивался с нюансами форматирования во время правок, а у нас была староватая версия). В результате на печать и подпись ушло немного не то, что мы читали на компьютере. И вот это "немного" стоило нам 2 месяцев работы и испорченных отношений, несмотря на объяснение ситуации и понимание ее клиентом.
Поэтому, нет, спасибо, не надо нам "верстки на лету" под "устройство на котором документ смотрят". Нам надо что бы мы четко знали, что читаем то, что писал кто-то другой:) Славься pdf !
Такое с Вордом случается крайне редко. Не знаю даже, как надо извратиться, чтобы такое получилось.
Подписать важный денежный документ, не читая финальной версии (вдруг распечатавший удалил что-то случайно или диверсант) - это тоже... надо, блин.
Даже в статье написано про проблемы с pdf, если читаешь не той версией, не от того вендора и т.д
Как часто вы получаете и подписываете такие документы? Я - 1 раз в год раньше и никогда сейчас.
Не убедили)
PDF в данном случае маркер "финальной версии", редактирование которой не подразумевается. HTML'ка на сайте - хорошо-и-удобно, но "портабельность" не обеспечивается, какой-нибудь удобно редактируемый переносимый формат создает риски, что содержимое будет тем или иным образом похерено - рукавом при просмотре с мАбилки задел, сразу не заметил - и разбирайся через две недели что это блин за нафиг такой был...
В общем, свои минусы конечно есть - но не то, чтобы принципиальные. Какую-нибудь технину с тразвесистыми иллюстрациями\таблицами\сносками\примерами кода "адаптивная верстка" скорее попортит до полной нечитабельности.
Для работы с PDF контентом мне нужно переводить PDF в HTML.
Это ад.
Спас столько OCR с соблюдением разметки (FineReader в моем случае).
Для архивирования документов нужно переводить в PDF/A.
Это ад, и спасения нет.
Все что прижилось в нашем мире и обрело популярность - ад. Возьмите те же самые популярные ЯП - С++ и JS.
Это примерно как при работе с исполняемыми файлами постоянно декомпилировать их в C (ну или извлекать текст через strings). PDF - исключительно выходной формат для печати на бумаге или отображения на устройстве с достаточно большим размером и разрешающей способностью и для этого он вполне подходит. Для остальных действий по хорошему надо использовать то, из чего этот PDF получен - если оно недоступно, то это уже хакерство, а не документооборот.
Гм. А как вы с ним "работаете"? Для меня - это "финальная неизменяемая версия", а все правки\совместная работа производится над исходником в каком-нибудь markdown'е или там word'е. Необходимость прям править pdf конечно возникала, но очень редко - и как правило это был верный признак "вы делаете что-то не так".
Возможно я делаю что-то не так, но таковы обстоятельства.
Пример (моя боль) - законодатели публикуют законы в PDF и требуют их соблюдения.
Для соблюдения нужно получить текст закона, понять и преобразовать в инструкции к выполнению.
У меня таких PDF документов более 12 тыс.
https://www.benefits.va.gov/WARMS/docs/admin26/pamphlet/pam26_7/ch04.pdf
Я, конечно, могу попытаться объяснить законодателям, что они ошибаются, но разумнее просто преобразовать PDF в HTML. И это ад.
Так как вам "преобразование в HTML" помогает читать, понимать, и преобразовывать (Читай - "перерабатывать") документ в "инструкцию"?
Через последующее копирование HTML секций, передаче на интерпретацию compliance attorney (законнику) и созданию инструкций к выполнению.
С PDF это ад. См. выше.
Все равно не понимаю, извините. PDF != внутреннему формату документооборота организации -> PDF это ад. Ну публиковали бы они в ms word - так вы бы точно так же страдали с преобразованием сложной верстки в html, в чем разница-то?
Или документ == отсканеная картинка? Так тут проблема не "формата" а исключительно того, кто подобный "документ" готовил - если бы эти картинки вставляли в word - ровным счетом ничего бы не поменялось.
Так PDF по определению для такого преобразования не предназначен. В общем случае, там даже не известна кодировка встроенных шрифтов. PDF надо воспринимать скорее, как графический формат, чем как текстовый. Могли и в многостраничном TIFF публиковать.
В описанной Вами ситуации единственный путь - через OCR.
Сообщается, что самым большим PDF-файлом из когда-либо созданных был документ на 10 000 страниц, созданный Европейским патентным ведомством
В целях печати квитанций на оплату коммунальных услуг лет десять назад тестировал формирование PDF на 100 тыс. листов. Но эта байда напрямую не открывалась, а сплиттилась по различным условиям для печати на потоковых принтерах. Всего клиенту ежемесячно нужно было печатать до миллиона квитанций.
Формат, намеренно ориентированный на визуальное представление, а не на семантику. И ужасно то, что огромное количество литературы - в том числе научной и технической - создается и хранится в этом формате. Почему ужасно? Потому что формат экстремально человекоориентированный, он специально сделан для того, чтобы документы одинаково отображались и печатались на всех устройствах, именно с теми шрифтами, отступами и прочей мишурой, которую заложил создатель документа, которая важна для человеческого восприятия, но совершенно бесполезна для машины. А вот нужно ли это для систем структурирования информации, для семантических сетей, для искусственного интеллекта? Нет, только мешает. И альтернатив особо нет (разве что html с mathml и svg).
Кто знает, может из-за этого формата момент наступления Технологической Сингулярности задержится на пару десятков лет?
html с mathml и svg
Они не позволяют отображать документ одинаково на любых системах, так как не содержат в себе используемые шрифты. А значит результат рендеринга на разных устройствах будет отличаться. В отличии от PDF.
По идее, достаточно формировать PDF всегда из LaTeX и включать в файл исходный код. Вот тогда и волки будут сыты, и овцы целы.
Вот только как бы еще от необходимости иметь дело с *TeX'ом избавиться - и совсем все замечательно будет, а так - больно уж "порог входа" высокий.
не позволяют отображать документ одинаково на любых системах
Зачем это "для систем структурирования информации, для семантических сетей, для искусственного интеллекта "?
Это законодательное требование для архивных документов в электронном виде. А то, что Вы пытаетесь использовать архивные документы не по назначению, вместо использования исходников, которыми эти архивные документы сформированы - уже Ваши личные проблемы.
Ну так и речь о том, что для осмысленной обработки надо использовать эти исходники в семантически структурированном формате.
Отсюда и мое предложение выше:
достаточно формировать PDF всегда из LaTeX и включать в файл исходный код
Что не так?
LaTeX - это скорее язык программирования, который притворяется форматом с логической структурой. Если используется только базовый набор с разбивкой на главы/разделы и т.п., проблем с обработкой нет, но в общем случае с кастомным стилевиком и кучкой вспомогательных пакетов для красивых таблиц, диаграмм и прочего автоматически понять смысл отдельных конструкций нетривиально. Но, конечно, это лучше, чем сам по себе PDF или скан распечатки )
Как его не называть, но это средство формирования публикаций типографского качества. Чего не скажешь о том же Word, LibreOffice или, тем более, html.
с кастомным стилевиком и кучкой вспомогательных пакетов для красивых таблиц, диаграмм и прочего
Это неотъемлемая составная часть исходного кода. Несмотря на требование ряда издательств и журналов использовать только предоставляемые ими стилевые файлы.
автоматически понять смысл отдельных конструкций нетривиально
Ну раз TeX понимает, то следовательно задача детерминирована и точно поддается алгоритмизации )
Чего не скажешь о том же Word, LibreOffice или, тем более, html
Я скорее с docbook сравниванию.
Это неотъемлемая составная часть исходного кода
В том то и дело, что это скорее код, чем данные )
раз TeX понимает
TeX понимает, как нарисовать результат интепретации исходника на бумаге, семантика ему не нужна.
Я скорее с docbook сравниванию.
Тем более. Ему даже до LibreOffice далеко. Не говоря уже о типографском качестве.
В том то и дело, что это скорее код, чем данные
Я и писал выше "исходный код". Потому что иным путем обеспечить автоматическую верстку типографского качества вряд ли реально.
TeX понимает, как нарисовать результат интепретации исходника на бумаге, семантика ему не нужна.
Ага, классически "Приду домой в жопу, поставлю чайник на хер и лягу спать в пи..ду.". Вот только чем в распознавании семантики этой фразы тот же docbook Вам поможет? )))
Ему даже до LibreOffice далеко
В него, скажем, FrameMaker умеет, вполне себе профессиональный инструмент.
иным путем обеспечить автоматическую верстку типографского качества вряд ли реально
Надо как то чётко разделять семантическую и типографскую разметку, в ТеXе оно переплетено. В xml-based форматах "типография" вынесена отдельно в stylesheet'ы.
чем в распознавании семантики этой фразы
Мы скорее о семантике структуры (вот этот текст - адрес, вот тот - цитата и т.д.), сам текст пускай LLM распознаёт )
В него, скажем, FrameMaker умеет, вполне себе профессиональный инструмент.
Не об этом речь, а о гарантиях того, что любой имеет возможность увидеть документ точно в таком же виде, в каком его видел автор при верстке. PDF это обеспечивает, TeX - предоставляет такую возможность. А docbook наоборот, рендерит так, как удобно читателю, а вовсе не так, как решил автор. Для технической документации это не только приемлемо, но даже приветствуется. Для нормативных документов и даже научных статей - уже нет.
Надо как то чётко разделять семантическую и типографскую разметку, в ТеXе оно переплетено.
Вообще-то, когда такое происходит, то это - кривые руки того, кто делал шаблон стиля. TeX позволяет смешать семантическую и типографскую разметку. Но совершенно не требует это делать.
Мы скорее о семантике структуры
И много Вы видели TeX шаблонов в стандартной поставке или от приличных журналов/издательств, где этой семантики нет?
вот этот текст - адрес, вот тот - цитата и т.д.
Вот открываю, например, стандартный шаблон letter и вижу: \address, \letter, \signature, \opening, \telephone, \location и т.п. Что я делаю не так? Ну кроме того, что не пытаюсь сам слепить кривой шаблон, в котором для разных семантических целей будут использованы одни и те же команды.
А docbook наоборот, рендерит так, как удобно читателю
Для печати и просмотра людьми docbook обычно рендерится в PDF на стороне автора или издательства.
И много Вы видели TeX шаблонов в стандартной поставке или от приличных журналов/издательств, где этой семантики нет?
Проблемы не с этими шаблонами, а с зоопарком пакетов на CTAN.
открываю, например, стандартный шаблон letter и вижу: \address, \letter, \signature, \opening, \telephone, \location и т.п
Если используются только чётко документированные параметры шаблона - нет проблем. Но TeX это никак не энфорсит - для валидности достаточно, если все макросы нормально раскроются и в результате получится валидный код для собственно TeX'овского движка. В xml можно как минимум проверить, что документ соответствует DTD.
Я не спорю с тем, что TeX хороший инструмент для написания научных статей или книг - но это не лучший формат для автоматизированной обработки.
Для печати и просмотра людьми docbook обычно рендерится в PDF на стороне автора или издательства.
Не понимаю, что значит "или". Гранки туда-сюда посылают, как в прошлом веке? TeX рендерится и на стороне автора для просмотра, и на стороне издательства для типографии. При этом автор точно знает, что после типографии он увидит свой труд в ожидаемом им виде, хоть и не знает, на какой странице журнала или книги этот труд в итоге окажется.
Проблемы не с этими шаблонами, а с зоопарком пакетов на CTAN.
Вообще-то журналы и издательства запрещают подключать пакеты, ограничивая автора только пакетами, упомянутыми в их шаблонах. Иными словами, CTAN применим при создании шаблонов, но уж никак не при написании публикации по утвержденному и проверенному шаблону.
В xml можно как минимум проверить, что документ соответствует DTD.
Что совершенно не гарантирует корректность семантики структуры, если автор не захотел ее придерживаться.
При этом, если исходный код TeX легко может анализироваться человеком, то про DocBook такого уже не скажешь.
Если Code Review для Tex достаточно простая задача, то про DocBook - уже этого не скажешь. При просмотре XML в Pull Request часто ни хрена не понятно и приходится разворачивать весь текст, чтобы осознать, где diff уехал.
автор точно знает, что после типографии он увидит свой труд в ожидаемом им виде
С точки зрения качества картинки - хорошо, с точки зрения автоматизированной обработки - плохо, потому что автор может явно или неявно выражать информацию чисто типографскими средствами.
журналы и издательства запрещают подключать пакеты
Я говорю о TeX как о формате и системе в целом, а не о практике использования в конкрентных местах. С хорошими coding guidelines и C++ - вполне читаемый язык )
При просмотре XML в Pull Request
Значит, нужны средства, вычисляющие и показывающие разницу на уровне xml элементов, а не plain text, который их выражает. Ну и редактировать по хорошему надо в среде, которая понимает DTD и даёт возможность создавать только корректный документ.
автор может явно или неявно выражать информацию чисто типографскими средствами
Маяковский любил выражать информацию такими средствами. Так что теперь, его стихи запрещать? )
о формате и системе в целом, а не о практике использования в конкрентных местах
Нечитабельную хрень можно написать на любом языке. А жесткие и простые методы ограничений использования макропакетов в TeX имеются.
редактировать по хорошему надо в среде
Проблема не в редактировании, а в code review pull requests.
нужны средства, вычисляющие и показывающие разницу на уровне xml элементов
Проще отказаться от XML в пользу других языков, чем написать для GIT специализированную обработку XML. В JSON или YAML таких проблем уже не возникает. Так же, как и TeX.
Что интересно, посмотрел по репозиториям проектов, с которыми работал последнее время. XML встречается только в легаси. С чего бы это?
Маяковский любил выражать информацию такими средствами. Так что теперь, его стихи запрещать? )
Мы всё таки о документах, из которых имеет смысл извлекать информацию в автоматизированном режиме.
А жесткие и простые методы ограничений использования макропакетов в TeX имеются.
Это уже не просто TeX, а TeX с жёсткими ограничениями. Если ещё добавить машинно читаемое описание структуры элементов в шаблоне и автоматическую проверку соответствия документа структуре - по сути будет тот же XML с другим синтаксисом )
В JSON или YAML таких проблем уже не возникает.
Это уже детали маппинга формата на текстовое представление. Мой основной момент в преимуществе декларативного описания над императивным.
XML встречается только в легаси.
Не очень понял, о чём речь. Мы же о документах, а не о коде.
Мы всё таки о документах, из которых имеет смысл извлекать информацию в автоматизированном режиме.
Вы - возможно. А я о любых публикациях типографского качества. В том числе и стихах. Не вижу смысла в зоопарке форматов для таких целей.
Если ещё добавить машинно читаемое описание структуры элементов в шаблоне и автоматическую проверку соответствия документа структуре
Зачем добавлять то, что уже есть? Вы хотя бы на стандартные шаблоны посмотрите. Я уж не говорю о предоставляемых журналами и издательствами.
будет тот же XML
Не будет. Будет намного короче и читабельней.
Мы же о документах, а не о коде.
И я о документах. Которые тоже код. Просто занимаясь разработкой я пользуюсь, в основном, MD. Который без проблем преобразуется при необходимости хоть напрямую в PDF, хоть в TeX. Благо MD позволяет включать элементы на TeX. Причем даже в комментариях исходного кода через /** или //*
И поверьте, при написании кода на SQL, С#, Java, Python и т.п. - это намного удобней, чем пользоваться многословным DocBook.
Не вижу смысла в зоопарке форматов для таких целей.
На мой взгляд всё-таки есть некое противоречие между физическим и логическим описанием, в разных случаях применимо разное.
Вы хотя бы на стандартные шаблоны посмотрите.
Смотрю на банальный article.cls и сходу не вижу, где там требование иерархии вложенности part/section/subsection/...
Просто занимаясь разработкой
Это всё таки специфическая деятельность, я большее о массовой обработке больших документов.
есть некое противоречие между физическим и логическим описанием, в разных случаях применимо разное
Что и решается в TeX разными шаблонами
article.cls
Потому что это класс, а не шаблон. На стандартные шаблоны можете полюбоваться, например, тут https://www.latextemplates.com/
массовой обработке больших документов
Вы недооцениваете объемы документации крупных проектов. Только на текущем проекте уже за 10 ГБ перевалило. А на РАО ЕС "Восток" было почти 100 ГБ.
разве что html с mathml
Тогда уж docbook с mathml. html - тоже скорее для показа, а не структурной обработки.
Но как показывает практика отображаться по разному он все таки может. Более того, не всегда даже печать успешно идет на тот или иной принтер.
Никто не спорит, что нет программ без ошибок. Например, глифы могут слететь из-за кривого хинтинга или его отсутствия. Но чтобы при печати PDF на принтер, аппаратно его поддерживающий через PostScript, вылезло что-то не то - ни разу не встречал. Хотя с типографиями и потоковыми принтерами пообщаться пришлось немало.
За PostScript не скажу, а вот GDI принтера бывает PDF не печатают. Не часто, но все же. Похоже какие-то знаки на печать принтером воспринимаются как служебные и принтер пытается уже не печатать, а обработать команду, "команды" с pdf не понимает (что естественно) и как результат пишет про неустранимую ошибку принтера и необходимость идти в сервис-центр. Когда первый раз такое увидел чуть ли не поверил, оказалось проблема в pdf, а не в принтере.
Что печатает GDI принтер - зависит не от него, а от драйвера. Если в драйвере кривой интерпретатор PostScript - это уже претензии к производителю. Но никто не запрещает отрендерить PDF через тот же GhostScript, после чего даже GDI принтер, скорее всего, напечатает все без искажений. Хотя и в GhostScript баги бывали.
Кто-то считает, что pdf — это конечный файл для печати, и никакой обработке он не подлежит. Но в том же Acrobat Pro доступны 100500 действий: перевести шрифты в кривые, свести прозрачность, обрезать, проверить цветоделение и ink limit. Одних только шаблонов в preflight несколько сотен. А еще доступны плагины с этими и другими возможностями.
Как PDF изменил мир