Box Structure

The API cross references give an immediate access to relevant interfaces and classes.

Box Structure

We make no distinction between composite objects and leaves. The glyph concept is a key one as it acts as the fundation of the composite structure. A node of the whole-part hierarchie knows about its parent and children. On the other hand leaves require a specific attention.

Here is our position on safety and transparency in composite.

Atoms

Atoms are the leaves of the box structure. They do not have children and provide the basics of formatting and drawing tasks. As an application may use many of them, their storage cost is really sensitive. The naive design (unshared atom) is well suited for unusual terminals. When you think in term of key-word then you should use instead the DecoratedSharedAtom.

Here are some implementation issues relative to text drawing in java relevant to the design of atoms.

For common use, the shared atom is the only way to deal with big structure. To do that, each objet shares as much as possible of its state. The extrinsic part (origin, parent, ...) can't be share, but the intrinsic part (text and size) is stored in a flyweight. A flyweight registry maintain a list of all shared flyweight. We use reference counting to remove unused objects. When formatting a shared atom, first we ask the registry for the given value (string or character code) in the given font before allocating a new one.

Updates

The box structure updates are made through the visit of a modification path. The path building visitor is used during the building stage. The mark stable/mark unstable operation allows the synchronization of the formatting and building threads. The path modification visitor is used during the interactive updates. This visitor computes the damaged area from removed or replaced boxes. The boxes are also tagged for incremental formatting.

• inserting a new child
• removing a child
• replacing a child with a new glyph
• marking a glyph as stable (i.e. ready for format)
• marking a glyph as unstable (i.e.e not ready for format)

Glyph

A glyph is an abstract notion representing all objects that we manage in a document. They know how to draw themselves, how much space they need, their relationship with their parent and children, how to interact with the user and how to manage exceptional situation.

Also a glyph knows how to manage its origin, its size, its format status its modification tag. As the size is a computed value, a glyph could manage a dependent (i.e. an object that needs to be notified when the size changes) and provides access to the current size value, to the accurate value (eager value) or lazy value (accurate value if there is no previous old value).

The main point is to maintain the components as small as possible since each attached information could have a major impact on derived classes. Heavy used concrete classes likes atoms share extrinsic information like size and datas.

API Cross References

• Interfaces:
  • [PENDING : links to the developer manual]
• Classes:
  • [PENDING : links to the developer manual]
• Exceptions:
  • [PENDING : links to the developer manual]