lmemsm | Entries tagged with pdf

This is a list of tips for converting and working with and printing documents and photos.

I'm out of black ink but still have color. I need something printed now and don't have time to buy another ink cartridge.

This trick converts the black (rgb 0x000000) colors in a graphic to blue (rgb 0x0000FF), so I can print with the color cartridge:

convert original.png -fuzz 25% -fill "rgb(0,0,255)" -opaque "rgb(0,0,0)" new.png

I need to edit a PDF file and send it to someone, but I don't want to print it out, make the changes to the printed copy and scan it back in. I'd like a paperless way to make my changes.

If the document is in PDF format, use Inkscape (or InkscapePortable). Open the PDF file. Be sure to select Poppler/Cairo import under Import Settings. Then, you can export it as a graphic file a page at a time.

You can edit a page in Inkscape itself or output it as a graphic file and edit it in another graphics editor. Export each page you need as a separate graphic using Inkscape. When you're ready to combine them and create a new PDF with the contents and your changes, use wkhtmltopdf.

Create a simple html file similar to this:

<html>

<body>

</body>

</html>

Add an img tag for each graphic of a page that you want to output and make sure the name of the corresponding graphic file is given. Separate each graphic with a page break command as shown in the example.

Then convert the document to PDF from HTML:

wkhtmltopdf --enable-local-file-access document.html document.pdf

I need to upload a graphics file and send it to someone, but the application I'm uploading to is complaining that the graphic is too big.

You can use ImageMagick to resize an image in a variety of ways.

You can decrease the size of the image:

convert original.png -resize 50% new.png

You can resize the image to specific dimensions:

convert original.png -resize 64x64 new.png

How do I find out the size of an image so I can resize to a specific bit length and bit width?

Use ImageMagick's identify program:

identify original.png

GraphicsMagick is a fork of ImageMagick. The same tips work with GraphicsMagick. The only difference is the syntax. You need to run the gm program instead of separate programs like convert and identify. So add gm in front of any ImageMagick commands. For instance:

gm identify original.png

I'm still looking for lightweight alternatives to work with and display Postscript or SVG files. I've previously compiled some of the information I've found on PDF and Postscript related programs here: https://lmemsm.dreamwidth.org/3702.html As mentioned, programs such as abcm2ps, lcal, pcal and others output to Postscript. So, I wanted to find a lightweight way to view the output. The abcm2ps program can also output to SVG. One thought was to convert Postscript or SVG to PDF and view the files with mupdf. So, far I haven't found a solution I've been happy with.

I wanted to avoid heavyweight programs and dependencies such as Ghostscript and librsvg. I've been using nanosvg for SVG files. There's an example svgview utility that comes with it. SDL2_img now supports SVG using nanosvg, so you can load and view images that way. I often use picaxo for quick image viewing and since it uses SDL2_img, it's able to support display of some SVG files. I've also been experimenting with an older version of mupdf that was released under a GPLv3 license. Along with adding cbr support (thanks to a FLOSS library from sumatrapdf), I added SVG support using nanosvg. I haven't tried the latest release of mupdf, but I did try a version a few years ago and nanosvg did a better job of handling SVG files than the mupdf code at the time.

I recently found an interesting lightweight SVG to PDF converter than uses nanosvg and libharu. Thought it might be worth checking out. It's called svgtopdf: https://github.com/MichaelMorozIQDirect/svgtopdf There's also a fork with some improvements at: https://github.com/Erroneous1/svgtopdf/tree/improvement/CurveTo As in the other solutions I've tried, it works well for some SVG examples but not others. I thought it was a very clever idea though. Biggest drawback with the program is that there's no information on licensing. I can't tell whether it would qualify as a FLOSS program or not. Would be nice if the author clarified the situation. It's written for Windows, but I believe it would be fairly easy to port to other operating systems.

I haven't found the solution I've been looking for, but trying svgtopdf did give me an excuse to update my libharu build scripts. I've switched them from using cmake to using CDetect, pkgconf and make. The library builds and works quite well. Haven't tracked down all the bug fixes and patches since version 2.3.0 and I don't think there have been any official releases since then. However, if I find some other programs I need that depend on it, I'll definitely look into updating the source with some of the patches others have created for it. Seems like it could be a useful library.

