On Mon, 2008-03-31 at 04:41 -0400, bulia byak wrote:
- Reuse the Layers dialog for displaying and switching these page
containers as well, making them part of the overall layers tree
displayed in that dialog. In this way, each page may have its own
subtree of layers, but there may be shared layers that show up on all
pages, stored in master pages or in the content before the pageSet
(which is also treated as a background master page). Of course the
Layers dialog will have to treat such page-layers in a special way,
-- display them differently (font, color, autonumbering)
-- enforce that only one of the sibling pages is visible at a time: as
soon as the user switches to a page and makes it visible (perhaps for
pages, we can implement "clicking on name makes visible"), all other
pages are hidden, using the standard CSS visibility property as is
done for layers
-- when a page gets visible, its nearest preceding masterpage also
gets visible, all previous masterpages get hidden (as per the SVG
- In addition to Layers dialog, we'll also need a small page flipper
in the statusbar, next to the quick layer selector, hidden for
non-multipage documents; the quick layer selector should perhaps be
limited to the layers of the current page and the currently active
- Add commands like New page, Duplicate page, Delete page, etc.
This sounds like a fairly decent UI approach... and also could lend
itself to two other main usage. Those are animation and icons.
Animation could map 'frame' to 'page', but we do need to keep in mind
that animations can be time-based as much as they are frame-based.
Frame-based is the easy case, but time-based is the more desirable case
for the end users.
Icons can map versions to 'page'. So 16x16 4-bit would be one 'page' and
32x32 8-bit would be a second 'page' and 32x32 32-bit would be a third
I think the internals should be set up to support those three purposes
in a common way, but then the externals might have some visible
variation. So 'multipage' would appear noticeably different than 'icons
mode' yet still would be consistent with each other.
Also... looking at the end-user work view as possibly different than the
internals would allow us to adjust to changes in SVG print a little
easier. We'd just need to account for changes in SVG print to impact the
internals the same way that changes from multipage to multi-image icon
does. (That is, abstract what might change in a common way, and split it
apart from the aspects that will remain constant)