Bonus: fbff, fbpad … and fbpdf too

I do feel obligated to list some framebuffer-specific software here, and I realized a week or two ago that my last list of framebuffer applications was not only almost a year old, but also omitted a worthy pair.

I don’t have much to show for fbff and fbpad, but they are both by the author of fbpdf, and mentioning one without the other two was an oversight. To complicate things, I don’t have a machine right now that will take faithful images of framebuffer output, so here’s my best effort at fbff, and to be fair, fbpdf.

 

Laughable, I know. Just don’t ask about fbpad. 🙄

fbff is probably my favorite of the three, as an alternative to running mplayer against the framebuffer. At 2Ghz on an ATI Mobility Radeon 7500 with an xvid-encoded avi file, the results were quite good. If you could see what it was showing, you’d be watching the opening credits for the first episode of season 11 of Gunsmoke. 😕 (Sorry, in my culture, people are mad for anything Western.)

And if you could see fbpdf at work above, it would be a classy black-and-white page with the words, “Sample text here.” I am nothing, if not inventive. 🙄

Please don’t blame the software for the shortcomings you see there. Both fbff and fbpdf accurately rendered the media against the framebuffer, and offered basic controls for each application. In spite of what you see above, they did actually work right. I just lack a proper screenshot.

fbpad was another issue, but that one was working against the clock for me. Configuring fbpad requires some heavy-duty font setup, the use of an outside font conversion tool, then editing the source code and recompiling fbpad to show the converted font.

I can’t say this is a better way than, perhaps, configuring fbterm. If you wade through those steps, show us a screenshot and we’ll all think highly of you. 😉

Dependency-wise, fbff and fbpdf were the heaviest, with fbff pulling in the ffmpeg structure (of course) and fbpdf requiring mupdf, some poppler and some djvulibre. If you have other options for video/audio/image playback and pdf display at the framebuffer, I’d recommend weighing them against what fbff and fbpdf will need.

fbpad didn’t strike me much heavier than fbterm, truth be told — unless you count the time and tools it would take to convert and configure and compile the font. And that, knowing full well I wouldn’t get a proper image of it anyway. 😦

One last question you might ask: So why make so much fuss about a couple of framebuffer-based applications? Well, for one thing, alternatives to the industry-standard tools, like mplayer or fbida, are always welcome. Neither of those is such a perfect fit for a framebuffer-only machine that someone new can’t wedge their way into my system.

Second, and probably more importantly, access to a framebuffer can sometimes be what saves a machine from the eternal reward. There’s a big difference between a 233Mhz machine that can run text programs fullscreen at 80×25, and a 233Mhz machine that can run a full suite of terminal applications at 1024×768 using the terminus font overlaid atop a picture of Miles Davis.

One is functional, but the other is crazy, funky and cool. 😉

groff: Typesetting, in any direction

It seems to me, groff is another one of those programs — like lilypond from so long ago, or even like mencoder or some other conversion tools — that are sitting on the fence in terms of console programs.

groff doesn’t really display anything, that I can find. It converts between specific markups, changing, for example, text-formatted pages to man format. If all goes right, groff doesn’t show you a darned thing. But the output files are quite lovely.

Here’s an example. First, a raw man page converted to ASCII, then formatted to be readable.

 

Whenever possible, I try to avoid the Wall of Text effect.

groff can do some other fun things too. Here’s a man page converted to a PDF document.

I know: Acrobat Reader. Ick. 😛

You can convert straight to PDF with groff and its included tools, without the need for ghostscript. groff translates between other formats too — including some I had never heard of. Here’s a memorandum macro letter, which was completely new to me until this morning.

Nice and clean output, even if it is in Acrobat Reader. Blech.

There is plenty of help online that will get you started with groff. My favorite discussion, as you will be able to tell as soon as you start into it, was here.

Like I said at the start, as a conversion tool, groff doesn’t seem to show much. In fact, in all those examples, groff never said a word unless there were errors.

So the question remains: Is a taciturn and laconic conversion tool still a console application? Should I have omitted this and all those others? Have I been wasting my time all these years? 😮

wkhtmltopdf and wkhtmltoimage: The clever twins

I was very much torn on whether or not to include wkhtmltopdf and wkhtmltoimage here, or just throw them into the leftovers at the end of the W section.

