Free printer output software for linux

Prima::Printer is a system printing services.

SYNOPSIS

my $printer = $::application-> get_printer;
print "printing to ", $printer->printer, "...n";
$p-> options( Orientation => Landscape, PaperSize => A4);
if ( $p-> begin_doc) {
$p-> bar( 0, 0, 100, 100);
print "another page...n";
$p-> new_page;
$p-> ellipse( 100, 100, 200, 200);
(time % 1) ? # depending on the moon phase, print it or cancel out
$p-> end_doc :
$p-> abort_doc;
} else {
print "failedn";
}

Prima::Printer is a descendant of Prima::Drawable class. It provides access to the system printing services, where available. If the system provides no graphics printing, the default PostScript (tm) interface module Prima::PS::Printer is used instead.

acoc is a regular-expression based colour formatter for programs that display output on the command-line. It works as a wrapper around the target program, executing it and capturing the stdout stream. Optionally, stderr can be redirected to stdout, so that it, too, can be manipulated. acoc then applies matching rules to patterns in the output and applies colours to those matches.

Ever wondered why the output of your favourite UNIX/Linux commands is still displayed in black-and-white after all these years?

Ever had to search back through your scroll-buffer in search of gcc errors and salient information to tell you what went wrong with your programs execution?

acoc is a regular expression based colour formatter for programs that display output on the command-line. It works as a wrapper around the target program, executing it and capturing the stdout stream. Optionally, stderr can be redirected to stdout, so that it, too, can be manipulated.

acoc then applies matching rules to patterns in the output and applies colour sets to those matches. A picture is worth a thousand words, so look at the sample screenshots in the next section.

Configuration

The configuration files used by the program are /usr/local/etc/acoc.conf, /etc/acoc.conf and ~/acoc.conf. One or more of these must exist. A sample /etc/acoc.conf is supplied with some example matching rules.

Blank lines and those that begin with a # are ignored.

A program configuration stanza is introduced as follows:

[program_spec]

The square brackets are mandatory literal characters. Alternatively, the @ symbol may be used, to allow [ and ] to retain their usual semantics in program specs comprising a regular expression:

@program_spec@

program_spec is defined as one or more instances of the following component, separated by a comma:

invocation[/flags]

where invocation consists of the programs name (not including its directory path component) plus any initial arguments.

Alternatively, invocation may be a regular expression, which can be used to match multiple programs and/or command-line arguments in arbitrary order. Regular expressions are automatically anchored to the beginning of the command line.

flags, if present, is separated from invocation by a slash and consists of one or more of the following characters:

a
continue to attempt to find matching patterns after the first match has been found. By default, acoc will stop processing a line and display it after the first match has been found.
e
redirect the target programs stderr to stdout, allowing it, too, to be matched by rules
p
allocate a pseudo-terminal in which to run the target program

Some programs, such as ls(1), behave differently when their stdout is not connected to a tty. Use of this option will fool the target program into believing it is outputting to a tty, rather than a pipe to acoc.

Use of this flag requires Masahiro Tomitas Ruby/TPty library to be installed. Otherwise, the flag is silently ignored.

Note that the pseudo-terminal communication enabled by this flag is one-way only, from the target program to acoc. It is thus not possible to use acoc in combination with interactive programs, such as the interactive Ruby interpreter (irb).
t
apply colour formatting even if stdout is not a tty. By default, formatting is not applied if the output stream is not attached to a terminal.

Heres an example of a line that introduces a configuration stanza:

[rpm/ae,rpmbuild/ae]

which says to apply the following rules to the rpm and rpmbuild commands, attempt to apply all matching rules, and also apply those rules to the programs stderr stream.

Another example:

[ls/p]

This says to allocate a pseudo-terminal to ls(1), fooling it into believing that its output is being sent to a regular terminal instead of a pipe to acoc.

With this flag, the effect will be this:

$ ls
file1 file2 file3 file4 file5 file6

Without it, ls will detect that its stdout is connected to a pipe and behave accordingly:

$ ls
file1
file2
file3
file4
file5
file6

A third example:

[diff/t,rcsdiff/t,cvs diff/t,p4 diff/t]

This says that the rules that follow should be applied to all invocations of diff(1) and rcsdiff(1), as well as those invocations of cvs(1) and p4 that are followed by the argument diff.

Additionally, colouring should be applied even when stdout is not connected to a tty, so that the colours still show up when the output is displayed in a pager such as more(1) or less(1).

Yet another example:

/ps -.*(e.*f|f.*e)/

In this example, the ps(1) command will be matched, as long as the e and f options are both passed in either order.

An alternative way to write the above spec is:

