pdfをレンダリングするためのカスタムpdfビューアhtmlページがあります。私はpdfをレンダリングするためにpdfjsライブラリを使用しています。それは私のためにうまくいきます。pdfviewer.jsを使用してスクロールしながら大量のPDFをレンダリングする時間がかかる
小さなpdfファイルを開くと、大きなファイルを開くとすぐにファイルがダウンロードされてレンダリングされます。 すぐにpdfファイルをダウンロードしますが、pdfファイルをレンダリングするには時間がかかりすぎます。
大きなPDFファイルの内容が表示されますが、下にスクロールするとブラウザ全体がハングアップします。
提案がありますか？
あなたがPDF.jsの古いバージョンを使用していることを、あなたのOPに要約すると、新しいバージョン
で試してみてくださいようにこれはそうです - あなたが質問に答えるか、との問題を抱えたPDFの例を提供しなかったので、誰も決定的な答えを出すことはできません。問題を調査するためにスニペットを設定するのは簡単だったので、これは残念です。
私は、あなたのPDFファイルの内容とpdfjの機能との間に不一致があると思われます。あなたのサンプルファイルがあれば、developers git,のバグを報告することができます。
以下は、一般的なブラウザに組み込まれているメインストリームのビルトインレンダリングエンジンを使用する理由を明らかにするために、PDFレンダリングエンジンの作成に関する問題の概要を説明したものです。
PDFのレンダリングは複雑な作業です。それをコンポーネント操作に分解することは可能ですが、多数のオプションを導入したPDF標準のいくつかのレベルがあります。あなたのPDFには、pdfjsでレンダリングの実装が誤っているもの、またはpdfjsがレンダリングしようとしたときに窒息するものが含まれている可能性があります。
背景：PDF形式は、同時に華麗かつ魔法の両方です。その移植性のために華麗ですが、内部の構造と保存メカニズムのために魔法をかけます。 HTMLのようなフレンドリーな「DOM」はありません。ポータブルな文書フォーマットを開発するために新たに始めたのであれば、私たちが選択するPDFではないでしょう。しかし、PDFは現在、あまりにも多くの勢いを捨ててしまう。
PDFファイルの内容を表示デバイスまたはプリンタにレンダリングするには、PDFを展開してコンポーネント（イメージ、フォーマット済みテキスト、ページ）を表示デバイスにレンダリングする必要があります。 HTML DOM操作の経験がある人なら誰でも直接聞こえるが、直接の比較はない。
PDFはvector-based graphics定義言語です。ほとんどの人が経験したであろう最も同等のものはSVGです。
PDFファイルに埋め込まれたイメージではないものは、連続した文字列ではなくx/y座標で圧縮されたテキストを除いて、ベクトルベースの出力です。
描画やレイアウトの指示は、ツリーのようなポインタを介してリンクされたセクション（ダイジェスト）で行われます。単純な上から下への読み込み&レンダリングプロセスはありません。 PDFには冗長セクションがあり、後で編集されますがまだ存在します。また、PDFファイルが高速なWeb表示用に設定されていない限り、表示中は、ファイルの表示方法を理解する前に、レンダリングエンジンがファイル全体の配信を待つ必要があります。ファーストウェブビューでは、ファイルストリームの最上部に「インデックス」セクションとページ1セクションが配置され、レンダリングエンジンが画面にできるだけ早く何かを出すことができます。
PDFを適切にサポートするには、PDFに含まれるものをレンダリングし、PDF標準に沿って完全にこれを行う必要があります。そうしないと、PDFビューアがクラッシュしたり、PDF全体をレンダリングできません。さまざまなAcrobatの標準レベル、および編集パッケージ（Word、Illustrator、InDesign）ベンダーがPDFファイルにチャッキングするショートカットや拡張機能を用意する必要があります。テキスト、図、レイヤー、サムネイルなどを表示することができます。
PDFでは、テキストはベクター描画命令またはHTMLファイルのようなフォントファイル内の文字への参照として格納できます。
色については、PDF仕様をお読みください。元のPDFプロデューサが使用することができる色空間オプションの配列があることがわかります。これらの一部は、エイリアンカラーメカニズムを使用するプリントデバイス用です。これらを画面上の合理的なデバイスカラーに解釈する必要があります。
そしてフォント。フォントは、サブセットに埋め込まれていても、埋め込まれていなくてもよい。レンダリングエンジンの実行時にPDFに記載されているフォントが存在しない場合は、使用する代替フォントを決定する必要があります。 PDFを忠実に保つためには、PDFで定義された縮尺でグリフを描画面にベクターグラフィックスとして認識させる必要があります。
PDFでレイヤー、スケーリング、回転機能を使用すると、htmlキャンバスを描画面として見ることになります。知っている人なら誰でも、キャンバスの世界では、キャンバスの強さと弱さの両方を表現するための機能はあなた自身であると言いますが、PDFのレンダリングでは絶対的なコントロールが必要なので、ほとんどの図書館はあなたに使ってください。時間を要し、バグの影響を受けやすい描画プリミティブを扱っていることを意味します。
おそらく最大の課題は、自分がしなければならないことの全範囲と範囲を理解することです。これは不可能ではないが、難しい。
この講義では、PDFレンダリングエンジンを書く上での課題について、要約するとPDFファイルを完全にレンダリングすることは非常に複雑な作業です。早期リリース段階で、PDF仕様のチャンクをサポートしないという点で、このような製品が非常に不便であると感じられるのは驚くことではありません。開発者にはあまり重視しないでください。彼らが目指しているターゲットは難しいです。開発者が支援を受け、プロジェクトにとどまる時間があれば、ある時点でPDF仕様のすべての機能が製品でカバーされる可能性があります。理想的には、サポートされていないPDF機能のリストを公開することで、ユーザーが潜在的な問題を認識できるようになりましたが、レンダリングやエンジンがクラッシュしたときにPDFファイルが奇妙に見えるようになるまで、
このPDFファイルのサイズはどれくらいですか？ – Justinas
150ページPDFファイル –
とMBサイズ？ – Justinas