As I understand it, these twins use WebKit to convert HTML documents into either PDF format, or to generate an image. It’s a nice idea, and works great.

kmandla@6m47421: ~/downloads$ wget https://inconsolation.wordpress.com
--2014-06-29 08:18:55--  https://inconsolation.wordpress.com/
Resolving inconsolation.wordpress.com (inconsolation.wordpress.com)... 66.155.9.238, 192.0.81.250, 192.0.80.250, ...
Connecting to inconsolation.wordpress.com (inconsolation.wordpress.com)|66.155.9.238|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html’

    [                                                                  ] 65,344       354KB/s   in 0.2s   

2014-06-29 08:18:56 (354 KB/s) - ‘index.html’ saved [65344]

kmandla@6m47421: ~/downloads$ wkhtmltopdf index.html index.html.pdf
libpng warning: iCCP: Not recognizing known sRGB profile that has been edited
Loading page (1/2)
Printing pages (2/2)                                               
Done                                                           
Exit with code 1 due to network error: ProtocolInvalidOperationError

My hesitation comes in the fact that, as best I can tell, neither program can run without qtwebkit or X (although the Arch package page suggests Xvfb will work). So I’m fudging the definition of “text-based program” again, for a tool that doesn’t show much “text-based” to start with.

But this wouldn’t be the first time. We endured a barrage of pdf-conversion programs back in February, and some of those are no more graphical than these two. So I guess it’s okay.

What’s the output look like? Not bad at all.

PDFs are about the same quality, but of course split into pages and probably bigger.

Both wkhtmltopdf and its sister have an immense number of flags and options that allow an impressive level of control over how the pages are rendered and the quality you achieve. So don’t dismiss either as a fire-and-forget conversion tool; the opportunity is there to fine-tune the experience.

Just remember that you will more than likely incur the need for X if you want to try either one.

qpdf: Still more PDF wizardry

Just when you thought all your PDF options were expended, along comes qpdf to rattle your cage once more.

The home page uses “pdf-to-pdf” as a subtext for what qpdf does. And most of what qpdf does is just that: manhandling PDF files and getting the results you want, without distorting or smushing the content. (“Smush” is the scientific term.)

For example, reversing the order of pages in a pdf file.

kmandla@lv-r1fz6: ~/downloads$ qpdf --empty out.pdf --pages intro-linux.pdf z-1 --

--empty signifies a new file named “out.pdf,” --pages tells qpdf to wrangle pages, “intro-linux.pdf” is the source file and z-1 is pages 1 to the end, in reverse order.

qpdf is quite forgiving about page orders, sequences and even multiple sources. I haven’t tried every permutation, but I suspect you could do some real PDF wizardry with the freedom qpdf allows.

There are a lot more ideas in the qpdf documentation pages, which is so up to date that it’s timestamped in the future! 😉 On a more serious note, the ins and outs of qdf’s power are all listed there, in precise detail.

It might take a little while to learn all the tricks qpdf makes available to you, but I have the feeling that if every other PDF gizmo fails you, qpdf will satisfy. 😉

ps2ascii and ps2pdf: In two directions

I don’t run across pure Postscript files too often any more. All the same, things like ps2ascii and ps2pdf are useful.

Both are part of the ghostscript package, which you might already have installed as a dependency to something else. It seems to get around.

 

I don’t know if there’s much I can add that isn’t better shown in the images. On the one hand you can convert to straight text, and the other, make the leap to PDFs … and from there, there’s lots of places to go.

I will say ps2ascii‘s product seems to be a bit cluttered, so it might need a little touching up here and there. I hold no grudge over that though.

And I should also note that ps2pdf has a few variations, and on my Arch system they show up as ps2pdf12, ps2pdf13, ps2pdf14 and ps2pdfwr. If you need a certain degree of compatibility — or lack thereof, if you use ps2pfdwr alone — you have the options.

Conversion tools, conversion tools, so many more conversion tools. … 😐

pdftk: All the others mixed together, and then some

I set apart pdftk from the rasher of other pdf-entitled tools for two reasons: One, because I already swept through Coherent PDF Tools a few months ago, and it seems fair to include another PDF suite; and two, because jojo and Antonio both suggested it.

