Support (rare) Type3 fonts which contains image resources (issue 10717) #10727
Conversation
From: Bot.io (Windows)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.215.176.217:8877/a27c626b9243116/output.txt |
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/b83e58f9bf432af/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/b83e58f9bf432af/output.txt Total script time: 17.91 mins
|
From: Bot.io (Windows)FailedFull output at http://54.215.176.217:8877/a27c626b9243116/output.txt Total script time: 25.29 mins
Image differences available at: http://54.215.176.217:8877/a27c626b9243116/reftest-analyzer.html#web=eq.log |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/83b6bdca692b4fc/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/83b6bdca692b4fc/output.txt Total script time: 1.86 mins Published |
Snuffleupagus
force-pushed
the
type3-image-resources
branch
from
e63b530
to
cc40896
Compare
The Type3 font type is not commonly used in PDF documents, as can be seen from telemetry data such as: https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2019-04-09&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=nightly%252F68&measure=PDF_VIEWER_FONT_TYPES&min_channel_version=nightly%252F57&processType=*&product=Firefox&sanitize=1&sort_by_value=0&sort_keys=submissions&start_date=2019-03-18&table=0&trim=1&use_submission_date=0 (see also https://github.com/mozilla/pdf.js/wiki/Enumeration-Assignments-for-the-Telemetry-Histograms#pdf_viewer_font_types). Type3 fonts containing image resources are *very* rare in practice, usually they only contain path rendering operators, but as the issue shows they unfortunately do exist. Currently these Type3-related image resources are not handled in any special way, and given that fonts are document rather than page specific rendering breaks since the image resources are thus not available to the *entire* document. Fortunately fixing this isn't too difficult, but it does require adding a couple of Type3-specific code-paths to the `PartialEvaluator`. In order to keep the implementation simple, particularily on the main-thread, these Type3 image resources are completely decoded on the worker-thread to avoid adding too many special cases. This should not cause any issues, only marginally less efficient code, but given how rare this kind of Type3 font is adding premature optimizations didn't seem at all warranted at this point.
Snuffleupagus
force-pushed
the
type3-image-resources
branch
from
cc40896
to
be604bd
Compare
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/21d831b50465500/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 1 Live output at: http://54.215.176.217:8877/7ca3222fe354a03/output.txt |
From: Bot.io (Linux m4)FailedFull output at http://54.67.70.0:8877/21d831b50465500/output.txt Total script time: 17.70 mins
|
From: Bot.io (Windows)FailedFull output at http://54.215.176.217:8877/7ca3222fe354a03/output.txt Total script time: 25.41 mins
Image differences available at: http://54.215.176.217:8877/7ca3222fe354a03/reftest-analyzer.html#web=eq.log |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/61def9404012714/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/61def9404012714/output.txt Total script time: 1.88 mins Published |
| @@ -2003,6 +2003,7 @@ class WorkerTransport { | |||
| }); | |||
| break; | |||
| case 'FontPath': | |||
| case 'FontType3Res': | |||
There was a problem hiding this comment.
I may be missing something, but why can't we just stick these in the objs so we don't have to do all the typ3e checks in canvas?
There was a problem hiding this comment.
That's what's currently happening without this patch, and that breaks because fonts are common to the entire document (i.e. placed in commonObjs), whereas the objs are unique for each page.
Since the same font is used on multiple pages, but the image resources were only available to the first page, using objs cannot work for these kind of font resource.
Hence the only simple way, that I could find at least, was to make these resources available "globally" which thus necessitated small changes in src/display/canvas.js.
|
/botio makeref |
From: Bot.io (Linux m4)ReceivedCommand cmd_makeref from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/6ea822943ac3e0a/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_makeref from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.215.176.217:8877/1aea4c64f4b017a/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/6ea822943ac3e0a/output.txt Total script time: 16.15 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.215.176.217:8877/1aea4c64f4b017a/output.txt Total script time: 23.13 mins
|
|
Thanks! |
The Type3 font type is not commonly used in PDF documents, as can be seen from telemetry data such as: https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2019-04-09&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=nightly%252F68&measure=PDF_VIEWER_FONT_TYPES&min_channel_version=nightly%252F57&processType=*&product=Firefox&sanitize=1&sort_by_value=0&sort_keys=submissions&start_date=2019-03-18&table=0&trim=1&use_submission_date=0 (see also https://github.com/mozilla/pdf.js/wiki/Enumeration-Assignments-for-the-Telemetry-Histograms#pdf_viewer_font_types).
Type3 fonts containing image resources are very rare in practice, usually they only contain path rendering operators, but as the issue shows they unfortunately do exist.
Currently these Type3-related image resources are not handled in any special way, and given that fonts are document rather than page specific rendering breaks since the image resources are thus not available to the entire document.
Fortunately fixing this isn't too difficult, but it does require adding a couple of Type3-specific code-paths to the
PartialEvaluator. In order to keep the implementation simple, particularily on the main-thread, these Type3 image resources are completely decoded on the worker-thread to avoid adding too many special cases. This should not cause any issues, only marginally less efficient code, but given how rare this kind of Type3 font is adding premature optimizations didn't seem at all warranted at this point.Fixes #10717.