Today I got an email from Elbert Pol,

Just let you know i compile Diffpdf to OS/2 using Qt v4.7.3

Get it @ ftp://ftp.netlabs.org/pub/qtapps/diffpdf-2.1.2-os2.zip

I have no OS/2, so I have not tried it yet, and if you have question, please leave a message, and I will let Elbert Pol know.

btw, Diffpdf windows static version 2.1.2 also released with minor changes.

Let’s have a look these three frameworks,

Vert.x is an event driven application framework that runs on the JVM – a run-time with real concurrency and unrivalled performance. Vert.x then exposes the API in Ruby, Java, Groovy, JavaScript and Python. So you choose what language you want to use. Scala and Clojure support is on the roadmap too.

Node.js is a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.

And here are some useful comparison articles,

• Vert.x: Why the JVM May Put Node.js on the Ropes

	Vert.x (Polyglot JVM)	Node.js (Javascript)	Netty (Java)	EventMachine (Ruby)	Twisted (Python)	LibEvent (C)
Language Type	Dynamic or Static	Dynamic	Static	Dynamic	Dynamic	Static
Speed of Development	Fast	Fast	Slow	Fast	Fast	Slow
Synchronous Threading Support	Great	None	Great	Poor	Poor	Good
Library Threadsafety	Good	N/A	Good	Poor	Poor	Good
Backed By	VMware	Joyent	Redhat	N/A	N/A	N/A

• Vert.x vs node.js simple HTTP benchmarks
  1. Vert.x is much faster than Node.js when reading the same file from the filesystem more than once. Neither Vert.x nor the JVM is doing any explicit caching, so this is most likely due to the OS caching it (memory mapped files?). In a webserver-type app the same file is likely to be served many times so this is pretty significant
  2. Node.js doesn’t appear to scale particularly well using the `cluster` module. The advice from the node.js folks is not to use it (for now). This leaves node with no out-of-the-box way to scale across multiple cores 
  3. Many of the out of the box load testing tools don’t appear to pipeline very much. The Vert.x results are dramatically better when there’s a high degree of pipelining going on.
  4. Java on the JVM is extremely fast. No surprises there  But what is very encouraging is how the other JVM langs held up – in particular Rhino held up very well against V8 

Yesterday, I got a comment on Jbig2

Hi Steven,
thanks for the port to windows. It works very good, produces small pdf-file sizes. Only one strange thing happens. The generate pdf files have a huge page-size. For example if I process A4-size pages (29.7×20.9cm) @400dpi tiff or png the pdf file size is 164.9×116.6 cm.
Is it possible to fix this by the python pdf.py or is jbig2.exe responible for this?
Thanks
Armin

after check the last version pdf.py, I notice it uses a default DPI(600). Images has different DPI, so if you want to use pdf.py, you need always modify it, it is not a good solution.

Then I check the source code of jbig, and found in jbig2_page_info structure ,

struct jbig2_page_info {
  u32 width;
  u32 height;
  u32 xres;
  u32 yres;
...

we can get xres and yres, so we can directly use xres and yres to generated proper page size.

and here is the patch file

btw, you can also download the last version jbig2 from here.

P.S.

Armin became the first user, and here is his response,

Hi Steven,
thank you very much for your quick response, and the new pdf.py
which works perfect. (I checked it with my 400dpi page scans.
the pdf page size is now of the same size as the scans)

Thank you so much,
Greetings from rainy Germany :-)

Armin