Pdfjs Bundle Laravel Package

Getting Started

This is a Symfony2 bundle, not a Laravel package — there is no service provider, no facade, no config publish. As a Laravel developer, the realistic starting point is to treat the repository as a source of PDF.js viewer assets, not as an installable dependency.

1. Do not composer require it into a Laravel app. The bundle targets Symfony 2.x and depends on the Symfony2 kernel/bundle system, which Laravel does not provide.
2. Clone or download the repo and look first at:
   • Resources/public/ — the compiled PDF.js viewer (viewer.html, viewer.js, pdf.js, pdf.worker.js, cmaps/, images/).
   • Resources/views/ — the Twig template that shows how the bundle embeds the viewer (typically an <iframe> pointing at viewer.html?file=...).
   • SalvaPdfJsBundle.php / DependencyInjection/ — confirms there is no Laravel-relevant glue; skip these.
3. Copy the viewer assets into public/vendor/pdfjs/ in your Laravel project. Preserve directory structure (the worker and cmaps must resolve relative to viewer.html).
4. First use case: a Blade view that renders <iframe src="/vendor/pdfjs/web/viewer.html?file={{ urlencode($pdfUrl) }}">. That is the entire day-to-day pattern the bundle was providing, minus the Symfony wrapper.

If your real goal is just "show a PDF in a Laravel app," skip this package entirely and use npm i pdfjs-dist (or a Blade wrapper around the CDN build). This bundle is a 2013-era snapshot; the upstream PDF.js has moved on substantially.

Implementation Patterns

Asset extraction pattern (the only viable one here). Treat the repo as a static asset bundle. Copy Resources/public/* into public/vendor/pdfjs/, then serve via an iframe or pdfjsLib in a Blade-injected script.

Streaming protected PDFs. The viewer's ?file= parameter needs a URL the browser can fetch. For private documents, add a Laravel route that streams the file with proper headers:

Route::get('/documents/{document}/stream', function (Document $document) {
    abort_unless(auth()->user()->can('view', $document), 403);
    return response()->file(Storage::path($document->path), [
        'Content-Type' => 'application/pdf',
        'Accept-Ranges' => 'bytes',
    ]);
})->middleware(['auth']);

Then point the viewer at viewer.html?file=/documents/42/stream. Range support matters for the viewer's lazy loading; response()->file() handles it better than response()->download().

Blade component wrapper. Wrap the iframe so views stay readable:

{{-- resources/views/components/pdf-viewer.blade.php --}}
@props(['src', 'height' => '800px'])
<iframe
    src="{{ asset('vendor/pdfjs/web/viewer.html') }}?file={{ urlencode($src) }}"
    style="width:100%;height:{{ $height }};border:0"
    title="PDF viewer"></iframe>

Configurable worker path. If you go the pdfjs-dist route later, point the worker explicitly:

pdfjsLib.GlobalWorkerOptions.workerSrc = '/vendor/pdfjs/build/pdf.worker.min.js';

Migration path. If you find any actual Symfony service this bundle registers (it's minimal — mostly a Twig namespace), replicate it as a Laravel view namespace or a small helper class. Expect the total value to be one or two lines of Twig.

Gotchas and Tips

• Framework mismatch is the headline gotcha. No auto-discovery, no config/pdfjs.php, no artisan commands. Any Symfony-specific wiring in DependencyInjection/ is dead weight in Laravel.
• Version rot. The bundled PDF.js is years behind. Expect missing features (signatures, forms, annotations), and known CVEs in old PDF.js releases. Do not expose this to untrusted PDFs in production without upgrading to a current pdfjs-dist.
• Worker and cmap paths are relative. If you move viewer.html or serve it under a Blade route, the viewer will fail to load pdf.worker.js and cmaps/ — usually seen as "The PDF file is corrupted" or missing glyphs. Keep the whole web/ directory intact.
• ?file= needs URL encoding. Blade's urlencode() or rawurlencode() for storage-backed or signed URLs; otherwise query strings on signed URLs break the viewer's fetch.
• CORS / range requests. The viewer issues Range requests. If you serve files through a controller, ensure your response allows ranges and does not strip Accept-Ranges. Signed S3 URLs work; a naive Response::make(file_get_contents(...)) does not.
• CSP. Default Laravel doesn't ship a strict CSP, but if you add one the viewer needs script-src, worker-src blob:, and frame-src allowances. The worker is loaded as a same-origin script, so keep it under your own domain.
• Licensing. The bundle is MIT; the embedded PDF.js is Apache 2.0. Keep the LICENSE and PDF.js header files when you vendor the assets. If you strip them, you're non-compliant.
• Debugging. Open the browser console inside the iframe — most failures (worker 404, 401 from a stream route, CORS) surface there, not in laravel.log. Test with the browser devtools network tab filtered to pdf.worker.js first.
• Extension points are effectively zero for Laravel. The honest leverage is: delete the Symfony scaffolding, keep the assets, upgrade to a current PDF.js, and wrap it in a Blade component. Any further "integration" is a fork.
• Bottom line: 3 stars, 0 dependents, and Symfony2-only. For a Laravel day-to-day workflow, treat it as a reference implementation you copy from once, not a package you install or depend on.