Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.0.0
-
None
-
None
Description
We want to refactor the core pdfbox module packages so that there is no longer a dependency on AWT. Any packages which are moved outside the of the org.apache.pdfbox module need to be re-packaged appropriately (e.g. org.apache.pdfbox.rendering).
AWT code could live in "pdfbox-rendering" but we need to think carefully about how to do this because, e.g. some of the Filters use AWT, as does FontBox.
What are the use cases for modularisation, currently we have:
- Android
- Google App Engine
Android seems to have some support for AWT and ImageIO, can somebody in the know provide more information?
Google App Engine seems to blacklist ImageIO and AWT classes. Is there a strong desire to support it?
Also, as Fred discussed on the mailing list the "util" package functionality is shared across numerous parts of the code but most classes are either used only from one package or can be replaced with new Java 1.6 constructs. By the end of this refactoring the pdfbox.util package should be mostly empty, containing only a handful of true utility classes.
Attachments
Issue Links
- incorporates
-
PDFBOX-586 Text Extraction on Android
- Closed
-
PDFBOX-1027 Modifications to permit use of PDFBOX on Google App Engine
- Closed
Revision 1574811 refactors PDFImageWriter and RenderUtil and creates a new "rendering" package as a first step towards isolating AWT code.