I am still trying to find utilities that handle rendering abcm2ps output properly. So far, I've found no lightweight solutions. Heavyweight browsers or Ghostscript can handle the situation, but I'd really like to find alternatives that are easier to build from source and would be more efficient on very low resource computers.

Also ran across an interesting C program to concatenate PDF files called pdfconcat:
https://github.com/pts/pdfconcat
I asked on github about the license since it wasn't indicated and just found out from the developer that the license is GPLv2. Looks like a nice program. Definitely worth sharing.

If you know of other lightweight SVG, Postscript or PDF utilities or conversion programs with minimal dependencies, I'd be very interested to hear about them.

I've been investigating Open Source C/C++ PDF viewers/rendering libraries. There really isn't a lot available out there. Most projects use poppler. It was developed as a fork of xpdf and is supposed to be somewhat more efficient than it. Both are licensed under GPL. The only other real competitor is mupdf. There have been some comparisons done on efficiency between mupdf and poppler and mupdf seems to be the clear winner. Just running mupdf versus a poppler based PDF viewer on a very large PDF file being viewed on a slow computer gives a good idea of the differences between the two. Mupdf was originally licensed under a GPL license and is now using AGPL which is even more restrictive. There are also commercial licenses available for poppler and mupdf which companies hope that projects will use if the GPL and AGPL licenses are too limiting. Projects would need to make all of their source code freely available if they want to include either of these libraries and don't want to purchase a commercial license. With AGPL, the source code needs to be available even if the program is not distributed, but it is used by someone over a network.

