Source Code/branch alg writerframes

From Apache OpenOffice Wiki
< Source Code
Revision as of 11:18, 7 May 2014 by Aw (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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

The branch has been reintegrated to trunk in r1579280. It is stable and has fallbacks for the im/exporters to exactly do what these have done before. These fallbacks are asserted, so the work to do is to enhance these im/exporters accordingly. This can now be done in trunk, after the beta and release branches for AOO4.1.0 are created.

This is work in progress in the sense that there is some work to do to refine it. To better find problems which are still present a reintegration now to trunk is the best solution, this also will make working in parallel somewhat easier.

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, Gradient, Color or Hatch can be added to the FillAttribute standard set and be used for fill, same for transparency, including transparency gradients.
  • 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. To allow that a minor aspect of the 'Position' FeatureSet for DrawObjects had to be expanded (and is also available for all DrawObjects in the future): When not Tiling and not AutoFitting, the Positioning allows the alignment of the graphic (the Left/Center/Right/Top/Bottom setting).
  • 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. PDF files may get bigger in size due to the increased quality.
  • 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 in the transistion. More about this can be found in the Nice-To-Have section below.
  • 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. In Detail:
    • FillColor: completely converted
    • Gradients: export a mid-color in old format
    • Hatches: if filled, export FillColor; if not, hatch color and 50% increasted transparency are used
    • Graphics/Bitmaps: all modes work, except when Tiled the old format has to be aligned top-left; this is the only mode supported by the former fill styles
    • Linear Transparency: Works for all modes additionally
    • Gradient Transparency: A medium value transparency is used calculated from the transparency gradient
    • Note: When using Metafiles or SVG the transparency is exported, but the current Writer cannot display this; to check correctness a look in the Dialog and the 'Background' TabPage is required. This is an error in the current version which will be gone with this change.
  • 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 now instead of 'Background'. All FillAttributes can be also defined in the FlyFrame Styles herarchy. With all the FillAttributes being independent, single Attributes, the granularity to define the FillStyle for Writer FlyFrames is much improved. Backward compatibility with FlyFrame styles uses the same mechanisms described above for load/save.
  • 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 already working things...

From developer POV:

  • Describe internal changes/modifications/unifications. To be able to work more simple with the changes corresponding to this task, all places which were changed and still need e.g. adding comments or remove out-commented code are tagged with the string 'UUUU', just grep for it (taken over from aw080 where I use TTTT for this). These will be replaced with comments or removed when this task is done.
  • todo

Necessary for Feature Complete (ToDo)

  • Im/Exporters to other formats (in Progress)
  • Due to issue 124638 the described adaptions are in question to be done also for OLE and Grap0hic frames; in the future this will anyways be needed to be done when we want to unify GraphicObjects closer between DrawingLayer and Writer, so this should be done. It should be done aligned to the task provided.
  • todo


  • 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.
  • Also checked if it is possible to replace the fill graphic with a link in ODF (in the styles section) and this is supported at load time, thus the possibility to also support linked graphics for fill style bitmap gets higher. Missing is probably to export these as links and to keep them as links during office lifetime. It may also be nice to support to break these links, too and there is also the aspect to have these in the user-specific list of Bitmap FillStyles (is it possible to have them as links there, too?).
  • 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.
  • Thought: All this may also be applied to the Writer's PageFill.
  • Added improved export of Gradients and Hatches; details see User's View above
  • todo
Personal tools