It’s true, there is a metric ton of pdf-titled tools available, and a good four-fifths of them are true gifts to those living life at the console. (That last fifth … well, I’m sure they have their fans. 🙄 )

And yet, if you were to combine (almost) all of those into one suite, you would probably come up with something weakly resembling pdftk. And chances are you’d still have quite a few functions available in pdftk that hadn’t been tackled individually.

pdftk will handle the mundane tasks — like splitting, merging, rotating and “bursting” PDF files — but it can also flatten PDF forms into single files of form and data, encrypt at 40 or 128 bits with passwords, collate scanned pages in reverse order, preserve document IDs across input and output files, stamp pages a la watermarking, fill PDF forms from external files, and a lot — no, I mean a lot of other things.

Seeing something like pdftk in action makes me wish I had more use for PDF files on the whole. 😕

Best part is, it does this all in a clean and easy-to-understand fashion, without cryptic commands or unwieldy strings of flags. Bravo! 😀

Now … there’s no color. And there’s no real interface to speak of. I know those are minor shortcomings.

But I think jojo and Antonio were both right when they suggested pdftk; it’s obvious this is a tool done right.

Last note: pdftk is in AUR and Debian; I showed the Debian version mostly because it was going to take a looong time to build in Arch. I get so lazy sometimes. …

pdf*: The splat meaning, “Whatever you want”

There’s no tool called pdf*. That’s just my snarky way of pointing out that there are hundreds of tools that start with “pdf” and do any number of conversion, editing, manipulation, password hacking or display tasks for PDF files.

There are even tools to drive spinning cube transitions for PDF documents. 😯 😕

An added ruffle comes in the fact that for every pdf conversion tool — particularly the ones cleverly titled “pdf2”-whatever — there’s usually a sister tool that reverses the process.

You saw that in action (sort of) the other day when I used ps2pdf14, out of the ghostscript package, to view the calendars pcal made.

So the number grows linearly. 😯

The fact is, there are enough of pdf* tools to satisfy a blog just about PDF tools. 🙄 Granted, not all of them are intended specifically for the console or even specifically for Linux. In fact a few of them might only work under full graphical steam.

But this post is my concession that there are hundreds to pick from, that I don’t have a comprehensive list by any stretch, and the few that I know personally are by no means the best available.

Rather than send you away empty-handed though, I have an admittedly brief list of some of the tools that start with pdf*, and links to their home pages where I could find them.

It’s possible that some of these are not text-only, and that some of them aren’t even working or available any more. It’s just a healthy chunk of the P section that I’m handing over, out of a sense of duty. 🙄 Here goes. …

• pdfadd: Builds mathematical graphs and diagrams in PDFs.
• pdfbeads: Converts scanned images into a single PDF file.
• pdf2book: Reorders PDF pages for printing in book format.
• pdfcrack: Password recovery for PDF files.
• pdfcrop: A perl script to trim white space from PDFs.
• pdf-decrypt: Strips encryption from PDFs.
• pdf2djvu: Creates DjVu files from PDFs.
• pdfenlarger: Adds whitespace to PDFs.
• pdfgrep: grep for PDF files.
• pdf2htmlEX: Renders (converts?) PDF pages to HTML.
• pdfjam: Shell scripts that build on the pdfpages package.
• pdflatex.sh: Simplifies creation of PDFs with LaTeX.
• pdf2line: Converts PDFs to plain text.
• pdfmasher: Converts PDFs to epub format.
• pdfminer: Extracts information from PDFs.
• pdf-parser: Reports the physical and logical structure of PDF files.
• pdf2png: Converts PDF pages to PNG files.
• pdfposter: Scale or tile PDF images for large-size printing.
• pdfreduce: Runs a PDF file through Ghostscript in hopes of reducing the original file size.
• pdfreflow: Reflows and repaginates text within a PDF.
• pdfresurrect: Analyzes PDFs and supports a built-in document history.
• pdfsam: Split and merge PDFs.
• pdfsandwich: Processes PDF files with optical character recognition and adds the text behind images of the pages.
• pdfscissors: Crops PDFs.
• pdfselect: A page selector for PDF files.
• pdf2svg: Converts PDFs to SVG files.
• pdf-tools: Various tools, including building and creating embedded PDFs.
• pdftools: Scripts for manipulating PDFs.
• pdftrans: Adds metadata or encrypts PDF files.
• pdftxt: Extracts text from PDFs.

