Pdf.js: отсутствует поддержка параметра "viewrect" в идентификаторах фрагментов URL

Привет,
Я новичок здесь, ищу проблему, которую нужно исправить, и я хотел бы исправить эту проблему, если кто-то еще не делает это. И я также прочитал документацию о viewRect, я не совсем уверен, что означает wd и ht.
Кто-нибудь может просветить меня об этом wd и ht, пожалуйста? Заранее спасибо.

Не стесняйтесь работать над этим. Я думаю, что wd - это "ширина", а ht - "высота".

Привет, @AndrewMyint , я просто хотел указать вам на пару проблем, связанных с этим, которые документируют ошибочное поведение текущей реализации (ошибочно названного) параметра " zoom ": https: // github .com / mozilla / pdf.js / issues / 10773 и https://github.com/mozilla/pdf.js/issues/2843.

Спасибо @markmatney. Я просматривал pdf_link_service.js и удивлен, что параметр " zoom " обрабатывает аргумент Fit тогда как его следует обрабатывать в " view " параметр согласно документации .

@markmatney Если я не ошибаюсь, все значения, предоставленные в качестве аргументов, такие как (left, top, scale, Fit, ...) , используются в BaseViewer.scrollPageIntoView . И есть несколько вариантов переключения case (Fit, FitB, FitH,......) в scrollPageIntoView . И один интересный случай, который я обнаружил, - это FitR который я даже не вижу в документации аргумента FitR .

Но мне кажется, что « FitR » вызывает поведение « viewrect », если вы добавляете #zoom=FitR,72,72,288,432 в адресную строку URL.

Не могли бы вы подтвердить, что это ожидаемое поведение для viewrect , пожалуйста? Спасибо.

Да, я считаю, что BaseViewer.scrollPageIntoView - это метод, который просматривает все эти аргументы, а затем каким-то образом преобразует область просмотра на их основе.

Я также вспоминаю, что видел FitR когда впервые смотрел на это. Он был представлен в master на d30fac0 (4 сентября 2011 г.) вместе с остальными аргументами Fit* и определен в спецификации PDF Reference . Я не уверен, почему он был опущен в спецификации «Параметры для открытия файлов PDF» (или почему есть даже две отдельные спецификации, если на то пошло).

В любом случае, у меня есть твердое мнение, что viewrect следует реализовывать иначе, чем FitR . Это, конечно, спорный вопрос, но:

• простое обращение с ними будет излишним и ограничит количество вариантов использования, которые могут быть выполнены с помощью этого программного обеспечения, и
• поскольку спецификации PDF определяют семантику каждого по-разному, мы, безусловно, _ можем_ реализовать их по-разному, при этом придерживаясь спецификаций.

Я надеюсь увидеть реализацию viewrect где, в отличие от FitR , результирующее представление не зависит от размеров окна веб-браузера пользователя. Чтобы понять, что я имею в виду, перейдите на https://mozilla.github.io/pdf.js/web/viewer.html#zoom = FitR, 0,0,144,144. Этот фрагмент URL-адреса просит зрителя показать квадратную область размером примерно 2 x 2 дюйма (_w_ x _h_, 1 ~ 72 пикселей). В настоящее время, если мой браузер работает в полноэкранном режиме с разрешением 1080 x 720 (соотношение 3: 2) Ориентированный пейзаж, тогда мне на самом деле будет показана область 3 "x 2". Если я поверну дисплей на 90 градусов и просматриваю тот же прямоугольник в полноэкранном браузере, то мне будет показана область 2 "x 3". Это потому, что PDF.JS заполняет остальное доступное пространство в соответствии со спецификацией PDF Reference, стр. 583:

[_page_ / FitR _left_ _bottom_ _right_ _top_]

Отобразите страницу, обозначенную _page_, с ее содержимым, увеличенным настолько, чтобы соответствовать прямоугольнику, заданному координатами [...] целиком внутри окна [...] Если требуемые коэффициенты увеличения по горизонтали и вертикали различны, используйте меньший из два [...]

«Параметры для открытия файлов PDF» определяют viewrect гораздо более свободно (см. Определение во вступительном комментарии к этой проблеме). Я хотел бы увидеть реализацию, которая отображает одну и ту же область независимо от размера окна браузера, чтобы все, что находится за пределами указанной области, было бы не в фокусе («затененным» или «затемненным»). Если я чего-то не упускаю, такая реализация все равно будет соответствовать спецификации.

Прочитав свой комментарий, я только что понял, что реализация PDFjs FitR отличается от спецификации PDF Reference. Он интерпретирует прямоугольник как _x, y, w, h_, тогда как он должен интерпретироваться как _left, bottom, right, top_.