This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I am writing a program that converts svg file to pdf and this has to happen under 50ms. I tried everything - batik,iText,inkscape(i used it with Runtime.getRuntime.exec("/usr/bin/inskcape /folder/file.svg --export-pdf=/folder/filepdf.pdf")) but everything is more than 50ms! Do you know if there is a way to convert svg to pdf under 50ms? Thanks in advance
I don't think there are any constrain. When convert svg to pdf it takes around 300ms and when i do it with batik is around 220ms. I make this convertion in a servlet and run it under glassfish(i use it because another part of my program is using jms and mdbs).
I would expect the time to do the transformation would be proportional to the size of the SVG input, or worse. In other words, at least O(N). Your assignment appears to be to find an O(1) algorithm to do the transformation. Such a thing is unlikely to exist.
Joined: Jan 05, 2012
Thank you for the answer. I also think that conversion under 50ms is not possible.
Tsvetelina Borisova wrote:I don't think there are any constrain. When convert svg to pdf it takes around 300ms and when i do it with batik is around 220ms. I make this convertion in a servlet and run it under glassfish(i use it because another part of my program is using jms and mdbs).
You know that old rule... the easiest way to solve a software problem is to throw hardware at it. I figure the disk is probably the slowest component, so, if it is a network disk, then consider a local disk. If it is a local disk, but spinning media, then consider an SSD. Or better yet, consider throwing a ram disk at the problem. And of course, using a more powerful processor always helps...
PS.... this response is partly in jest, but also partly serious.
Tsvetelina Borisova wrote:Thank you for the answer. I also think that conversion under 50ms is not possible.
One test that might be worthwhile is to pick the smallest possible valid file you can think of (perhaps a single word), and run that through the products you're investigating. That at least may give you some idea of the overhead they are imposing. I think I'd also do the test for one conversion, and many, all on small files (perhaps in the same directory), to work out if there's any extra overhead in doing single 'random' conversions.
If you can't convert even a tiny file in under 50ms. I suspect you'll have ammunition to go back to your tutor with.
Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
I'm not to familiar with PDF, but can the rendering be parallelized? Just throwing out couple of ideas
a) PDF format support layers, doesn't it? and SVG supports it too. Suppose you could convert each layer in it;s own thread, and put them all together in the end.
b) Or you could divide the vectors into groups, and rasterize the groups in parallel and in the end merge the raster images together. Merging images together is not time consuming. It's basically ORing all the pixels together which is a O(1) operation
ETA: oh shoot. Shows how much I know about PDF :p Just googled it a bit and PDF has native support for vector graphics. That opens up another option:- Find an API that support Vector graphics in PDF. Directly convert vectors read from the SVG file to vectors in PDF. It should be much faster than rasterizing the graphics.
Joined: Sep 21, 2011
Given that even the simplest of documents -one geometric shape on one page- doesn't fulfill the timing requirements, I don't see how parallelizing would help.