# Double precision changes

## Branch aw080

This page is part of the documentation for the aw080 branch for the Apache OpenOffice project (incubating). The main page can be found [here]

## Double precision changes

Changes that influence the used number format, mainly changes from unsigned 32-bit to floating point, including usages of Linear Algebra solutions for object transformations.

**SdrObject geometric definitions changed to basegfx classes**

This is the change of all geometry definitions at SdrObjects to double precision, e.g. using basegfx::B2DVector, basegfx::B2DPoint, basegfx::B2DPolyPolygon or simply double values as needed. Nearly all interfaces in DrawingLayer adapted to use these, all usages adapted in all applications and implementations.

**SdrPage geometry changed to double precision (size, borders)**

The PageSize and it's border definitions are no longer based on integer, but on double precision. The page size is called PageScale now and is a basegfx::B2DVector. All interfaces adapted to this, all usages, too. There are some usages of this, all calculations based on page size and all interaction adaptions e.g. limitations to page and surrounding area needed to be adapted.

**All Interactions overhauled, all on double precision**

All implemented interactions in Draw/Impress, Writer and Calc are adapted to double precision. Classes partially reimplemented based on new basegfx base classes. All snapping, cropping, grid calculations, edges of other objects, page boundaries and other stuff transferred to double precision. All stuff from other usages adapted as far as needed, still some work to do here.

**All object creators revamped to double precision**

All object creators (when activated an object insertion from the object toolbar) adapted or partially reimplemented for double precision. Same snapping and precision as the interactions.

**All snapping/alignment reworked**

All snpping to grids, forcing to angles, aequidistant modes (pressing SHIFT) and other stuff adapted to double precision.

**Extended basegfx matrix tooling (UNO converters, buffered decompositions, …)**

The matrix tooling in basegfx was extended for converters for UNO API classes like Matrix, sequence of points and other useful stuff. Base classes to have a basegfx::B2DHomMatrix in it's combined form and buffered in it's decomposition were added, this is e.g. used as member in SdrObjects so that it is not necessary to get the matrix, decompose each time just to get e.g. object scale (size). Convenience methods at SdrObject hand out these directly, e.g. the method getSdrObjectScale(). Caution: Of course this scale can be negative in aw080, expressing that the object is mirrored in X and/or Y, so it may be necessary to get the absolute of the vector.

**PresObj creation completely transfered to new SdrModel paradigm and adapted to double precision**

All default object creation for the Title/Content logic on MasterPages and Pages in Draw/Impress, their layout and handling were changed to use double precision and new mechanisms.

**SdrHandle creation and lifetime revamped, double precision adaption**

All classes for SdrHandles were relayouted, members checked and changed, adapted to double precision, adapted to transformations and hungarian notation.

**UI elements adapted (Helplines, etc.)**

All DrawingLayer UI elements like helplines, grid, extended cursor on object move, object replacement during interacion and others are adapted to double precision and the changed SdrObject/SdrModel paradigm, also using transformations.

**Drag and create methods adapted to double precision**

All interactive methods for creation and/or modification of SdrObjects are adapted to double precision and do manipulate SdrObjects by using transformations. This allows real interactive mirrorings where e.g. the evtl. contained text can be seen mirrored during the running interaction without tricks.

**GluePoint handling changed to always be relative to object in unit coordinates**

As described SdrObjects have an implicit unit coordinate system ranging from (0,0) to (1,1). Thus, glue points use this definition now too. Unfortunately there is a 'Distance from Edge' mode for them which needed special treatment, but this is possible and done. This makes handling much simpler, e.g. to get the discrete position (Pixel coordinates) of a GluePoint in a view just multiply it's unit coordinates (e.g. 0,0) with the object transformation and with the ViewTransformation from the used OutputDevice.