Can main module openpdf be modularized further?

[gnahraf]

Hi everyone,

Wondering whether the main module openpdf can be (in principle) broken up into smaller modules (jar files) for my more narrow use case..

In my application, there's no need for a parser (I'm imagining), since I directly invoke the library's API methods to create the PDF file. So, naively skimming the code, it seems the packages com.lowagie.text.xml.*, com.lowagie.text.html.* might be unneeded in my use case. I'm not even sure these packages contribute much to the overall byte size of application code, but any way to shave some bytes (2MB) would be very cool. Am I reading the situation right? Or should I not even try?

~ Babak

[asturio]

I don't know if it is a big win. Removing the classes from xml and html would make the jar about 100kb smaller.

And probably if we split the jar, the parser code would only be one of the aspects, that can be separated.

[gnahraf]

I don't know if it is a big win ..100kB smaller

Sounds right: probably not a big win. But..

if we split the jar, the parser code would only be one of the aspects, that can be separated

..yes, the parser is what jumps out to a casual observer/user such as myself.

I imagine if one only wishes to write PDF docs (not read), it might be possible organize things so that you only need (pick n choose from) a smaller subset of the overall library. (On the read-path, you don't know what the PDF contains ahead of time, so you typically need "fuller" capabilities.) So taking the write-path example, what else besides parser code could conceivably be modularized? (I believe fonts are already packaged modularly, no?)

[asturio]

As this discussion is quite old, an there is not many interest on it, I think there wont be further modularization in near future.