Display widget signature in SVG

[CetinSert]

Attach (recommended) or Link to PDF file here:
https://github.com/mozilla/pdf.js/blob/master/test/pdfs/bug854315.pdf

Configuration:

• Web browser and its version: -
• Operating system and its version: -
• PDF.js version: >=2.8.335
• Is a browser extension: -

Steps to reproduce the problem:

1. use canvas rendering ✔
2. use SVG rendering ❌

What is the expected behavior? (add screenshot)

What went wrong? (add screenshot)
SVG backend was not updated with #13214

Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):
http://54.67.70.0:8877/f90cd937a5806b8/web/viewer.html
https://mozilla.github.io/pdf.js/web/viewer.html

@calixteman
I think it is important to keep the two renderers in sync. Pull requests that break this should at least mention what needs to be done in the other backend to maintain feature parity.

[Snuffleupagus]

I think it is important to keep the two renderers in sync.

No, that's not really necessary since the FAQ specifically mentions that the SVG-backend is unsupported (it will never perform well enough for general use, given the huge number of DOM-elements it creates); please note https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#backends

Pull requests that break this should at least mention what needs to be done in the other backend to maintain feature parity.

Sorry, but while you might want that, we have no such requirements at all (since that'd only serve to slow down/hinder overall development of the canvas-backend)!

[Snuffleupagus]

This is, for all intents and purposes, a duplicate of #10165

[CetinSert]

@Snuffleupagus this does stand in contrast to a recently closed project
https://github.com/mozilla/pdf.js/projects/2

SVG back-end
Closed Updated on Oct 14, 2020
Improve the SVG back-end for viewing and printing.

[Snuffleupagus]

this does stand in contrast to a recently closed project
https://github.com/mozilla/pdf.js/projects/2

No, it doesn't since the information which is provided in the FAQ is the official position.

That project was closed since there's no work happening/planned for the SVG-backend, for the reasons already mentioned. (Generally speaking, the mere closing of an old and now irrelevant project cannot be construed as something automatically being supported.)

[CetinSert]

@Snuffleupagus

No, that's not really necessary since the FAQ specifically mentions that the SVG-backend is unsupported (it will never perform well enough for general use, given the huge number of DOM-elements it creates); please note https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#backends

1. SVG backend is unparalleled in touch screens where one can pinch to zoom freely and everything stays crystal clear at all times.
2. It is trivial for anyone to only render the internals of a page currently intersecting with the browser viewport using an IntersectionObserver – rendering 1 or a few pages totally mitigates any high-number-of-DOM-elements issues.

I would love to know what it takes to keep the SVG backend at parity. In your assessment would one developer fully dedicated to it be enough or does it require more effort? (I understand you might prefer not to burden all developers to consider both backends as you prioritize the canvas one for Mozilla's use.)

[Snuffleupagus]

I would love to know what it takes to keep the SVG backend at parity.

Please read what I've already written (multiple times now), which is that the sheer number of DOM elements generated for anything but trivial PDF documents will lead to really poor memory usage and very poor overall performance (e.g. when scrolling).

rendering 1 or a few pages totally mitigates any high-number-of-DOM-elements issues.

The demo viewer already limits the number of visible/rendered pages, regardless of backend, to improve performance and reduce memory usage. For the SVG-backend that's, as already mentioned, still not enough in many cases!

In your assessment would one developer fully dedicated to it be enough or does it require more effort?

You'd have to somehow get browsers to handle the case of huge amounts of DOM elements better, there's generally speaking nothing we can do about that here.

(I understand you might prefer not to burden all developers to consider both backends as you prioritize the canvas one for Mozilla's use.)

No-one ought to be using the SVG-backend, given its issues. In my personal opinion: it'd basically be a waste of development/reviewer resources to work on the SVG-backend, all things considered.

---

The reason why work on the SVG-backend stopped, is that it wasn't deemed feasible to get in working as well (overall) as the canvas-backend already does.

[Snuffleupagus]

@timvandermeij Mind closing this, please note #13219 (comment).

[timvandermeij]

Yes, this is indeed a duplicate.