Pdf.js: SVG 경로가 2개의 노드로 잘못 분할됨

이것은 버그 #9167과 관련이 있을 수 있습니다.

범인이 여기에 있다고 생각합니다.
https://github.com/mozilla/pdf.js/blob/a045a00af34b764edda5991d2bcd18541ed60536/src/core/operator_list.js#L533 -L534
OperatorList 의 작동 방식에 익숙하지 않지만 연산자 목록이 약 1000개의 연산자 덩어리로 분할된 것처럼 보입니다. 때때로 청크 경계가 PDF 경로 정의의 중간에 배치됩니다. 이것은 두 개의 OPS.constructPath 연산자를 생성하고 후자는 moveTo 시작하지 않습니다.

그럴듯하게 들리나요?

OperatorList 및 상수 CHUNK_SIZE 를 수정하는 대신 svg.js를 수정해야 합니다. 아마도 다음과 같을 것입니다. 중간 경로 페인팅 연산자가 없으면 연속 OPS.constructPath 연산자를 하나의 <svg:path> 노드로 결합해야 합니다...

OperatorList 의 작동 방식에 익숙하지 않지만 연산자 목록이 약 1000개의 연산자 덩어리로 분할된 것처럼 보입니다.

옳은; 이는 전체 OperatorList (즉, 페이지)가 구문 분석되기 전에 렌더링을 시작할 수 있도록 하여 페이지 로드에서 완전히 렌더링되는 데 필요한 전체 시간을 줄이기 위한 것입니다.

그럴듯하게 들리나요?

예, 확인하기 쉬워야 합니다(값 을 많이 늘리면 이 청크를 효과적으로 비활성화할 수 있음).

OperatorList 및 상수 CHUNK_SIZE 를 수정하는 대신 svg.js를 수정해야 합니다.

동의합니다. 상수를 수정하는 것은 확실히 허용 가능한 솔루션이 아닙니다. 우선, 오류를 다른 곳으로 옮기는 것 외에는 아무 것도 하지 않습니다. 두 번째로, 훨씬 더 중요한 것은 이를 변경하면 캔버스 백엔드의 일반적인 렌더링 성능에 광범위한 영향을 미칠 수 있다는 것입니다.

아마도 다음과 같을 것입니다. 중간 경로 페인팅 연산자가 없으면 연속 OPS.constructPath 연산자를 하나의 <svg:path> 노드로 결합해야 합니다...

다시 말하지만, 그것은 완전히 합리적으로 들립니다.

CHUNK_SIZE를 10000000으로 늘리면 문제가 사라짐을 확인할 수 있습니다.
(그리고 나는 이것이 적절한 해결책이 아니라는 데 동의합니다)
당신의 도움을 주셔서 감사합니다.