All committers have signed the CLA.

Please create a feature request issue.
PRs are the result of issue discussions.
Thank you!

This is a nice idea. It could also clear the way for writing to stdout, for piped processing. I regularly use an operation of the form pdfcpu | jq | pdfcpu, but of course at the moment it creates temp files.

What Problem Does WritableFS Solve?

The core idea is abstracting where extracted PDF content gets written. Instead of hardcoding filesystem operations, the PDF extraction logic delegates writing to an interface (WritableFS). This enables:

1. Writing to disk (via OsFS).
2. Writing to memory (via MemFS, useful for tests).
3. Writing to stdout or pipes (see below).
4. Future backends (e.g., cloud storage, ZIP files, databases).

Example

1. Support for Pipes/Stdout (Your Example)

The comment you referenced highlights a real pain point: temporary files break clean piping (e.g., pdfcpu | jq | pdfcpu). With WritableFS, you could add a StdoutFS implementation:

type StdoutFS struct{} // Implements WritableFS

func (s *StdoutFS) WriteFile(name string, data []byte, _ fs.FileMode) error {
    _, err := os.Stdout.Write(data)
    return err
}

// Usage: ExtractContentFS(pdfData, &StdoutFS{}, ...) 

Now, the extracted PDF content streams directly to stdout—no temp files needed. This fits Unix-style pipelines perfectly.

2. Testability Without I/O Overhead

MemFS lets you verify what would be written without touching the disk:

func TestExtractContent(t *testing.T) {
    memFS := NewMemFS()
    err := ExtractContentFS(pdfReader, memFS, []string{"1"}, nil)
    // Check memFS.files["1_123.txt"] contains expected data
}

• Faster tests: No filesystem cleanup.
• More reliable: No permission/disk space issues.

3. Swappable Storage Backends

The same extraction logic works across backends. For example, to add S3 support:

type S3FS struct { Bucket string }

func (s *S3FS) WriteFile(name string, data []byte, _ fs.FileMode) error {
    return s3.Upload(s.Bucket, name, data)
}

No changes to ExtractContentFS are needed—just pass S3FS instead of OsFS.

4. Consistent Directory Handling

Both OsFS and MemFS:

• Normalize paths (e.g., clean/../path → path).
• Auto-create parent directories (no "directory not found" errors).
• Respect file permissions (even if just in-memory for tests).

Why This Design Matters

• Separation of concerns: PDF extraction doesn’t care where data goes.
• Unix philosophy: Enable pipes by supporting stdout (via StdoutFS).
• Future-proof: New storage backends don’t require refactoring.

For your specific use case (avoiding temp files in pipes), the missing piece is a StdoutFS implementation—which would be trivial to add thanks to WritableFS. The interface makes this explicitly possible without hacks.

The only thing is that am not sure if _ fs.FileMode is even needed