Regarding the usage of the loadDocument API

[YaoZhouZ]

Hello,

I'm very excited to use such a high-performance PDF preview library! I plan to integrate it into our enterprise project.

However, I've run into a few issues. Specifically, I couldn't find any documentation for the loadDocument API in the official docs, although I saw it being used in your examples.

In your provided examples, file selection and preview are handled via loaderProvider?.value?.openFileDialog(). For my use case, I need to load PDF documents directly from a URL, so I cannot use your file selection method.

I found that when I use loadDocument to load a second file, it causes two problems:

The text content of the document becomes unselectable.

It introduces rendering issues (as shown in my previous issue, where files overlap).

I will provide a video demonstrating this behavior. Could the author please help me resolve this?

This library is genuinely the most modern and best PDF library I've ever encountered!

[YaoZhouZ]

[YaoZhouZ]

test.mp4

[mpenndev]

I'm not sure if this would be better as a separate issue but I'm also encountering problems switching PDFs programmatically.

My issues might be specific to the React version.

First implementation was getting memory leaks, I presume from the engine not cleaning up documents when React components are unrendered.

I've tried some manual cleanup but I'm now getting out of bounds memory access errors.

Implementation:

const PDFViewer = ({ id }: PDFViewerProps) => {
    const { engine, isLoading: engineIsLoading } = usePdfiumEngine()
    const { provides, isLoading } = useLoaderCapability()

    const pdfRef = useRef<PdfDocumentObject | undefined>(undefined)

    // Does authenticated API request to get a Stream of the PDF from my server
    const { data, isLoading: isDownloading } = useSWRImmutable<BlobWithFilename>(myEndpointUrl)

    useEffect(() => {
        const run = async () => {
            const buffer = await data?.blob.arrayBuffer()

            if (buffer) {
                pdfRef.current = await provides?.loadDocument({
                    type: 'buffer',
                    pdfFile: {
                        id,
                        content: buffer,
                    },
                })
            }
        }

        run()

        // TODO: This isn't cleaning up properly, it seems to fix the memory leak but leads to out of bounds memory access
        // The easiest solution is to render a new engine instance each time, but that is slow and inefficient
        return () => {
            if (engine && pdfRef.current) {
                engine.closeDocument(pdfRef.current)
            }
        }
    }, [data, provides, id])

    if (engineIsLoading || isLoading || isDownloading) {
        return (<p>Loading...</p>)
    }

    return (
        <Viewport>
            <Scroller
                renderPage={({ width, height, pageIndex, scale }) => (
                    <div style={{ width, height }}>
                        <RenderLayer pageIndex={pageIndex} scale={scale} />
                    </div>
                )}
            />
        </Viewport>
    )
}

export default PDFViewer

This is a snippet of the error I now get, most times my component unrenders:

pdfium.wasm-01d59ee2:0xb189 Uncaught (in promise) RuntimeError: memory access out of bounds
at pdfium.wasm.std::__2::__tree<std::__2::__value_type<unsigned int, fxcrt::RetainPtr<CPDF_Object>>, std::__2::__map_value_compare<unsigned int, std::__2::__value_type<unsigned int, fxcrt::RetainPtr<CPDF_Object>>, std::__2::less, true>, std::__2::allocator<std::__2::__value_type<unsigned int, fxcrt::RetainPtr<CPDF_Object>>>>::destroy(std::__2::__tree_node<std::__2::__value_type<unsigned int, fxcrt::RetainPtr<CPDF_Object>>, void*>) (wasm://wasm/pdfium.wasm-01d59ee2:wasm-function[139]:0xb189)
at pdfium.wasm.std::__2::__tree<std::__2::__value_type<unsigned int, fxcrt::RetainPtr<CPDF_Object>>, std::__2::__map_value_compare<unsigned int, std::__2::__value_type<unsigned int, fxcrt::RetainPtr<CPDF_Object>>, std::__2::less, true>, std::__2::allocator<std::__2::__value_type<unsigned int, fxcrt::RetainPtr<CPDF_Object>>>>::destroy(std::__2::__tree_node<std::__2::__value_type<unsigned int, fxcrt::RetainPtr<CPDF_Object>>, void>*) (wasm://wasm/pdfium.wasm-01d59ee2:wasm-function[139]:0xb196)

[mpenndev]

I mentioned it here #217 (comment) but I can avoid these memory issues by rendering a new engine for each document which may or may not be the expected usage, I'm unsure.

[YaoZhouZ]

I am eagerly looking forward to a quick resolution for this issue, as the ability to load and switch files via URL is a critical requirement for my use case.

[nico1996it]

i think everybody is wondering the same, multiple questions about this topic

[bobsingor]

This is solved in #303

You can read about the new document manager here: https://www.embedpdf.com/docs/react/plugins/plugin-document-manager