One possible alternative to these options is pdf.js ( https://github.com/mozilla/pdf.js ). The license is Apache 2.0 which doesn't require that you distribute your own source code. pdf.js as the name implies is written primarily in JavaScript. So, to run this with a C/C++ program, one could use an embedded web browser that can handle JavaScript. One such alternative that works with SDL, FLTK and other graphics or GUI libraries is the wkccc library (based on webkit) in Netrider ( https://sourceforge.net/projects/netrider/ ). Another alternative would be to convert the JavaScript code to C. This should greatly improve rendering efficiency and speed if done properly. It's an alternative I'm seriously considering should I need a PDF rendering library with a more liberal license at some point.

Since I just wanted a simple, efficient Open Source PDF viewer that I could freely distribute (along with its source code) if needed, mupdf seemed like a good possibility. However, I'd prefer to avoid AGPL licenses. Occasionally I see developers keeping an older version of an Open Source software project alive because they prefer the license used by the older version. When I ran across a GPLv2 version of mupdf at Github ( https://github.com/technosaurus/mupdf-GPL2 ), it encouraged me to consider the option of using an older version of mupdf with a more lenient license. I investigated using the GPLv2 version at github, however, it was missing several features of later versions of mupdf and it used jam as a build system. Going back to the last GPLv3 versions of mupdf provided many more features than the GPLv2 version plus a more standard build system. Searching for mupdf GPLv3 on github even yielded a handful of projects that went on to add new features. So, assuming ebook rendering isn't needed (and I already use applications like bard for that), the GPLv3 version of mupdf really has all the features needed for creating a fast, basic, cross-platform PDF viewer. My next step was to investigate what was working in the GPLv3 version, what was missing and what could be easily added using the various GPLv3 forks or other Open Source projects.

After further investigation and some prototyping, I now have a GPLv3 version of mupdf. It already had basic cbz support. However, I really wanted a cbr viewer as well. I have been searching for a decent, open licensed cbr library for a long time and I finally found an Open Source LGPL library that is part of sumatrapdf. I removed much of the cbz code in mupdf and substituted code that uses the unarr library from sumatrapdf for cbz and cbr access. If one can view graphics in cbz or cbr format, one can also view graphics that aren't archived, so I made sure support for that was working properly. I also added support for SVG format using nanoSVG. Viewing SVG files with a later version of the mupdf application and comparing that with my results, my version actually seemed to do a better job using the nanoSVG code for rendering than the mupdf AGPL licensed rendering engine did.

I happen to like the Unix philosophy of finding and working with programs that do one thing well. Since unarr is LGPL licensed, I realized I could have a cbz/cbr viewer completely independent of any mupdf code and the whole project could be licensed under LGPL. I have the basics working with unarr and SDL, I just need to create a user interface to handle choosing files and navigating through the pages. However, my original goal was a PDF viewer. It would still require a library such as mupdf whether I split off cbz/cbr viewing functionality or not. That currently leaves me with two choices for PDF viewing. I can use the mupdf GPLv3 library with a mupdf or custom SDL front end or I can attempt to port a library such as pdf.js to C and create a SDL front end for it.

I can't help wondering if I'm the only person looking for a lightweight, efficient, C based Open Source PDF viewer that can be used with a Linux distribution (or on other platforms when needed). There are some interesting lightweight Linux distributions being developed with goals such as working on older computers or making the most of their hardware. There are projects where developers build everything themselves (such as Linux from Scratch). Simple to build programs with limited dependencies are often preferrable in those cases. There are some alternative free operating systems in the works (like FreeDOS and Haiku). There are also users who like to specialize in finding light, efficient, limited dependency software for their desktop computers. Plus, with cross-platform programs, it would be nice to run the same familiar software on mobile devices as well as on desktops and laptops. Considering all that, there should be other developers and users who might be interested in similar goals. If that's true, I'd love to hear from you and compare ideas on how best to accomplish the goal of creating a simple, lightweight Open Source C PDF viewer. You can contact me via the CppDesign mailing list ( http://groups.yahoo.com/group/cppdesign ) or other methods and share notes on development and building software. It would be nice to combine resources on a project of this nature. Would also be happy to discuss finding/working on/building other useful, lightweight Open Source C/C++ projects.

I haven't fully decided which way to go for a PDF viewer, so I haven't made my source code enhancements to mupdf (GPLv3) available as yet. Not much point taking up web space to share code if no one's using the project at all. If there are others interested in this route, please let me know.

Some interesting Open Source command line programs output their results in Postscript and/or PDF format. That makes it useful to have lightweight PDF and PostScript viewers that don't require a lot of dependencies to build so you can view their output quickly. It's also nice on Linux systems if they work in framebuffer mode, so you don't have to start an X Windows session just to view results. Cross-platform viewers work on a variety of systems from Linux and Mac to Windows to DOS and even Android. Having tools to edit/modify PDF and PostScript output is also useful.

I've been searching a lot lately for lightweight PostScript and PDF viewer options. Thought I'd share some of what I've learned about cross-platform PostScript and PDF support. If you know of any other viewers or PDF/PostScript related programs with minimal build dependencies that I may have missed, please let me know. I'm always looking for additions for my Open Source applications list: http://www.distasis.com/cpp/osrclist.htm

First, here some of the programs I use that output to PDF or PostScript.

wkhtmltopdf
http://wkhtmltopdf.org/
This does have a lot of build dependencies (needs Qt and webkit), but it's one of the few programs that I've been able to find that does a good job of converting HTML to PDF.

Other HTML to PostScript/PDF alternatives are html2ps ( http://user.it.uu.se/~jan/html2ps.html ) which requires Perl and PhantomJS ( http://phantomjs.org/ ).

abcm2ps
http://moinejf.free.fr/
I use abcm2ps to convert songs in ABC notation to sheet music. Later versions of abcm2ps have the ability to output to SVG as well as PostScript. I have a lightweight SVG viewer based on nanosvg and SDL that displays SVG, so that should be an interesting display option if a PostScript viewer isn't readily available. I can upload the build scripts for it to my archive if anyone wants to try out the SVG viewer.

lcal and pcal
http://pcal.sourceforge.net/
Personal calendars and lunar calendars can also be output to PostScript format.

gle
http://glx.sourceforge.net
The graphics layout engine outputs charts and graphs to PostScript, PDF and some graphics formats.

Other applications can output starcharts, barcodes, graphs, etc. to PostScript format. The applications I listed above are the ones I personally use the most in this category. If you have other favorites, would be interested to hear about them.

Next, I'll mention some PDF libraries and viewers.

The two main PDF rendering libraries/applications are mupdf and poppler.

Poppler
https://poppler.freedesktop.org/
Poppler is a library based on the xpdf viewer, so in most cases you really only need one of these on your system. They both have a lot of the same utility programs. When building poppler, there's additional support for GTK and Qt frameworks if you have those on your system. I typically build with these turned off to lower dependencies.

MuPDF
http://mupdf.com/
Mupdf was written by the developers of Ghostscript. It renders very quickly and is supposed to be very lightweight. However, what I dislike about it is its growing list of dependencies. Newer versions of mupdf provide more and more functionality, but they're requiring more dependencies to do so. Later versions of mupdf now require harfbuzz which I typically don't use with any other applications. (I'm not using Opentype fonts.) Also, the developers recommend you use their third party libraries rather than system libraries. There are work-arounds to use the system libraries, but it's a nuisance to modify the build scripts each time the program is updated. The API is not very stable either. Every time I download a new version, it seems to break third party utilities built using the mupdf library.

Mupdf has example viewers that come with it. The latest example includes an OpenGL based viewer. I did some work on a SDL based viewer using mupdf, but the API kept changing, making it difficult to maintain. When the OpenGL based viewer was added, I looked into using picogl in place of OpenGL/Mesa as a backend for the viewer. Using a viewer that comes with mupdf meant the mupdf developers would be responsible for dealing with the API changes. I got the OpenGL based viewer to build with picogl, but picogl still needs additional functionality to provide clear rendering of the text displayed by the mupdf viewer. Hope to work on this further in the future and would love to hear from anyone else who'd be interested in helping on this project.

There are some SDL and framebuffer based PDF viewers. However, they were either not easy to port to other platforms or had heavy dependencies I didn't want to add to my system. I found it interesting that some viewers used SDL as the actual graphical user interface (and could run in framebuffer mode on Linux), but still required GTK or Qt as an additional interface when rendering pages.

I finally found a lightweight, cross-platform PDF viewer that uses FLTK as a front end. It's called SpRead ( https://github.com/muranoya/SpRead ). It can be run in framebuffer on Linux using FLTK built with nano-x. The viewer is very lightweight and does seem to render quickly. Dependencies are really minimal compared to other viewers I've looked at. However, mupdf renders faster in many cases. SpRead uses poppler for PDF rendering and libarchive for zipped/archived file access.

Some other interesting PDF libraries available for editing and creating PDFs are qpdf ( http://qpdf.sourceforge.net/ ) and libharu ( http://libharu.org/ ).

Poppler and xpdf both come with PDF to text conversion utilities. This is very useful if you want to work with grep to search for a word or phrase in a collection of PDF files. Mupdf has added the ability to convert to text in more recent versions. However, their help/man pages on how to use their tools could use improvement. When I was searching for a lightweight PDF to text converter, I ran across pdftxt at https://litcave.rudi.ir/ As I mentioned, the mupdf library API keeps changing with newer releases, so typically when I update my version of mupdf, the pdftxt build breaks. I've uploaded patches to build pdftxt with the version of mupdf that I've most recently updated to. You can find patches and build scripts at the archive link on this page:
http://www.distasis.com/cpp/lmbld.htm

Since lightweight PDF viewers are more plentiful than PostScript viewers, I searched for PostScript to PDF converters. The main option in this category is Ghostscript. Like mupdf, it requires several dependencies and uses its own versions rather than system versions of libraries. It's actually worse in this area than mupdf. The only viable option to Ghostscript that I could find for PostScript rendering was xpost ( https://github.com/luser-dr00g/xpost ). It has less dependencies that Ghostscript and is easier to build. However, it's still a work in progress. I'm hoping at some point that it will replace Ghostscript for the functionality I'm interested in, but it at this point, it still doesn't have all the functionality I require. It does look like a promising project though.

Those are some of the interesting libraries and applications I've found on my search for PostScript and PDF related utilities. Hope you find some of them useful. If you know of other lightweight, cross-platform alternatives, I'd love to hear from you about them.