Pdf.js: SVG path is incorrectly broken into 2 nodes
Attach (recommended) or Link to PDF file here:
test4.pdf
Configuration:
- Web browser and its version: Chrome 56.0.2924.76
- Operating system and its version: Linux Mint 18.3
- PDF.js version: commit c0d6e46e392b327996eb0964b7932cb5bdde1727
- Is a browser extension: no
Steps to reproduce the problem:
- run "node pdf2svg.js test4.pdf"
- load the output test4.1.svg into Chrome
- Check the console error log. You will see this:
What is the expected behavior? (add screenshot)
No errors.
What went wrong? (add screenshot)
One path in the output got split into 2 parts.
The initial "M" is in one node and the following "L" is in the next node.
These should be in the same node.
Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):
johnkingsley
All 4 comments
This may be related to bug #9167.
johnkingsley
on 6 Feb 2019
I think the culprit is here:
https://github.com/mozilla/pdf.js/blob/a045a00af34b764edda5991d2bcd18541ed60536/src/core/operator_list.js#L533-L534
I'm not very familiar with the workings of OperatorList but it looks like operator lists are split into chunks of about 1000 operators. Sometimes the chunk boundary is placed in the middle of a PDF path definition. This produces two OPS.constructPath operators and the latter one doesn't start with a moveTo.
Does this sound plausible?
Instead of modifying OperatorList and its constant CHUNK_SIZE, svg.js should be fixed. Maybe like this: Consecutive OPS.constructPath operators should be combined into one <svg:path> node if there is no intervening path painting operator...
janpe2
on 12 Feb 2019
I'm not very familiar with the workings of
OperatorListbut it looks like operator lists are split into chunks of about 1000 operators.
Correct; this is to allow rendering to begin before the entire OperatorList (i.e. the page) has been parsed, thus reducing overall time needed from the page loading to it being fully rendered.
Does this sound plausible?
Yes, and it should be easy to verify (just increase the value a lot, effectively disabling this chunking).
Instead of modifying
OperatorListand its constantCHUNK_SIZE, svg.js should be fixed.
Agreed, modifying the constant is definitely not an acceptable solution. First of all, it would do nothing more than move the error elsewhere. Second of all, and much more importantly, changing it could have far-reaching implications for the general rendering performance in the canvas back-end.
Maybe like this: Consecutive
OPS.constructPathoperators should be combined into one<svg:path>node if there is no intervening path painting operator...
Again, that sounds totally reasonable.
Snuffleupagus
on 12 Feb 2019
I can confirm that if I increase CHUNK_SIZE to 10000000 then the problem goes away.
(and I agree that this isn't a proper solution)
Thanks for your help.
johnkingsley
on 13 Feb 2019
Related issues
PeterNerlich
·
3Comments
SehyunPark
·
3Comments
aaronshaf
·
3Comments
jigskpatel
·
3Comments
liuzhen2008
·
4Comments
Most helpful comment
Correct; this is to allow rendering to begin before the entire
OperatorList(i.e. the page) has been parsed, thus reducing overall time needed from the page loading to it being fully rendered.Yes, and it should be easy to verify (just increase the value a lot, effectively disabling this chunking).
Agreed, modifying the constant is definitely not an acceptable solution. First of all, it would do nothing more than move the error elsewhere. Second of all, and much more importantly, changing it could have far-reaching implications for the general rendering performance in the canvas back-end.
Again, that sounds totally reasonable.