Mark Storer

Greenhorn
+ Follow
since Nov 02, 2010
Merit badge: grant badges
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
2
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Mark Storer

Apologies for the confusion.

iText in fact has two separate licenses.

1) AGPL, not exactly suitable for commercial use.

2) Commercial license, which costs about what you'd expect given iText's feature set.

Lester Burnham wrote:... the bottom line of which is that the AGPL version of iText is a complete non-starter for just about any business application.



The AGPL version of iText is equivalent to any other commercial PDF library for just about any business application (with a comparable feature set, and you get the source for free which costs Much More for other libraries). Nice try though.

Or you can stick with the pre-AGPL version, 2.1.7.
The biggest barrier to Java in terms of high performance games is the garbage collector. You never know when it will start[*] and it can eat several tenths of a second every time it does... at which point you can kiss your frame rate goodbye.

As far as examples goes, the only one that springs to mind is Puzzle Pirates. It's a 2D puzzle-based MMO. Quite a bit of fun, though not exactly cutting edge technology.


[*] The GC can start every time an object is created. You have to pre-allocate pretty much everything, then work hard to avoid all the cases where you might allocate something without realizing it.

There's a pretty good video intro to the topic published under the Google IO series (from their Android Development conference):

http://developer.android.com/videos/index.html#v=U4Bk5rmIpic

And the 2010 edition:

http://developer.android.com/videos/index.html#v=7-62tRHLcHk

The game engine he developed is available in source at, and is built around OpenGL-ES (their embedded version, the one you'll find on Androids and similar devices).


12 years ago

Bruno Lowagie wrote:...



The short version:

Yes.

Under the AGPL, anyone with access to the program's output needs to also have access to the source.
Cardiff.com:
We use iText to generate and manipulate PDF forms (AcroForms) in our LiquidOffice (soon to be rechristened "Autonomy Process Automation") product.

The 'other team' here uses iTextSharp to a lesser extent in TeleForm, though I'm not familiar with the particulars. I think it's mostly just to wrap and unwrap TIFFs in/from PDF for scanning purposes. They come by my cube with questions from time to time.
Hello everyone. I'm another iText guy... I've been working with PDF in general for >13 years now (wheeze). Over the last several years, I've been using iText almost exclusively and was made a committer a couple years ago.

I started working for a company called DigiDox in Grand Rapids, Michigan... an "all things PDF" production shop that was getting its in-house tools ready to be sold to the general public. We were bought by Adobe (as their only subsidiary, they had previously always brought groups like ours "in house"), sold to ourselves by Adobe under the name "Audience One", bought by Cardiff Software in Cardiff By The Sea, California, which was bought by Verity (Bay Area), which was bought by Autonomy(UK).

I'm the only DigiDox-er left, one of two A1'ers, and a couple dozen Cardiffians.

I started writing Acrobat plugins (C/C++) for Digidox. When Adobe picked us up (briefly), and then in A1 and Cardiff, I worked with "Headless Acrobat" AKA the PDFL (C/C++ again). In Cardiff/Verity I wrote my own Java PDF library to fill in form data, worked with the PDFL, and with an API-clone we replaced it with called PDFLib by Zeon. Somewhere in the Cardiff/Verity time-frame I came across iText, pitched my own PDF library, and rewrote a fair portion of iText's field rendering/flattening code for my own nefarious ends, submitting my changes back to the trunk in One Huge Slab.

NOTE: I don't recommend submitting patches as an outsider to Open Source projects in Huge Slabs. In my (one) experience, the owners stick it on a back shelf until your code is dated enough to need an overhaul and you end up babysitting your own fork. Smaller patches are good until they to trust you enough to make you a committer, at which point you can go hog wild... just don't break the build. That doesn't go over so well either.

At Cardiff/Verity/Autonomy, I use iText to create and manipulate PDF forms (AcroForms to be precise). I also do odd jobs on the side using iText from time to time.

Rob Hunter wrote:Can I generate a PDF from an existing HTML file or pretty much create a PDF from scratch using iText?



Both, plus quite a bit more.

iText's HTML->PDF conversion isn't great (CSS support is a bit spotty, but it's been getting some attention lately), but is quite functional. OTOH, the original goal of iText was to generate documents (in HTML, PDF, or RTF). It has since evolved into a more general PDF library (create, manipulate, encrypt, sign, fold, spindle, mutilate), but it is still very much a PDF generator.

Kuba Zygmunt wrote:Hi Bruno

I know that merging pdfs is possible using iText, for example using PdfCopy class. However I got 100ish pdfs based on the one template ( they got the same graphics, just different wording )

Is it possible, during merging, to copy images once and then use references to those images later on ?



I believe PdfSmartCopy will take care of that for you... let me check. Aha! It does indeed. It builds MD5 hashes of the streams it encounters (fonts, images, content streams) and compares them based on the hash and then the actual bytes.

PdfSmartCopy uses more memory on account of the caching it does for these comparisons, but the resulting PDFs will be smaller... in your case much smaller.
Prior to iText 5.x, we maintained compatibility with Java 1.4.

Now we're compiling against Java 1.5. The only real change I'm aware of regarding language version is the use of generics. Type safety is your friend.

There have been quite a few other changes (package names, license, various improvements/bug fixes), but as far as language level goes? Generics.

I'm not aware of any plans to move to 1.6. As Bruno pointed out in another thread, there was quite a hue and cry when we dropped 1.4 compatibility, so moving away from 1.5 doesn't seem likely in the near term.