My apologies beforehand for any broken links or nonworking packages. I haven’t taken the time to try them all out. That would be a feat. 😯

lilypond: That gray area

I am very much on the fence when it comes to including lilypond on this list.

As I understand it, lilypond — the program — just converts text-based sheet music into a visual format (I believe the home page calls it “engraved”) not unlike what LaTeX does … although I know very little about that either.

So the net effect of lilypond is this:

Text-based coding for sheet music converted into pdf format, without much of an interface or interaction.

That doesn’t discount it as a text-based application, any more than imagemagick or even inkscape, or some other tools that follow the same style.

That does drop it into a gray area though, where the benefit is in the output, and not the interface.

So is it a command-line application? Is it a true-blue text-only program?

I’m not going to fight through this one. I humbly submit that it does its job, interface or no interface, and if you need to draw some sort of line in the sand to reinforce an us-and-them mentality … then you’ve overlooked the real beauty of software like this — making life easier, and more beautiful.

epub2pdf: Proof of the viability of Java-based applications

I joke when I say that. A long time ago I was in a rather terse forum “conversation” with a person who insisted Java was the only negotiable programming language because it was cross-platform.

Of course, as a proponent of underpowered hardware, my reply was that I’d rather be beaten about the head and shoulders with a dead fish than suffer too many Java-based applications … cross-platform be darned. 🙄

I don’t hold anything against Java, if that’s your gig. I usually don’t hold anything against anything, because having the choice is the most important part to me.

And now having made all those disclaimers in quick succession, I can offer you a glimpse of the end product of epub2pdf.

It probably doesn’t need said any more, but epub2pdf is apparently a Java program, and will run on anything that you can squeeze the runtime environment into … be that Windows *, Mac OS*, Linux or what have you.

And by all accounts, it does a pretty good job. I’m sure there are PDF-o-philes out there, like there are audiophiles, who can tell me whether or not epub2pdf’s end product is worth a darn. In my book, it’s acceptable.

As far as options go, you’ll have to dig around in epub2pdf’s documentation to find all the tweaks you’re after. By default, epub2pdf dumped the output in my home directory, named the same as the epub.

And I hesitate to say it, but I wonder if epub2pdf isn’t a bit slower than some other tools, being Java-based. I know, I’m an uneducated heel and I have no proof of the insinuation, but over two minutes on a dual-core machine just to convert one document seems … lengthy. I’m sorry. I’m speaking out loud again. 😳

I do know that I would be shy about using this on a machine much older than this dual-core, because I have a feeling performance would drop off exponentially. Just my hunch though.

All of that does not detract from the point that epub2pdf works, works well, and will probably work on your machine too, no matter what it is. So is it proof of the viability of Java-based applications?

Oh heck, I don’t know. 😐

enpi: Making the jump to the graphical

I was a little more than surprised the other day when I started digging around on the old blog, and realized I had never really shown enpi in action.

I see why though. Apparently, five and a half years ago, I was absorbed with WordGrinder and didn’t see much potential in enpi.

enpi does the job of translating simple text codes into specific commands for LaTeX.

As such, it really doesn’t stand as a word processor on its own … rather, it’s more a filter or a converter from simplified text to what LaTeX understands.

Which explains my lack of practical use five and a half years ago: I was looking for something to behave like Word 5.5, not just a conversion script.

I will give enpi credit though. As you can see above, it does an impressive job.

But all the actual word processing is going to require an outside application, i.e., the text editor of your choice. So technically speaking, it’s true: enpi isn’t a word processor.

enpi has some other limitations. As far as I could tell, you’re limited to two (three?) fonts and three point sizes. There are subscripts, superscripts and a lot of font effects though.

Some characters jam up enpi, and as a result you can get error messages in the conversion process and garbage characters in the final PDF. Curly quotes, for one, give enpi a headache.

On the other hand, I don’t know of too many applications — scripts or otherwise — that can give you such lovely output with a minimum of effort like this. And not force you to learn an entire new application, commands, etc.

So for enpi, I say huzzah. 😉

P.S., pay close attention to the packages you’ll need to run enpi. And also note that enpi can work alongside joe, if you want a more word-processor-like experience. 😉