Free region software for linux

Data::Region Perl module can define hierarchical areas with behaviors.

SYNOPSIS

use Data::Region;

$r = Data::Region->new( 8.5, 11, { data => PageObj->new() } );
$r->data( PageObj->new() );

foreach my $c ( $r->subdivide(2.5,3) ) {
$a = $c->area(0.25,0.25, 2.25,2.75);
$a2 = $c->area(0.25,0.25, -0.25,-0.25); # as offset from lower right

($t,$m,$b) = $a->split_vertical(2,5,1); # sequential heights
($t,$m,$b) = $a->split_vertical_abs(0,2,7); # absolute offsets
($l,$r) = $a->split_horizontal(2); # $l gets width of 2, $r gets the rest

my($x1,$y1,$x2,$y2) = $a->coords();
my $data = $a->data(); # data inherits from parent, if not set
$a->action( sub { $data->setfont("Times-Bold", 10);
$data->text($x1,$y1, "Some Text");
$data->line( $_[0]->coords() ); # the non-closure way
} );
}
$r->render(); # heirarchically perform all the actions

# Get some info about a region:
($w,$h) = ( $a->width(), $a->height() );
($x1,$y1, $x2,$y2) = $a->coords();
($x1,$y1) = $a->top_left();
($x2,$y1) = $a->top_right();
($x1,$y2) = $a->bottom_left();
($x2,$y2) = $a->bottom_right();

Data::Region allows you to easily define a set of nested (2-dimensional) areas, defined by related coordinates, and to associate actions with them. The actions can then be performed hierarchically from any root of the tree.

Data::Region was written to provide an easy way to do simple page layout, but has, perhaps, more general uses.

PromoEngine is a product which allows the use of the PluggableAuthService in Plone.
The Promo Engine developed by Six Feet Up provides a way to manage the syndication of static promotional content throughout a Plone site from a single centralized repository of "ads".
The Promo Engine leverages the Archetypes reference engine to place ads in specific regions of a site ("ad slots").
Enhancements:
- Major overhaul of the PromoEngine that brings Plone 2.5 integration

FreeDoko is a Doppelkopf-game, written by Borg Enders and Diether Knof. It is developed under and for the platforms Linux and Windows.

The game is still under developement, but since some time playable.

The game ”Doppelkopf“ is a card game for four or more Players. One game will be played by four players.

Doppelkopf originates probably from the mostly in south germany played game ”Schafkopf“. Its name comes from the double (in German: Doppel) existence of each Card (Doppel-Schafkopf). Meanwhile Doppelkopf is played in whole germany, but mainly in north germany and the region of Rhein and Main.

Doppelkopf is a card game with 48 cards and at least 4 players. It is not unlike the card game ”Skat“. Doppelkopf is played with two normal Skat packs of cards (each has 32 cards) without sevens and eights. Here the players with the club queens are playing together. So there are while playing often new pairs.

Doppelkopf is like Skat a game which depends on the skills of each player. This guarantees a exciting and varied game event.

Hugin is a panorama tools GUI.

Goal: an easy to use cross-platform GUI for Panorama Tools.

With hugin you can assemble a mosiac of photographs into a complete immersive panorama, stitch any series of overlapping pictures and much more.

Main Window

This window consists of a toolbar that provides quick access to important functions. It also contains the Images, Lens, Control Point, Optimizer and Panorama Tab, which will be explained below.

Images Tab

Images can either be added with the Add button, or via drag and drop. To change the orientation of one or more images, select them in the list on the left. The image will be show in the preview area, and its orientation (yaw, pitch and roll values) can be edited on the left.

It is possible to select multiple images at the same time. Changes in orientation will be applied to all selected images

Lens Tab

The lens tab looks a lot like the Images tab, except that the lens settings can be edited here. As in the Images Tab, multiselection can be used to change the parameters for multiple images.

Currently only one lens is supported. The idea is that the Lens describes the process that was used to create the image. The most important parameters are the Lens type and the HFOV (Horizontal Field of View). Hugin will read the EXIF information in jpg files created by digital cameras, so usually it is filled out correctly.

Photographers do not use a HFOV in degrees, but the focal length. The focal length can be entered and it will be converted to HFOV in degrees, like the panorama tool require it. The focal length entered is taken to be for 35 mm film cameras.

Usually images are more or less distorted. This can be seen especially if there are long straight lines close to the image border, which are usually not completely straight but bent a little. The a b and c parameters are used to remove that distortion. They are applied radially from the image center, which can be moved by changing the d and e parameters.

During image capture, it is possible that the parameters vary, that is are not the same for each image. This can have many reasons, one of the could be a scanner that cuts a way a few pixel more at one side than the other. Other parameters stay the same, like usually the a,b and c parameters (if the zoom and focus for the images is the same).

The inherit checkmark means that this parameter doesnt vary between the images that were captures with that lens setting. If a parameter is inheritied it is forced to be the same for all images. When inherited parameters are optimized they are kept the same for all images, whereas parameters that are not inherited can get values specific for a single picture.

Control Point Tab

