Move text layer scaling logic to CSS#20491
Conversation
2763604 to
9be3ac8
Compare
|
/botio test |
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @nicolo-ribaudo received. Current queue size: 1 Live output at: http://54.241.84.105:8877/cf5aa7cfca2bd1b/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_test from @nicolo-ribaudo received. Current queue size: 1 Live output at: http://54.193.163.58:8877/3c1cef802ac5954/output.txt |
From: Bot.io (Linux m4)FailedFull output at http://54.241.84.105:8877/cf5aa7cfca2bd1b/output.txt Total script time: 40.17 mins
Image differences available at: http://54.241.84.105:8877/cf5aa7cfca2bd1b/reftest-analyzer.html#web=eq.log |
From: Bot.io (Windows)FailedFull output at http://54.193.163.58:8877/3c1cef802ac5954/output.txt Total script time: 75.12 mins
Image differences available at: http://54.193.163.58:8877/3c1cef802ac5954/reftest-analyzer.html#web=eq.log |
9be3ac8 to
af6868b
Compare
This commit moves all the logic to scale up&down `<span>`s in the text layer, introduced in mozilla#18283, to CSS. The motivation for this change is that mozilla#18283 is still not enough for all cases. That PR fixed the problem in Chrome&Firefox desktop, which allow users to set an actual minimum font size in the browser settings. However, other browsers (e.g. the Chrome-based WebView on Android) have more complex logic and they scale up small text rather than simply applying a minimum. A workaround for that behavior is probably out of scope for PDF.js itself as it only affects not officially supported platforms. However, having access to the actual expected font height (through `--font-height`) allows embedders of PDF.js to implement a workaround by themselves.
af6868b to
eb2b7c2
Compare
|
I manually checked the reftest differences. They are all due to fraction of pixel differences in how the text layer There is also a difference in rounding, that again is effectively unobservable: What's interesting, is that although I can see the difference between The rendering difference is caused by having vs not having |
|
/botio test |
From: Bot.io (Windows)ReceivedCommand cmd_test from @nicolo-ribaudo received. Current queue size: 0 Live output at: http://54.193.163.58:8877/1d55449e9756ece/output.txt |
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @nicolo-ribaudo received. Current queue size: 0 Live output at: http://54.241.84.105:8877/4013f1d58194339/output.txt |
From: Bot.io (Linux m4)FailedFull output at http://54.241.84.105:8877/4013f1d58194339/output.txt Total script time: 39.94 mins
Image differences available at: http://54.241.84.105:8877/4013f1d58194339/reftest-analyzer.html#web=eq.log |
From: Bot.io (Windows)FailedFull output at http://54.193.163.58:8877/1d55449e9756ece/output.txt Total script time: 74.57 mins
Image differences available at: http://54.193.163.58:8877/1d55449e9756ece/reftest-analyzer.html#web=eq.log |
|
Thank you for improving this! |
|
/botio makeref |
From: Bot.io (Linux m4)ReceivedCommand cmd_makeref from @timvandermeij received. Current queue size: 0 Live output at: http://54.241.84.105:8877/c849109f85b68fa/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_makeref from @timvandermeij received. Current queue size: 0 Live output at: http://54.193.163.58:8877/21dfe8066e0b4fe/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/c849109f85b68fa/output.txt Total script time: 17.64 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.193.163.58:8877/21dfe8066e0b4fe/output.txt Total script time: 30.30 mins
|
Commit message:
In my app that uses PDF.js I'm currently patching the PDF.js code to export the text height as
textDiv.dataset.fontHeight = fontHeight;. I find the approach proposed in this PR to be cleaner, as it has the benefit of moving style-related logic from the JS file to the CSS file.What do you think about this change?