@ps -.*[ef].*[ef]@

There are two things to note in this alternative:

1. @ has been used to delimit the spec, because [ and ] are required for the character lists in the regular expression.
2. While this form is less specific (in that it allows matches against duplicated command line options), it makes for considerably shorter specs if one wishes to test for the inclusion of a set of more than 2 or 3 command line flags. In the original form, one must manually list all of the possible permutations, which is equal to x! (factorial). For 3 command line flags, this is 6 permutations; for 4, it is 24, etc.

Heres one more example:

[tcpdump/r]

If this were placed in ~/.acoc.conf, it would remove any matching rules that had been installed for the diff command by either /etc/acoc.conf or /usr/local/etc/acoc.conf.

After defining the program name and operational flags, matching rules can be defined. These take the following form:

/regex/[flags] colour_spec

where regex is a Ruby-compatible regular expression. The delimiting / characters can be any character, as long as that character is not present in the regular expression itself. flags, if present, consists of one or more characters from the following list:

g
find every match on the line, not just the first. When using this flag, regex should not include parentheses.

colour_spec is defined as a comma-separated list of one or more colour_groups, which are defined as a plus-separated (+) list of one or more of the following:

* black
* blink
* blue
* bold
* clear
* concealed
* cyan
* dark
* green
* italic
* magenta
* negative
* on_black
* on_blue
* on_cyan
* on_green
* on_magenta
* on_red
* on_white
* on_yellow
* rapid_blink
* red
* reset
* strikethrough
* underline
* underscore
* white
* yellow

Examples of a colour_group are white+bold, black+on_white, etc. A complete colour_spec might look like this:

red+bold,white,yellow+bold,black+on_green

Except when using the g flag, each component of the regex that you wish to colour should be placed in parentheses. Text outside parentheses will be used for matching, but will not be coloured.

For example, examine the following:

/^(d+)foos*(w+)/

This will match a line that starts with more or one digits, followed by the string foo and any amount of white space, followed by one or more word characters. However, only the initial group of digits and the group of word characters will be coloured. The string foo and the white space that follows it will be used for matching, but will not be coloured.

Separated from the regex by white space is the colour_spec. Usually, you will include in this as many colours (separated by commas) as you have parenthesised expressions in the regex. However, its also permissible to have fewer. If, for example, you have three parenthesised expressions in the regex, but only two colours listed in the colour_spec, then the second colour will be used for colouring both the second and third matches.

If you have more colours listed in the colour_spec than there are parenthesised expressions in the regex, the surplus colours are ignored.

When using the g flag to perform a global match on the line, you may list as many colours as you want. The same rules apply here. If there are more matches than colours, the remaining matches will be coloured using the last colour listed. Surplus colours are ignored.

PackPrint provides a pretty-printer for ethernet packets.
PackPrint is a program to parse and print out ethernet frames in a pretty way. For protocols that it knows about (ARP, UDP, TCP, ICMP, and raw IP), it will decode the data and print it out in an easy-to-read format.
Main features:
- PackPrint will display the contents of ethernet frames. For protocols that it knows about, it will decode the data and print it out in an easy to read format
- The protocols that PackPrint currently understands include
- ARP
- UDP
- TCP
- ICMP
- IP
Usage:
PackPrint is incredibly easy to use - simply to packprint , where is the name of a file generated using the -w option for tcpdump (or some other program using libpcap).
If is -, then packprint reads from standard input, so you could do:
$ tcpdump -s 65535 -w - | packprint -
to produce an nice output for tcpdump
NOTE: always use the -s 65535 options on tcpdump to make sure you get the entire packet contents so that packprint can decode it

Audio Input-Output Library (libaio) is meant to solve the problem of differing digital audio platforms once and for all.

JACK is unnecessarily complex for most applications, and while libaos support for file output is cool, it limits what the API can do and is therefore inadequate for any kind of real time application.

libaio provides a clean application interface and a simple compile-time driver switching decision, yielding a lightweight way to use the local sound hardware without having to care what it is.

Libaios first sparkle was when I, Hod McWuff (alias, of course), found myself trying to debug ALSA implementations for libao and madplay, and another audio-related project Id been working on. That project needed multiplatform audio support of its own, with latency management, which libao lacked.

It also seemed that libao shouldnt have been trying to be both a hardware abstraction *AND* an output abstraction, and also that it seemed more intuitive as an output (live vs file) abstraction.

Enter libaio. All it does is abstract the local sound hardware platform, to present a clean, uniform interface to playing and capturing digital audio, with facilities for basic latency management. It was written from scratch around its developing ALSA driver, from many many reference sources including libao and Robert Leslies excellent madplay MP3 decoder, and of course the ALSA documentation and examples.

