[Bug]: convertToPdfPoint or getViewport do not account for DPI scale

[croraf]

Comparing coordinates in the page.getAnnotations() output and the coordinates produced with page.getViewport({scale: pdfViewer.currentScale}) and convertToPdfPoint I notice that the transform does not give the correct output.

Web browser and its version

Chromium 144 (Version 144.0.7559.96 (Official Build) snap (64-bit))

Operating system and its version

Ubuntu 24.04

PDF.js version

5.4.530

Is the bug present in the latest PDF.js version?

Yes

Is a browser extension

No

Steps to reproduce the problem

1. do the selection of text
2. grab one clientRect from this selection
3. map to coordinates relative to the page

    const localX = rect.left - textLayerDivBounds.left;
    const localY = rect.top - textLayerDivBounds.top;

4. Use the viewport and apply conversion

const viewport = page.getViewport({ scale: pdfViewer.currentScale });`
// where `currentScale = 1`
const [pdfX, pdfY] = viewport.convertToPdfPoint(localX, localY);

What is the expected behavior?

I compare the result with the highlight annotation at the same position and expect the coordinates to be the same.

What went wrong?

The highlight annotation coordinates and my result of selection is different.

For the bottom part of the page the pdfY is negative, like -140.

If I multiply pdfViewer.currentScale by 4/3 the result is correct.

Link to a viewer

No response

Additional context

The error of factor 4/3 is exactly equal to var(--scale-factor)

--total-scale-factor: calc(var(--scale-factor) * var(--user-unit));

which is the same as CSS standard of 96 DPI divided by PDF standard of 72 DPI, if I understand correctly.

The getViewport or convertToPdfPoint should account for that in the transformations.

[Snuffleupagus]

The getViewport or convertToPdfPoint should account for that in the transformations.

I'm not convinced that'd be generally appropriate, since it'd risk breaking various PDF.js library/viewer use-cases and lead to annoying fallout/regressions to deal with.

Unless there's a bug here affecting the Firefox PDF Viewer, I'd strongly advise against changing that code.