Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
I tried to get the IcePDF-based version to work, but ran into exceptions when running it. Am I making a mistake, or was this version abandoned in favor of the PDFRenderer-based version before it ever worked?
I made some efforts to get the IcePDF Version running until I found out, that the public (open source) version of IcePDF does not support embedded FONTs in PDF files.
So the open source version of IcePDF always uses AWT-Fonts to replace the embedded Fonts. Because in Android there are no AWT-Fonts we do not get very much to see.
As long as the open source release of ICE-PDF does not support embedded FONTs I will not work on this branch.
OTOH the Android Canvas and its drawText method can provide a lot of attributes with the Paint object, including text size and style. Don't you think this would offer a means of rendering text without having to use embedded or AWT fonts?
yes, it would be possible.
Android does not have the standard fonts (arial/times/courier).
TTFs can be embedded as resources, as long as they are free :)
But in my opinion the drawbacks are too big.
Look at the documents opened with the open source Ice-PDF renderer.
Most of them look somehow clumsy, because font substitution is never as accurate as the real fonts.
An advantage of font substitution could be a better performance in rendering. But this should option and not a restriction.
Currently I am working on the pdf-renderer port and it works quite good (somewhat slow, but this is not in focus now). I have added support for PDF-1.5 documents (Compressed Cross-References). So most of the documents can be opened now. The User Manual can be opened and only some graphics are not visible.
What are your interestes about Ice-PDF?
There are two aspects why I tend to prefer IcePDF:
a) According to some profiling which I have done, it is especially the font handling that makes the PDFRenderer so slow. Therefore rendering of a page takes (at least on my machine and emulator) about 10s - this is probably unacceptable for any user.
b) I am looking for a PDF library that does not have the restrictions of the (L)GPL. IcePDF is licensed under MPL which would allow me to create a viewer component on top of the library and keep its source code closed.
yes, the rendering performance is bad. I did not analyze how much the font handling takes. The PDF Viewer is still in status Alpha, because there are still display bugs. When most documents can be shown correct the next step will be to enhance performance and usability. Current focus is on the rendering engine itself.
I am not a lawyer, but I thought that you can use a library under LGPL without the need to publish the sources which are using the library.
Only changes to the library itself have to be open source again.
I think the business model of IcePDF is to sell the font-rendering engine. :-)
Please don't see my comments regarding the performance as any kind of critique to your code. In fact I think you did a great job in porting the library from AWT/Swing to Android. The low performance is more due to Android still not offering a JIT plus that of course mobile devices have slower CPUs than desktop systems.
Regarding the license, AFAIK LGPL does not require you to publish the sources if the library is found on the system and used from there, but it requires you to publish the code e.g. in the case of a Java application where the "library" sources are compiled into the code and then are part of the application. IANAL but I think the MPL does exactly what you mentioned above and would not require publishing of anything but modified library code if compiled into the application.
Unter http://www.gnu.org/licenses/lgpl-java.html findest Du übrigens den Artikel, aus dem ich die Informationen zur LGPL mit Java her habe.
So the main problem is, that in Android APKs you can not reference external JAR files?
Indeed, if I knew how to use an external jar file _and_ if a jar file with the Android PDF library would exist (which currently is not yet the case, but that would be probably be the easier part) then the LGPL-based PDFRenderer would be more attractive.
I will take a look at this issue (how to use external jars).
To create a jar file will not be to difficult. :)
I took a look at this issue (how to use external jars).
I made a proof of concept how to include a library and allow replacing it with a newer instance of this lib if it is found on the sdcard.
The zipped projects are in the project file releases as .
The details can be found there.
**The contained projects:**
* *LgplLibInterfaces:* the interfaces visible to all implementations
* *LgplLibImplementationIntern:* the internally used implementation (v0.9) which is used if there is no lib found on the sdcard
* *ClosedSource:* the not published source code which uses LgplLibInterface.jar und LgplLibImplementationIntern.jar
* *LgplLibImpl1:* an open source implementation (v1.0) different from the internally used but implementing the same interfaces
* *LgplLibImpl2:* another open source implementation (v2.0) different from the internally used but implementing the same interfaces
* *OpenSourceLib:* An Android-Project to convert the LgplLibImplX.jar into OpenSourceLib.apk
* *interfaces:* this project is needed to separate the interfaces from the implementation. OpenSourceLib references this project, so the Interfaces are known but not compiled into the apk
**How it works:**
ClosedSource includes the LgplLibInterfaces.jar and LgplLibImplIntern.jar.
On Startup a check for the existence of the file "/sdcard/runtimelib/OpenSourceLib.apk" is done. If this file exists a DexClassLoader is instantiated to load the MainFactory Class which implements IMainFactory provided by LgplLibInterfaces.jar
If no file is found the intern MainFactory (also implementing IMainFactory) is used.
The rest is straight forward. All Instances are referenced as Interfaces visible to all implementations. Beside the MainFactory no Class is directly instantiated.
Starting ClosedSource starts the Activity with the Message
Compiling OpenSourceLib with LgplLibImpl1.jar and copying OpenSourceLib.apk into the folder "/sdcard/runtimelib".
Starting ClosedSource (without recompiling) gives:
Compiling OpenSourceLib with LgplLibImpl2.jar and copying OpenSourceLib.apk into the folder "/sdcard/runtimelib".
Starting ClosedSource (without recompiling) gives:
Deleting OpenSourceLib.apk from the /sdcard/runtimelib again gives
So it is possible to replace the delivered Implementation for which the sources can be published with any newer version by copying the lib into a predefined path on the sdcard.
There are some restrictions because of the ClassLoader issues. It is not allowed to define the same class in the internally and the external implementation. This is ensured by using another package name. The Interfaces are only delivered with the ClosedSource.
The ClosedSource is runnable without a sdcard, because the LgplLibIntern.jar is included.
With some more ClassLoader acrobatic a solution allowing duplicate Classes in the intern and extern library might be possible (perhaps putting the intern lib into the raw-resources and loading them via URLClassLoader with a handler for reading the stream for the resources).
Thanks, I'll give it a try.