Обязательный электронный экземпляр и преобразование PDF в PDF/A для РГБ

  • Автор темы Автор темы BorA
  • Дата начала Дата начала

Вложения

  • Clipboard02.jpg
    Clipboard02.jpg
    292.4 КБ · Просм.: 393
Курите тему и факи
 

Вложения

  • tag.JPG
    tag.JPG
    65.4 КБ · Просм.: 446
  • Спасибо
Реакции: AM Labs Solutions
В переводе с адобовского на человеческий язык формулировка ошибки звучит "В PDF содержится массив размером более 8191 элемент"
Снова повторяю - каким боком это соотносится с тэгированой информацией?
Нет, я не исключаю, что злосчастный массив именно в ней, но суть шаманства, путем которого наванговали что именно в этом дело от меня ускользает
 
Миш, ты ж спросил каким боком удалить тэги?
 

@german показал. Ещё скриншоты.


В переводе с адобовского на человеческий язык формулировка ошибки звучит "В PDF содержится массив размером более 8191 элемент"
Снова повторяю - каким боком это соотносится с тэгированой информацией?
Нет, я не исключаю, что злосчастный массив именно в ней, но суть шаманства, путем которого наванговали что именно в этом дело от меня ускользает

Пару недель назад разбирали с Senior Developer из Callas несколько сложных файлов с подобными ошибками.
 

Вложения

  • Screen Shot 2019-11-13 at 09.27.43.png
    Screen Shot 2019-11-13 at 09.27.43.png
    292.8 КБ · Просм.: 395
  • Screen Shot 2019-11-13 at 09.27.01.png
    Screen Shot 2019-11-13 at 09.27.01.png
    322.8 КБ · Просм.: 393
Миш, ты ж спросил каким боком удалить тэги?
Я спросил "каким боком тэги к процитированной ошибке"
У AM Labs случайно совпал пролет самолета с началом сезона дождей и он теперь советует всем культовые самолеты из глины и палок лепить
 
  • Спасибо
Реакции: ~RA~
Я спросил "каким боком тэги к процитированной ошибке"
У AM Labs случайно совпал пролет самолета с началом сезона дождей и он теперь советует всем культовые самолеты из глины и палок лепить
А с РГБ всё случайно. Они случайно стали навязывать всем формат, в котором сами нифига не шарят, зато мозг всем вынесли. Подозреваю, что и сам Адобе в этом формате мало чего шарит. Это был крик негодования в сторону РГБ, ежели что 'otbline'
 
Я спросил "каким боком тэги к процитированной ошибке"
У AM Labs случайно совпал пролет самолета с началом сезона дождей и он теперь советует всем культовые самолеты из глины и палок лепить

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

The problem is actually a design error in the tagging structure in PDF format. The so-called "ParentTree" tags pages (via the "StructParents" number) with certain page contents. This tagging is index-based, i.e. an Index-in an array is used. The indexes are stored in the Mark-Content commands as "MCID", e.g. like this:
".../Span<</Long(en-US)/MCID 395>>BDC..."
Since these "MCID" are numbered consecutively over all pages, they can quickly assume large numerical values. Due to the format of the "ParentTree" and the indexing, all entries in the arrays below the first index used in the page are filled with "zero".
This leads to an overflow of the arrays in a "ParentTree" in multi-page documents with a lot of tagging structure.

Всего доброго!
 
Последнее редактирование:
Не совсем понимаю, на основании чего был сделан такой вывод. Вот привожу кусок callasовской документации, где приводятся возможные места локализации данной ошибки:
1573636041193.png
 
@hulk1776, вы можете проверить (удалить) теги в вашем файле или отправить это файл мне для проверки моего "вангования"? Вангую, что и страниц в файле много... :)
 
Всех приветствую! Примерно понимаю, чем мне это грозит, но всё же сразу скажу: я имею отношение к РГБ.

За несколько вечеров я честно прочитал все предыдущие 77 страниц темы, чтобы проникнуться атмосферой проблем и чтобы меня трудно было упрекнуть, мол, "не читал, но мнение имеет". В относительно недалёком прошлом я руководил отделом препресса, так что чтиво не только полезное с точки зрения нынешней работы, но и интересное - вспомнил молодость.

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

Я вряд ли смогу ответить на все вопросы из серии "почему", "зачем", "на фига" и т.п. Во-первых, потому, что я не участвовал в принятии тех решений, которые были приняты и которые так всех здесь раздражают. Во-вторых, потому, что в данной теме это всё равно будет офтопом. Отвечу на два самых очевидных вопроса, которые касаются непосредственно меня:
1. Зачем я здесь?
- Чтобы постараться понять, как надо реформировать систему приёма обязательного экземпляра.
2. Почему не пришёл раньше?
- Потому что присоединился к РГБ совсем недавно.

