Pdf.js: Путь SVG неправильно разбит на 2 узла
Прикрепите (рекомендуется) или ссылку на файл PDF здесь:
test4.pdf
Конфигурация:
- Веб-браузер и его версия: Chrome 56.0.2924.76
- Операционная система и ее версия: Linux Mint 18.3
- Версия PDF.js: зафиксировать c0d6e46e392b327996eb0964b7932cb5bdde1727
- Расширение браузера: нет
Шаги по воспроизведению проблемы:
- запустите "node pdf2svg.js test4.pdf"
- загрузить выходной файл test4.1.svg в Chrome
- Проверьте журнал ошибок консоли. Вы увидите это:
Какое ожидаемое поведение? (добавить скриншот)
Ошибок нет.
Что пошло не так? (добавить скриншот)
Один путь на выходе разделен на 2 части.
Начальная «M» находится в одном узле, а следующая «L» - в следующем узле.
Они должны быть в одном узле.
Ссылка на программу просмотра (если она размещена на сайте, отличном от mozilla.github.io/pdf.js или как расширение Firefox / Chrome):
johnkingsley
Все 4 Комментарий
Это может быть связано с ошибкой № 9167.
johnkingsley
6 февр. 2019
Думаю, виноват здесь:
https://github.com/mozilla/pdf.js/blob/a045a00af34b764edda5991d2bcd18541ed60536/src/core/operator_list.js#L533 -L534
Я не очень знаком с работой OperatorList но похоже, что списки операторов разбиты на блоки примерно по 1000 операторов. Иногда граница блока помещается в середину определения пути PDF. Это дает два оператора OPS.constructPath и последний не начинается с moveTo .
Звучит правдоподобно?
Вместо изменения OperatorList и его константы CHUNK_SIZE следует исправить svg.js. Может быть так: последовательные операторы OPS.constructPath должны быть объединены в один узел <svg:path> если нет промежуточного оператора рисования пути ...
janpe2
12 февр. 2019
Я не очень знаком с работой
OperatorListно похоже, что списки операторов разбиты на блоки примерно по 1000 операторов.
Верный; это позволяет начать рендеринг до того, как весь OperatorList (т.е. страница) будет проанализирован, тем самым сокращая общее время, необходимое от загрузки страницы до ее полной визуализации.
Звучит правдоподобно?
Да, и это должно быть легко проверить (просто сильно увеличьте значение, отключив это разбиение на части).
Вместо изменения
OperatorListи его константыCHUNK_SIZEследует исправить svg.js.
Согласны, изменение константы определенно не является приемлемым решением. Во-первых, это не что иное, как перемещение ошибки в другое место. Во-вторых, и что гораздо важнее, его изменение может иметь далеко идущие последствия для общей производительности рендеринга в серверной части холста.
Может быть так: последовательные операторы
OPS.constructPathдолжны быть объединены в один узел<svg:path>если нет промежуточного оператора рисования пути ...
Опять же, это звучит вполне разумно.
Snuffleupagus
12 февр. 2019
Я могу подтвердить, что если я увеличу CHUNK_SIZE до 10000000, проблема исчезнет.
(и я согласен, что это неправильное решение)
Спасибо за вашу помощь.
johnkingsley
13 февр. 2019
Смежные вопросы
THausherr
·
3Комментарии
zerr0s
·
3Комментарии
PeterNerlich
·
3Комментарии
jigskpatel
·
3Комментарии
hp011235
·
4Комментарии
Самый полезный комментарий
Верный; это позволяет начать рендеринг до того, как весь
OperatorList(т.е. страница) будет проанализирован, тем самым сокращая общее время, необходимое от загрузки страницы до ее полной визуализации.Да, и это должно быть легко проверить (просто сильно увеличьте значение, отключив это разбиение на части).
Согласны, изменение константы определенно не является приемлемым решением. Во-первых, это не что иное, как перемещение ошибки в другое место. Во-вторых, и что гораздо важнее, его изменение может иметь далеко идущие последствия для общей производительности рендеринга в серверной части холста.
Опять же, это звучит вполне разумно.