Comment 1 Michael Wenz 2011-03-08 10:02:42 EST

I did an check how the classes are used, here are the results:

DefaultPrintFeature:
- Implements IPrintFeature with hooks for pre- and postPrint operations
- Is registered and returned by the DefaultFeatureProviderWrapper and
  AbstractFeatureProvider
- The feature gets an IPrintContext object containing only a (by default empty)
  property set
- The IPrintContext object is only used for the pre- and post hook --> as of
  today the behaviour in the print cannot be influenced
- By returning null for the print feature in the feature provider, printing can
  be disabled completely
- What could be done inside the feature?
	- The diagram could be changed:
		- Not so good an idea: print should from the user perspective not
                  change a diagram
		- Revert changes in postPrint hook? - Basically possible, but
                  practical?
		- By doing this, elements in the diagram could be made not 
                  printable or additional elements (e.g. copyright) could be added
		- Is this the right or desirable way to do this?


DefaultSaveImageFeature analogous

Comment 2 Michael Wenz 2011-03-09 06:58:59 EST

Potential usecase for pre-hook:
Change the selection in the diagram for save selected elements or print selected elements (e.g. add the connections between selected shapes).

Comment 3 Michael Wenz 2011-03-11 04:06:37 EST

The save image context has a property pictogramElements which is filled on starting the save operation with the currently selected PEs but never used inside. The selected objects can be easily retrieved within the feature, the property could be removed.

Comment 4 Michael Wenz 2011-03-11 07:00:16 EST

The existence of the 2 features makes perfect sense in order to enable tool builders to hook into the process of printing or saving a diagram as image. The basic functionality to enable this exists, nevertheless only some modifications by tool builders are supported (like changing the selection inside the diagram).

Nevertheless it makes sense to leave the functionality in and be open for future extensions in this area. These should be triggered via seperate enhancement requests.

I cleaned up the implmentations of the features, documented the currect possibilities in the JavaDoc and removed the stuff that is not supported (see comments above).

Changes have been checked in to head.

Michael

Comment 5 Michael Wenz 2011-06-24 09:09:25 EDT

Part of Graphiti Indigo 0.8.0