Негатива в теме, конечно, много. В том числе, вполне справедливого. Тем не менее, хочется сказать несколько слов и в оправдание существующей системы приёма ОЭ:

1. Мы должны выполнять требования законодательства. Не имея на начальном этапе собственной экспертизы в тонкостях PDF, библиотека, естественно, была вынуждена отдать задачу подрядчикам. В результате появился механизм, построенный на движке VeraPDF. Собственно говоря, все "ошибки на непонятном техноязе" - это переведённые на русский язык тексты ошибок, которые умеет генерить VeraPDF. К сожалению, от наличия перевода эти тексты понятнее не стали.

2. Ряд проблем вызван не тем, что система ОЭ предъявляет слишком жёсткие требования к файлам, а тем, что профессиональные инструменты для создания PDF/A содержат ошибки (вспомните хотя бы траблы с 8-м Акробатом). В теме, кстати, видел упоминания о том, что типографии требовали упрощения файлов, т.к. сложные файлы рип переварить не мог. Как видите, PDF/X тоже не является панацеей. Проблема в том, что PDF - очень сложный и неидеальный, на самом-то деле, формат.

3. Одно из требований законодательства - ОЭ должен быть подписан. PDF/A изначально разрабатывался с оглядкой на ЭЦП. Когда мы открываем PDF/A в Adobe Reader'е, мы видим предупреждение о том, что возможность редактирования отключена. В PDF/X такие ограничения не закладывались, соответственно файл на любом из этапов может быть непроизвольно изменён (напр., отредактированы какие-то из технических полей). В результате цифровая подпись слетит. Что-то мне подсказывает, что ни издатели, ни библиотеки не хотели бы работать с этими самыми экземплярами на CD/DVD/флешках с подписью гендиректора и печатью на поверхности носителя.

4. Напомню, что обязательный экземпляр нужен, чтобы сохранить культурное наследие. Задача верстальщика - сверстать, отправить в типографию. Наша задача - собрать все издаваемые документы в таком виде, чтобы потомки могли их прочитать. Собранное мы должны пронумеровать и положить на полку. Мы не враги издателям, мы тоже делаем свою работу. Просто это другая работа. PDF/A был разработан именно для архивного хранения и используется во многих странах, он был принят у нас, просто потому что является best practice. Если кому интересно почитать про этот стандарт и его применение, то вот есть неплохая брошюра (сорри, у меня есть ссылка только на английскую версию): https://www.pdfa.org/wp-content/uploads/2013/05/PDFA_in_a_Nutshell_211.pdf

5. С моей точки зрения, самая сложная техническая проблема на сегодняшний день - это текстовый слой. Как многие уже убедились, для англоязычных инструментов вполне естественно взять и просто так сменить кодировку, например, с 1251 на стандартный ANSI 1252 - программисты на Западе иногда просто не вспоминают, что кто-то использует символы из второй половины таблицы ASCII для букв своих алфавитов, а уж про CJK (китайский, корейский, японский) я вообще молчу. Возможно, решение лежит в плоскости стандарта PDF/A-3u. Буква "U" прозрачно намекает на мэппинг всех символов в юникод, что, по идее, должно снимать вопросы с сабсетами шрифтов, да и просто с "кривыми" шрифтами. Я был бы весьма благодарен, если кто-то из форумчан поможет провести исследования в этом направлении.

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

Потомкам же нужен текст, а не средства гигиены и псевдолекарства?
 
@George, о отличать нетленку от рекламы ты будешь?
 
  • Спасибо
Реакции: kstati
@Lupantrop

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

Потомкам же нужен текст, а не средства гигиены и псевдолекарства?
Абсолютно согласен.
А уж добавим факт, что нередко реклама делается на стороне. Контролировать её с точки зрения маразма РГБ, а не реалий типографии — терять прибыль — "весело".

Не буду тыкать пальцами, есть несколько заказчиков, использующих специально купленные для корпоративных нужд шрифты. Как быть? Заказчик рекламы должен раздавать свою покупку за доп. бабло автору, или же кривить? Или исполнитель обязан покупать тот же шрифт за право на публикацию рекламы?
Ответ очевиден. Весело.
 
Последнее редактирование:
Любой кривой элемент должен считаться графикой, а не текстом.
Я работаю в крупном издании. Как мтс-мегафон-билайн. Не редко получаю "кривые" полосы. Сегодня - 16 из 60. Исходников нет.
РГБ превращает в шамана.
 
Последнее редактирование:
  • Спасибо
Реакции: George