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

Revision as of 22:42, 15 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

todo

Necessary for Feature Complete (ToDo)

todo

Nice-To-Have

todo