Control Points are probably the most important thing when using panorama tools. The Tab consists of two image displays and tab bars to switch images to be editied. The bottom contains a list view where Points can be selected and some fields to edit a selected point. Points can also be selected by clicking or dragging on them in the images. It is possible to zoom out to show the full image.

Adding a control point works by clicking into one image to select a point and then into the other image. If auto add is not set, the points can be moved by clicking at some other place in the images. They are added to the list of control points by pressing the right mouse button. If you press the right mouse button when only one point is slected, the point selection will be aborted. auto add adds the control point as soon as both points have been specified.

Control point creation is influenced by the following checkboxes:

auto fine tune hugin helps you to find the second point by looking for it in a search region (shown by a rectange around the cursor). This might not always work, but usually is reliable, if the image distortions are not too big. Try and play with it.
auto add A control point is automatically added when both points are know. You wont have time to refine the selection before adding the point.
auto estimate Tries to estimate the position of the second point by estimating the translation between the two images. This is very crude and probably only works for single row panoramas created from rectilinear images.

All these flags can be combined. I typically use auto fine tune and auto estimate at the same time. Then hugin usually automatically selects the second point correctly. Well for single row panos that is...

The images are zoomed out, the first click zooms to a temporary 100% view to give you the chance to refine your selection. Note that only the second click will trigger the auto estimate.

The Fine Tune button can be used to find a better position for the point in the right image for already selected point. Contrary to auto fine tune it only looks in a very small area around the point. This function is especially useful if you moved both points by hand, but want to have fine tuned control points.

Press the middle mouse button to pan the image. If you press shift key while paning, both images will move.

This window supports some keyboard shortcuts:

a add a new point that has been selected in both images, and the auto add is switched off.
cursor keys scroll image under the mouse cursor
shift + cursor keys scroll both images at the same time
f fine tune currently selected control point pair. Same as the Fine Tune button
Del Remove currently selected control point.
0 Zoom out to full view.
1 100% view.
Mouse function
Function
control key + mouse movement Scroll image under cursor
shift key + mouse movement Scroll both images
left button Use left mouse button to select new points or drag existing points.
right mouse button Add control point, if auto add is switched off
middle mouse button Scroll image under cursor
shift + middle mouse button Scroll both images

Optimizer Tab

The optimizer moves the images into the right position, so that they can be assembled into a hopefully seamless panorama.

To select what the optimiser should try to estimate, use the Optimize combo box, then click the Optimize Button. If you select the "custom" setting, you can change

Pano Panel

Options concerning the output panorama can be set here.

Indus is an effort to provide a collection of program analyses and transformations implemented in Java to customize and adapt Java programs. Indus is intended to serve as an umbrella for:

* static analyses such as points-to analysis, escape analysis, and dependence analyses,
* transformations such as program slicing and program specialization via partial evaluation, and
* any software module that delivers the analyses/transformations into a particular application such as Bandera or platform such as Eclipse.

At present, there are 3 modules that are part of Indus. More modules are expected to be added over the course of time. We provide an overview of the intent of each module that are available at present.

Indus is a module that houses the implementation pertaining to algorithms and data structures common to analyses and transformations that are part of or are planned to be part of Indus. This module contains interface definition common to most analyses and transformations to provide a framework in which various implementations of analyses/transformations can be combined to form systems with ease. Hence, this module is updated when a new sort of analysis/transformation is implemented as a module in Indus. However, a new implementation of an analysis/transformation will not affect this module as it will implement an existing interface.

StaticAnalyses module is intended to be the collection of static analyses such as object-flow analysis, escape analysis, and dependence analyses. The analyses in this module use common interfaces and implementations from Indus and may define/provide new interfaces/implementations specific to new analyses. Existing analyses are mentioned below.

* Object-flow Analysis (OFA) is a points-to analysis for Java. Each allocation site in the analyzed system is treated as an abstract object and its flow through the system is tracked to infer the possible types an receiver at a call-site to enable the construction of a precise call-graph. The precision of the analysis can be varied in terms of flow-sensitiveness for method local variables and object-sensitiveness for instance fields.

* Escape Analysis is an extended implementation of the escape analysis proposed by Ruf for the purpose of pruning interference and ready dependence edges. The extensions are in the form of seamless addition of value equivalence to the analysis to improve the detection of conflicting field reads/writes occurring in different threads beyond just using type equality of the primaries of the access expressions. The analysis also uses object-flow information orthogonally to further improve precision.

* Dependence Analyses is a collection of dependence analyses: entry-based control, exit-based control, identifier-based data, reference-based data, interference, ready, synchronization, and divergence, required by analyses/transformations such program slicing and partial evaluation. Interference and Ready dependence analyses depend on the previous escape analysis while reference-based data and synchronization dependence analyses depend on object-flow information and the calculated call-graph information. Some analyses have varying levels of precision which can be varied via a well defined interface.

* Side-Effect Analysis provides method-level side-effect information. The user can query if any of the arguments/parameters to a call-site/method will be affected either directly (immediate members) or indirectly (recursively reachable members). Similarly, the user can provide a data access path rooted at arguments/parameters to a call-site/method and query if end point of the data access path is affected by the call/method.

