Pdf.js: SVGパスが誤って2つのノードに分割されている

これはバグ＃9167に関連している可能性があります。

犯人はここにいると思います：
https://github.com/mozilla/pdf.js/blob/a045a00af34b764edda5991d2bcd18541ed60536/src/core/operator_list.js#L533 -L534
私はOperatorListの仕組みにあまり詳しくありませんが、演算子リストが約1000個の演算子のチャンクに分割されているようです。 チャンク境界がPDFパス定義の中央に配置されることがあります。 これにより、2つのOPS.constructPath演算子が生成され、後者はmoveTo始まりません。

これはもっともらしいと思いますか？

OperatorListとその定数CHUNK_SIZEを変更する代わりに、svg.jsを修正する必要があります。 たぶん次のようになります。パスペインティング演算子が介在しない場合は、連続するOPS.constructPath演算子を1つの<svg:path>ノードに結合する必要があります。

私はOperatorListの仕組みにあまり詳しくありませんが、演算子リストが約1000個の演算子のチャンクに分割されているようです。

正しい; これは、 OperatorList全体（つまりページ）が解析される前にレンダリングを開始できるようにするためです。これにより、ページの読み込みから完全にレンダリングされるまでに必要な全体的な時間が短縮されます。

これはもっともらしいと思いますか？

はい、それ（だけで効果的にこのチャンキングを無効に、値をたくさん増やす）を確認するために簡単なはずです。

OperatorListとその定数CHUNK_SIZEを変更する代わりに、svg.jsを修正する必要があります。

同意しました。定数を変更することは、絶対に受け入れられる解決策ではありません。 まず第一に、それはエラーを他の場所に移動するだけです。 第二に、そしてはるかに重要なことに、それを変更すると、キャンバスバックエンドの一般的なレンダリングパフォーマンスに広範囲にわたる影響を与える可能性があります。

たぶん次のようになります。パスペインティング演算子が介在しない場合は、連続するOPS.constructPath演算子を1つの<svg:path>ノードに結合する必要があります。

繰り返しますが、それは完全に合理的に聞こえます。

CHUNK_SIZEを10000000に増やすと、問題が解決することを確認できます。
（そして私はこれが適切な解決策ではないことに同意します）
ご協力いただきありがとうございます。