MHonArc v2.5.0b2 -->
office message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Proposal for copy-frames
Hello,
here's a proposal for an extension to the file format.
I would like a way to model copy-frames. This is for having multiple frames
that represent the exact same underlying data, i.e. perfect copies of one
another, and always so. If the user changes the text or picture in one of the
frames, it affects all the other frames that are "copies" of that one - much
like headers and footers, for instance.
This can be used for text boxes but also for picture frames: for instance for
a company logo, that must appear somewhere on every page, without being
inlined into a page header (which would be currently the only way of doing
it). But if the logo has to be somewhere on the left side of the page, a
header won't help. If you imagine a company logo _and_ the company name in a
text frame, this would be an example of when this feature is also needed for
text boxes.
My proposal for the file format change is:
in order to know which frame is a copy of which other one we would use
something similar to the the frame chaining model (draw:chain-next-name, see
9.3.1), where a frame specifies the name of another one it follows.
In this case, a frame would specify the name of the frame it's a copy of,
with e.g. <draw:frame draw:name="logo-2" draw:copy-of="logo-1" ...>
So, if I get the syntax correctly, the addition would look like:
1) adding <ref name="draw-frame-attlist"/> to draw:frame (line 6153)
2) defining it as
<define name="draw-frame-attlist">
<optional>
<attribute name="draw:copy-of">
<ref name="string"/>
</attribute>
</optional>
</define>
3) changing the oneOrMore inside draw:frame's definition into a zeroOrMore,
since a copied frame doesn't have any contents definition by itself,
it copies the contents of the "copy-of" frame.
Discussion on alternatives:
I believe this is a more flexible model than saying "put a copy of this
on pages 4 to 15, at position (x,y)", because the various copied-frames
don't necessarily have to be at the same position on every page.
Another way to do the same would be to include multiple positions and sizes
in a single draw:frame. This would allow to use a single name for the whole
set of frames and to avoid the 'zeroOrMore for the contents' above; but then
it's not really a single draw:frame anymore, more like a frameset (KWord's
term). Text framesets with multiple frames are currently modelled with
chained frames in the Open Office format, so I'm suggesting to keep it that
way and simply add the copy-of attribute to frames.
PS: typo in 9.3, schema line 6158/6159, draw-text-box is referenced twice from
draw-frame.
--
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]