Libaios distinction comes from its build-time decisionmaking. It only compiles and links the best driver available for the given platform. Therefore, selecting and loading a driver no longer applies; and well it shouldnt, theres never more than one correct choice anyway.

Libaio is not intended to replace libao; rather it is intended to supplement it. The key argument is, why would anyone EVER have more than one running sound platform type on any single machine? Sure, they might have ESD or ARTS, but they more resemble file output than a live device. Theres also the OSS emulation in ALSA, but given a good ALSA driver, whod use OSS?

Then theres the fact that applications have to tell libao what "plugin" to use, and all the drivers in libao have different parameters. That means the application has to know more than it should about what it shouldnt have to see. The app shouldnt have to say more than "give me the local device for playback with *** format" or something to that effect, and start writing.

Finally, plugins for stuff like proprietary file formats, ESD et al, but there shouldnt be any need for more than one of (ALSA|OSS|SUN|WIN32|MACOSX ) on any given distribution. Therefore, binary distribution of a compiled-in driver is possible, even preferred.

It is proposed that all of the hardware drivers in libao, and madplay, and several other places, be reviewed and ported to libaio. Then, they can be removed from those packages in favor of an AIO interface.

Installation:

## building
./configure
make


## installing (as root)
make install

neo-Portal is the most customizable portal.
Main features:
- full i18n localization support;
- OS,
- web server,
- database independent;
Output:
- XHTML
- PDF
- RSS
- TXT
- RTF
- WML
- and more...

Lexmark Z11 printer driver for Linux is a Linux printer driver/filter for the Lexmark Z11 printer, supporting color and b/w printing, variable page size and more.
The driver lz11-V2 is an improvement of the lz11 driver, which was first released in 2002. Additionally to the features of lz11, which include variable page sizes and ink saving, the lz11-V2 version comes with a backward compatibility mode for the filters "cZ11" and "cZ11somsom". While the cZ11 filter is emulated in an improved way, which helps to save ink and takes away the grayish look of color prints, the cZ11somsom emulation only supports the basic properties (as InkType and DitherPPI). Ink weighting is not included, but merely needed, because of a new pixel placement algorithm for black and color ink.
"Highlights" of the lz11-V2 are: further improved printing speed for black ink and a tool to align the skew of the black ink cartridge. A smooth-dithering algorithm for black and color prints was added. The driver comes with an improved set of installation and utility scripts that support automatic installation-option-checking, testpage-printing, black-ink-adjustment, automatic installation of foomatic-xml-files as well as automatic installation of the included PPD files for CUPS and PPR. For backward compatibility reason the GhostScript device emulation (as "hpdj", "epsonc", ...) is still included, but should never be offered on "modern" Linux installations.
The original driver-code "cZ11" was written by Christian Kornblum in 2001 (this code still is the backbone of this filter).
WARNING:This driver is known not to work with the Z31 and Z51. In fact, it is known to hose those printers flash in some circumstances!
Enhancements:
- The installer can be called by ./lz11.install --debug, which will produce BMP files instead of paper prints (for test)
- Now the cups-restart is done also properly for Debian and Gentoo
- An installed Z11 printer-queue (PPD) and its options are updated automatically during installation
- The print-job cancelling is now appropriate for hotplug generated devices. Printer "hick-ups" on a resume are prevented
- The print-job cancelling is shown automatically in an "xterm"
- some smaller bug fixes

The purpose of the preview-latex package is to embed LaTeX environments such as display math or figures into Emacs source buffers. By mouse clicking, you can open the original text.

After editing, another click will just run the region in question through LaTeX and redisplay the new results. It requires version 21.1 or higher of Emacs or XEmacs and AUCTeX.

WYSIWYG (what you see is what you get) sometimes is considered all the rage, sometimes frowned upon. Do we really want it? Wrong question. The right question is what we want from it. Except when finetuning the layout, we dont want to use printer fonts for on-screen text editing.

The low resolution and contrast of a computer screen render all but the coarsest printer fonts (those for low-quality newsprint) unappealing, and the margins and pagination of the print are not wanted on the screen, either.

On the other hand, more complex visual compositions like math formulas and tables cant easily be taken in when seen only in the source. preview-latex strikes a balance: it only uses graphic renditions of the output for certain, configurable constructs, does this only when told, and then right in the source code.

Switching back and forth between the source and preview is easy and natural and can be done for each image independently. Behind the scenes of preview-latex, a sophisticated framework of other programs like `dvipng, Dvips and GhostScript are employed together with a special LaTeX style file for extracting the material of interest in the background and providing fast interactive response.