I am looking for some tool or library (.NET version will be perfect) I could use to convert some big PDF files (over 200MB) to TIFF in the product we are developing for our client.
I need tool I could call from the command line or a library that I could use in the .Net application.
I have tested ghostscript, and it works perfect but according to its license, we cannot use it.
Do you have any experience with free or commercial products we could use for it? Could you recommend something?
Thanks in advance!
As you explicitly ask for commercial software as well, callas pdfToolbox performs this task. I'm affiliated with this company / product so draw your own conclusions about quality / price. However, the software:
works perfectly on the command-line
exports to PNG, JPG or TIFF (or rasterized PDF)
exports to either grey, RGB or CMYK
supports smoothing and overprint preview (important when you're in graphic arts, likely less so if not)
is available on Mac OS X, Windows, Linux and Unix
Send me a private message if you want to know more.
Gnostice PDFOne .NET has a PDFDocument.SaveAsMultiPageTiff() method that you can use.
http://www.gnostice.com/nl_article.asp?id=215&t=Convert_A_Multi-Page_TIFF_To_PDF_Using_PDFOne_NET
Related
There are so many formats that intuitively are more bound to graphics: it could be vector graphics format such as SVG, various PNG, JPEG formats etc. Why PDF of them all has a dedicated library?
Note: this question is NOT opinion-based. I'm interested in the very reason for why PDF has such a central point in xOS. Give it a day to see.
My bonafides: I licensed my PDF viewer to Apple for Rhapsody and then the PDF library I wrote in Objective-C to Apple as the basis of CoreGraphics. I’ve written code for NeXT systems since 1988, and worked as a contractor for NeXT and Apple many times.
As Rob says, NeXTstep used Display Postscript (“DPS”), under license from Adobe. When Apple switched from “Classic” Mac OS to OS X, they absolutely didn’t want to keep paying Adobe the per-seat license for DPS each Mac it sold – it had been years since they’d agreed to pay a per-seat license to anyone for the Mac.
And, at the same time, DPS didn’t reflect modern graphics trends. It was a Turing-complete language and ran in its own process, and client apps would have to send inter-process messages to it, which meant expensive context switches and no direct sharing of buffers. (Also it broke down isolation between client processes.)
So the graphics team (led then by Peter Graffagnino) needed to replace DPS, but also not break all the existing NeXTstep apps. As it happened an engineer at Adobe (I believe it was originally Sam Streeper) had written a graphics language that was MUCH simpler than PostScript and wasn’t Turing complete, but still had most of the drawing conventions of PostScript. (Display PostScript was superset of PostScript, so any PostScript program runs in DPS.)
PDF was originally designed for PostScript-driven printers, because lots of PostScript programs (aka “print jobs”) ended up slurping down memory and processor time and often were just too big to work on any individual printer (RAM was expensive back then). Converting PostScript files to PDF made them process far more easily, and since PDF doesn’t have control flow you couldn’t, say, send the printer into an infinite loop. (Adobe processed PDF with a PostScript program they’d send to the printer as well.)
PDF was also an open standard, so with Apple writing their own implementation they didn’t have to pay Adobe anything to use it. PDF was fast and simple and free and had the exact same model because it was designed to run on PostScript printers.
So: Apple had to switch to a new graphics language for Mac OS X (née NeXTstep), and wanted one with the same semantics and Display PostScript so all their existing apps largely still worked.
So first they wrote the functional calls to CoreGraphics, implementing all the conventions of PostScript / PDF (eg: how clip paths work, how paths are filled if they self-overlap, resolution-independence, the state stack, etc). They rewrote all the existing high-level graphics functions (eg, NSRectFill()) so they were on top of CoreGraphics, so 99% of existing NeXTstep programs could switch from DPS to CG without modification. (By the late 1990s most NeXTstep programmers had realized dipping into DPS and trying to create effects by writing PostScript was pretty much always a bad idea, so we used the high-level calls.)
But the final missing piece was giving programs a format they could read and write to disk. In NeXTstep days we used both PostScript and Encapsulated PostScript, but the former was Right Out now. PDF was a natural fit (for the reasons outlined above) so they added reading and writing of PDF files.
Postscript (pun intended): The PDF code in CoreGraphics today is not what I licensed Apple — they used my code as more of a “working reference” and came up with their own APIs, since CoreGraphics couldn’t use Objective-C and my API was never really intended to be used by general programs.
The drawing model utilized by Quartz 2D is based on PDF specification.
It is widely stated that Quartz "uses PDF internally" (notably by Apple in their 2000 Macworld presentation and Quartz's early developer documentation), ... Quartz's internal imaging model correlates well with the PDF object graph, making it easy to output PDF to multiple devices.
https://en.wikipedia.org/wiki/Quartz_(graphics_layer)#Use_of_PDF
https://developer.apple.com/library/content/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_overview/dq_overview.html
Continuing Mahal Tertin's points, focusing on the drawing side, which isn't really PDF-centric but the history is interesting anyway (I'll get to the file format side below).
Quartz was developed before 1999, and was a fairly natural continuation of NeXT's use of Display Postscript and QuickDraw, which conceptually goes back to the Lisa and was used extensively on pre-OS X Macs.
SVG might have been a reasonable base, but work on it didn't even start until 1999. It was never in a position to the basis for OS X drawing. Even if it had come out a couple of years earlier, it would still have been an untested experimental format vs a established format that Apple already had extensive code and experience for.
When iOS came along, it inherited Core Graphics, which made development dramatically easier for OS X developers. Converting everything to an SVG DOM or the like would have made iOS much harder to migrate to. (I had complex custom views on OS X that I ported verbatim to iOS with the addition of one flip translation and a hacky #define to replace NSColor with UIColor.) It also made developing iOS much easier in the first place since Apple could reuse substantial existing code. Why replace the entire drawing system with another format? To what purpose?
Quartz/PDF/Postscript all have the concept of independent objects/layers that are composited together, and has lots of support for text and lines. This makes a lot of sense when you're building a windowing system and want to easily drag a window along the screen, overlapping other windows, and minimizing computation. PNG and JPEG are built to compress single, static images. They don't make any sense for this use. JPEG in particular would be a horrible way to try to manage a windowing system full of crisp, straight lines and text, exactly the things that JPEG hates.
So that's the drawing side (which isn't really PDF-centric anyway, but it answers why SVG DOM isn't the heart of Core Graphics), but why does PDF get its own framework and not PNG?
As a graphics format, PNG does get a lot of support in iOS (as opposed to OS X). iOS is highly optimized to display PNG and converting images to and from PNG is very easy in iOS. There really isn't a need for a PNGKit. What would it do beyond what's built into UIKit, where PNG and JPEG are given their own special handling right in UIImage (handling PDF doesn't get)?
PDFKit exists because PDF is complicated, and it addresses printing problems that the other formats don't (things like handling multiple pages; when was the last time someone mailed you an SVG Print document?) While it may seem that it's getting a lot of special support by getting its own framework, PDFKit isn't really very good and doesn't support a lot of more complicated PDF features. So while there is a long history of PDF inside of Core Graphics, PDF as a file format is actually pretty poorly supported by Apple IMO. (Compare PSPDFKit, which much more powerful, and a necessary addition for almost any app that uses PDF in a non-trivial way.)
I've been playing around with ImageResizer for a week or so now and am wondering if it's possible to output resized images with the same ICC profile embedded (and in the same colour space) as the source image, for example the Adobe 1998 colour space?
I intend to use ImageResizer as part of my company's workflow for thumbnailling our source images before our imaging dept looks at them for consistency, so the same colour profile is essential. Generation speed isn't too important as they will be cached once generated.
Can someone please tell me if ImageResizer is capable of this and which parts of the pipeline I would need to overload to achieve this?
Thanks.
ImageResizer targets the web, always produces images in the sRGB color space; browsers don't support ICC profiles, so we don't use them.
That said, you can certainly modify a few lines and get the result you want.
ImageResizer has 3 pipelines - GDI+ (the default), FreeImage, and WIC.
GDI+ does not support output profiles - at least not through System.Drawing.
FreeImage is supposed to have very good ICC profile support
WIC should have ICC profile support as well, but is likely to share bugs with GDI+ as both use the same codecs.
To make changes, go to the ImageResizer repository and click the 'fork' button.
When you clone your fork, be sure that you switch to the develop branch before making changes - otherwise your changes will not be compatible with the next major version.
You'll probably want to modify Plugins/FreeImage/FreeImageEncoder.cs. FreeImage documentation is in pdf form (yay!), so you'll probably want to scan that quickly to understand how it handles profiles.
When testing, make sure you enable the 3 FreeImage plugins by installing them and activating them via their command strings, &builder=freeimage will activate the full FreeImage pipeline, but &encoder=freeimage will just activate the encoder portion (useful if you want to edit the image with GDI+, but save via FreeImage).
You will likely also want to use the ignoreIcc=true command, so that you don't see sRGB values interpreted as Adobe RGB.
I have a project in which I am using a Raspberry Pi to print ticket to a thermal printer.
It is pretty much the same principle as in this video.
Tickets are generated from templates that may include text and images. Both text and images are dynamic, for example I may want to print the current time. I receive the template as a .psd from a designer and the thermal printer takes bitmap data. The Raspberry Pi communicates to the printer with a python library. Everything must be done locally as cloud access is not guaranteed. Performance is important.
I investigated several options:
Latex + ImageMagick
Webkit + Phantom.js
Pillow (Python Imaging Library), especially the module ImageDraw
The first option is not quite satisfying because Latex generates a pdf file and then ImageMagick is very slow to convert it to a .png.
The second option is seducing but if I am not mistaken, I would need to start a server locally.
The third option would be great because it will be pure python, but requires to build a basic typesetting system on top of PIL.
Has anyone been confronted to a similar problem ?
I am looking for an SDK for (roughly) the following capabilities regarding JPEG2000 files –
Decode and encode J2K files.
Decode to access individual elements (boxes, marker segments, image stream, etc.) of JPEG2000 images for inspection and potential alteration of texts and bits.
Encode (reconstruct) the JPEG2000 image with given elements.
This is all done from within C++ applications.
It must support 64-bit Redhat Linux OS.
It should be able to handle J2K (JPEG2000) files as large as 16GB i.e. 64-bit file address.
Please tell me of SDK's with the above capabilities that you know or have used in your projects. Also, hints on performance and licensing/pricing would be appreciated.
The best JPEG 2000 library is Kakadu: http://www.kakadusoftware.com/
No problems, Kakadu can handle raw codestreams (j2c) and file formatted codestreams (jp2)
Full codestream access and manipulation.
Not sure what you mean here, but if you mean to assemble components together or pieces of an image (i.e. like tiles.) yes, Kakadu is more than capable.
Yes, it's written in C++ so it will easily integrate with other C++ applications.
Yes, every major platform is supported.
Yes, 64bit addressing is supported.
Source: http://www.kakadusoftware.com/documents/Overview.txt
As for pricing and licensing model, it's a bit different for how you use it. Licenses start from $250USD for individual licenses, $500USD for evaluation licenses. See here for the most accurate details on licensing: http://www.kakadusoftware.com/index.php?option=com_content&task=blogcategory&id=6&Itemid=12
Kakadu is authored by David Taubman, one of the key contributors to the JPEG 2000 specification. If you need JPEG 2000 to do something more, he will be a great person to ask for help.
Another commercial library to do this is Accusoft Pictools.
We use it for Medical Imaging purposes.
It supports most known formats including jpeg2000 (.jp2).
https://www.accusoft.com/pictools.htm
Has complete libraries to be called from unmanaged code.
regards
Ari
I have to make a hardware project using a microcontroller, memory, screens, etc.
Is it possible to make an independent PDF / documents reader, which is capable of running on battery power?
Please note I don't want to use any technology which needs licensing. It must be all freeware readers, etc., and programing language can be assembly, C, Flash or any.
I have submitted proposal of PDF reader project (independent hardware). Many say it's impossible. What should I do?
Reading and displaying a PDF document is quite a "high level operation".
You should start with a microcontroller starter kit, with an ARM9 processor or something similar. Then install a Linux operating system on it, include a standard display driver and run an X server. Then you should be able to find a Linux based PDF reader with X drivers.
To 2nd another comment here, I would say that you're not going to to do this with a microcontroller, you're going to need to get some more powerful ARM CPU like an ARM9, Cortex-A8 or similar with a decent amount of RAM.
You'll probably need something that's capable of running Linux if you want to start with pieces of software that won't require writing quite a large volume of software from scratch.
Note that for commercial devices that are out there, including the Kindle, run Linux, and aren't based on a micrcontroller.
You might be best off getting something like a BeagleBoard, attach a display to that, and start from there with an X-based PDF viewer.