PDFBox Rendering Layout Bug Fix
Budget / Salary€250–750
TypeFreelance project
LocationRemote
Posted2 hours ago
My application relies on Apache PDFBox for generating and displaying PDFs, but the current build renders pages with an incorrect layout— it renders over other components in user interface. I need a developer who knows the internals of PDFBox, its Renderer (PDPageContentStream, PageDrawer, etc.), and the Java graphics pipeline to identify and patch the root cause of this layout problem. The problems is related to PDFRenderer.renderPageToGraphics -method. It may be reproduced by adding a JSplitpane into a JFrame, then rendering to the left component. It renders over the right component, too. It is wrong. It also relates to PageDrawer and its setClip() -method. Even if we apply the initial clip, it still renders wrong, see code below.
AffineTransform at = graphics.getTransform();
at.invert();
Shape shape = at.createTransformedShape(initialClip);
graphics.setClip(shape);
Moreover, if we render, for instance a rectangle after rendering the pdf, the rectangle will be below the pdf. So, it cannot bee seen.
Scope
• Reproduce the issue consistently with a sample PDF I will supply.
• Locate the fault inside the rendering component (not text extraction or encryption—just the core page-drawing logic).
• Deliver a clean, well-commented fix or workaround that compiles against the version 2.0.36 PDFBox release.
• Provide a brief summary of the changes and a test case proving that the layout now matches Adobe Reader output pixel-for-pixel.
Acceptance criteria
• No layout shifts when the patched library renders my sample documents.
• All existing unit tests in PDFBox continue to pass; your patch must not introduce regressions.
• The solution is delivered as a pull-request-ready patch or a forked repo with clear commit history.
If you have tackled PDFBox bugs before or contributed to its GitHub project, please mention it.
AffineTransform at = graphics.getTransform();
at.invert();
Shape shape = at.createTransformedShape(initialClip);
graphics.setClip(shape);
Moreover, if we render, for instance a rectangle after rendering the pdf, the rectangle will be below the pdf. So, it cannot bee seen.
Scope
• Reproduce the issue consistently with a sample PDF I will supply.
• Locate the fault inside the rendering component (not text extraction or encryption—just the core page-drawing logic).
• Deliver a clean, well-commented fix or workaround that compiles against the version 2.0.36 PDFBox release.
• Provide a brief summary of the changes and a test case proving that the layout now matches Adobe Reader output pixel-for-pixel.
Acceptance criteria
• No layout shifts when the patched library renders my sample documents.
• All existing unit tests in PDFBox continue to pass; your patch must not introduce regressions.
• The solution is delivered as a pull-request-ready patch or a forked repo with clear commit history.
If you have tackled PDFBox bugs before or contributed to its GitHub project, please mention it.
Apply on Freelancer →
Project sourced from Freelancer.com. Applications happen directly on the original platform — we never collect your data.