Difference between revisions of "Source Code/branch alg writerframes"

Revision as of 15:48, 16 January 2014

branch alg_writerframes

Support of full DrawObject FillAttributeSet for Writer Frames

Frames in Writer support filling these. Currently 'no fill', 'fill with a Color' and 'fill with a Bitmap/Graphic' are supported. When Bitmap/Graphic is used, some alignments for the content to the frame are possible. There is no way to use the identical set of fill attributes as for DrawObjects, e.g. no Hatch or Gradient support, plus many missing configuration options. This includes having different UIs for the same purpose. Historically this is probably the case since Writer was the first application existing for AOO and noone ever adopted to the broader possibilities of DrawObjects.

It would be nice to have the same set of fill attributes all over the office, in cases where the same target has to be achieved. This would unify the usage and for the future make extending these easier.

The motivation to this task came from the OSBA task 5.1 where it was requested to support Gradients in Writer Frames to enhance the compatibility with other formats. Exactly that was achieved, Gradients were added, keeping the non-uniform fill attribute set for Writer Frames in it's basic form with just Gradients added. The needed UI extension to add this property was added to make this accessible to the users via UI.

This will make a request for the still missing graphic fill possibilities (e.g. Hatches or other mapping modes for Bitmap/Grahic fill) only a question of time, also a lot of data is still handled unequally within the office:

• The UI is different for Writer Frames and DrawObjects
• The Core data is unequal
• The FileFormat representation is not exchangeable/copyable (as XML should be)
• The output (Print/PDF/Others) is unequal (e.g. still not exporting SVG content as vector data, but as Bitmap)

All this made me think about starting to implement the full set of fill attributes which DrawObjects support for Witer Frames. This will allow unified handling with many advantages. If e.g. in the future SVG Gradients will be implemented, it will be not necessary to do this for two data core sets/UIs and all the exporters.

Current State

This is work in progress (hence it's in a branch) and will need more work fine-tuning. A lot of bigger and smaller problems showed up during the first implementation started (as usual). Following are three sections; an overview what is already working, a section collecting necessary changes before this feature will be ready for trunk and one describing the nice-to-have things.

Already Working

From user POV:

• When creating or selecting a Writer FlyFrame, the Sidebar will offer the Area Panel to allow modification of all FillStyle and Transparency settings known from DrawObjects

• Using the 'More Options' button in the Sidebar's Area Panel will open the full-blown Area Dialog, including the Color/Gradient/Bitmap/Hatch defining pages. All these work, any Bitmap/Graphic can be added to the FillAttribute standard set.

• Sub-FlyFrames created inside the original will inherit their parent's FillStyle (when they have no own one). The original mode to show the 'continued' filling of that parent for the child is perserved, quite some Primitve definitions had to be adapted to allow that. This is good since these modes are useful for future options, too. None of the renderers had to be adapted at all, thanks to primitives.

• Print works as usual, but with increased quality due to the Primitive usage. This is especially true for FillStyles using Metafiles or SVG content, these are printed as vector graphic now.

• PDF export also profits from this, equal to Printing.

• When loading a current ODF Writer file the former fill definitions for FlyFrames can be seamlessly adapted to the new FillStyle definitions, no loss will happen. One caveat is that the DrawObject FillStyles do not support linked graphics, that aspect will be removed.

• When loading a ODF Writer file created with the branch version, all formerly used available FillStyles will be preserved; this is possible since the trunk version does save the new FillAttribute set and also the older one to be backwards compatible. This will be done for a while and can be removed in a later version (e.g. AOO 5.0). When using new possibilities this cannot be offered, but what is possible is done.

• When using the Frame Attributes Dialog for a Writer FlyFrame (context menu/Menu/DoubleKlick) the 'Background' TabPage is replaced by the 'Area' and 'Transparency' TabPage pair. This pair is needed since the full FillAttribute set contains the transparency aspects (an also be seen in the Area Panel of the Sidebar).

• When working with FrameStyles in Writer, the same TabPage pair is used. All FillAttributes can be also defined in that Styles herarchy. With all the FillAttributes being independent, single Attributes, the granularity to define the FillStyle for Writer FlyFrames is much improved.

• When using the Frame Attributes Dialog where not the full range of TabPages of the full-blown FillStyle dialog is used, a 'Import Graphic...' button is added to the bottom of the Area TabPage in Bitmap mode to allow easy and simple direct selection of any Graphic/Bitmap file. This can also be used in other cases where not the full-blown dialog is used (OLE, Chart, ?). It may even be useful to always use this handy feature in all usages of the Area TabPage. The difference to 'Import...' on the 'Bitmaps' TabPage is that the imported graphic is used, but not automatically added to the standard FillSet of the user (which would blow up his private definitions over time).

• todo: not sure if I described all alraedy working things...

From developer POV:

• Describe internal changes/modifications/unifications

• todo

Necessary for Feature Complete (ToDo)

• Im/Exporters to other formats (in Progress)

• todo

Nice-To-Have

• Just checked (with some temp modifications) if it would be possible to even use linked graphics. Save and reload works, but no link in ODF. The XFillBitmapItem uses a GraphicObject which allows that; the graphic import dialog offers links, too. What does not work is the recognition as linked graphic when as fill attribute (edit/links... not grayed out), also ODF export adds as non-linked graphic. Hint: It may be possible with some more effort to make linked graphics work as fill attribute, if really wanted.

• Thought: the added direct "Import Graphic..." button in the Area TabPage in Bitmap mode may be useful even for all other usages of the full FillStyle dialog. I originally planned this only for the mode with the TabPage pair of Area and Transparency.

• todo