* Monitor Anlaysis is a simple analysis that provides monitor/lock graph information for the given system.

* Safe Lock Analysis is an analysis that conservatively discovers if a lock (monitors) will not be held indefinitely. This information is used in conjunction with temporal dependences steming for Object.wait() and Object.notify()/ Object.notifyAll() as it is done in ready dependence.

* Atomicity Analysis provides information about atomicity in the given system. Current implementation relies on escape analysis to predict if a statement can be executed atomically. This information is used to detect atomic region of codes. This information is useful in applications such as model checking to reduce the the size of the state space, hence, improve performance.

Some analyses may be large enough to constitute module on their own and such analyses will be hosted as different modules in Indus rather than being consumed by this module.

Java Program Slicer module contains the core implementation of Java program slicer along with adapters that deliver the slicer in other applications such as Bandera and Eclipse. The implementation is architected as a library rather than as an application to facilitate the reuse of its subparts. The core is independent of the application; Each applications requirement of the slice can be satisfied by coding up implementations of post-processing interfaces and hooking in these implementations to form a customized slicer.

This module relies heavily on the information provided by dependence analyses and also the call-graph provided by OFA via well-defined interfaces that enables external implementations to be used for slicing.

This implementation of slicer is delivered to Eclipse with an intuitive UI via Kaveri plugin.

Features:o

Backward and Forward slice generation. Complete slices (union of backward and forward
slices starting from the same slice criteria) can be generated.

* Support to residualize (appropriate) slices into executable class files.
* Support for context-sensitive slicing via context rich slice criteria specification.
* Support to restrict the slice to a particular part of the system by scope specifications.
* Support to serialize slice criteria, slicer configurations, and slices.

All modules in Indus project work on Jimple, an intermediate representation of Java, provided by Soot toolkit from Sable group in McGill University. Each module in the project will be exposed as one or more Eclipse plugins if the provided information is useful to the user and amenable for user consumption via a graphical user interface.

Software Engineering Philosophy

Each module in this project will provide just the required functionality via well-defined interfaces that can be implemented to assemble a customized system with suitable extensions that fulfill specific requirement. As the interface is clearly separated from the implementation, any external implementation that provides the required interface can be seamlessly used with modules from this project.

Background

The implementation of most of the analyses was driven by the requirements of Java program slicer required by Bandera. However, as the program slicer could be used outside Bandera and the analyses could be used to enable other transformations such as program specialization via partial evaluation, we moved the analyses and transformations into a new project called Indus.

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.

Krita is a image editing and painting application for KOffice. The application is almost ready for use, and the architecture provides a solid framework to build an application on.
Because of the current unfinished state, Krita is not yet part of the regular KOffice releases, but the source is available from the KDE SVN repository. We hope to get Krita into a releasable state for KOffice 1.4.
Krita, like other KDE and KOffice applications, is free software which uses GPL Licensing. You enjoy the same rights to own, copy and modify this software with commercial and personal use, so long as you dont restrict the freedom of others to do the same.
Main features:
- Painting with brushes and colors
- Creating brushes from circles and squares
- Filling with colour and patterns
- Gradients
- Erasing
- Airbrush
- Simple geometric forms
- Many filters
- undo and redo
- Loading and saving of images in its native file format.
- Importing and exporting of images in all file formats supported by your installation of ImageMagick.
- Adding, removing, reordering and merging of layers.
- Layer transparency.
- Loading Gimp brushes, pipe brushes, gradients and patterns.
- Zoom.
- Color selection.
- Gray(A), RGB(A) and color models.
- Support for Wacom tablets.
- High-quality scaling
- Selections
- And much, much more
Or rather, what should it do, and what does it do already:
- brushes, drawing and layer editing tools (not complete)
- Color management using Little CMS
- RGB, RGBA and Grayscale color modes with adjustable color selectors. CMYK is implemented but buggy at the moment.
- Import/Export of png, jpg, xpm, tiff and bmp images, including color-indexed images. Import of gif images. (complete)
- an XML file format which saves and loads layer and channel information and full 32 bit image data (complete)
- color editing and selection tools (partly complete)
- dithering, transparency, blending and color reductions (partly complete)
- multiple views of the same image (complete)
- multiple images in the same view (complete)
- gradients and patterns (under development)
- cut,copy and paste between images and layers using rectangular area and other basic selection methods (incomplete)
- masking of selected regions during painting operations (under development)
- user-definable brushes (under development)
- adjustable zoom levels (mostly complete)
- scaling of images, selections and layers (incomplete)
- graphical access to layer and channel information (partly complete)
- import/export of xcf (Gimp) image files (complete, in as far as ImageMagick supports this)
- embedding in other KOffice apps (needs testing)
- user-oriented documentation of all the above basic functionality (incomplete)
- Scripting using kjsembed
Other planned features:
- HSV, Wet & Sticky and Wet Canvas color models
- image manipulation filters for advanced import/export
- wide range of region selection methods, including fuzzy selection and boundary detection
- scripting with the Python language
KParts architecture and plugins allow:
- plugins for effects and operation on images and selections
- additional tools
- additional filters
- components loaded as needed