[scribus-dev] Editable Master Pages
gpittman at iglou.com
Wed Aug 6 16:49:21 CEST 2008
Andreas Vox wrote:
> Am 06.08.2008 um 15:53 schrieb Gregory Pittman:
>>> 1. The frames that will be linked need only to be tagged as "to be
>>> linked" to the *same* frame on *next* page to which this particular
>>> MP would be applied. That way, you can set as many chain of text
>>> frames as you need.
>>> 2. The frames that are un-tagged are created on each page too but
>>> are not linked.
>>> 3. Plus, you can also set 2 or more frames to be linked together on
>>> a single page, but not to the next page.
>>> 4. And finally, you can have a set of frames in a structure where
>>> all those frames are linked together on a single page and are also
>>> flowing in the next set of identical frames on the next page. That
>>> is, the last frame in the chain gets a tag to be linked to the next
>>> first one of the chain on the next page.
>>> The same can be done on facing pages. With the particularity that we
>>> could set the links to run on the full sequence of the pages, 1-2-3-
>>> or 1-3-5 and 2-4-6.
>> I think you also have to think about streamlining the process. For
>> one thing, without changing the way links work, they could be easier
>> to work with. Make the linking something like making a Bezier curve,
>> where you activate linking, then left click, left click, left click,
>> then when you're done, right-click or ESC to end linking and turn it
>> off, with a message or tooltip to tell you this.
> I'd rather see something like in Pagemaker: clicking on the overflow
> indicator goes into link-mode. Shift clicking will create new
> textframes as necessary.
> Unlinking is available via context menu.
>> As far as auto-linking, maybe there should be some semi-automated
>> naming of frames, so that you could have families of text frames with
>> similar names (think of the way that KSnapshot helps with naming
>> screengrabs by automated numbering: eg, snapshot.png > snapshot1.png
>> > snapshot2.png, and so on). This would facilitate auto-linking. It
>> might also allow for rearranging the linking simply by changing names
>> of the frames.
> I think role names are a cleaner approach than some elaborated naming
>>> e) Manually linking frames overrides the "auto-link-to" mechanism.
>>> If we are to create a new dialog for managing links, I would be
>>> incline to think of a way to link two frames that are far from each
>>> other in the page range, such as "Top Story on Front page" >
>>> "continued on Back Page" and be able to set the link from this back
>>> page frame (or on any page) to the front page frame from within that
>>> dialog instead of having to run the link through all pages with the
>>> mouse. But this is a tweak!
>>> f) Empty text objects from master pages are editable on normal
>>> pages and use the role/auto-link-to properties.
>> What about the idea of having, for example, an empty text frame on a
>> MP, which in a sense "links" to an editable frame on a regular layer
>> on every page where that MP is used. The content could be edited in
>> the usual way, but you could go to the MP and change position and
>> size, which then would change the position and size of the editable
>> frame on the editable layer without changing content.
> We already need a separate copy of the content for each MP textframe
> because of pagenumbers,
> so it would be more natural to reuse the MP textframe, just with local
>> Could/should you be able to change position/size on the regular
>> layer? Perhaps, but you'd have to decide whether this might change
>> the frame on the MP -- might be a problem, and perhaps might "break"
>> this MP link, at least on that page. I'm trying to think in the terms
>> of the complaints that people seem to have, but also preserving the
>> "integrity" of the MP.
> AFAIU that's the core of the MP-usability question, ie. the point
> where people disagree.
> My position is:
> a) if we allow changing position or other properties of MP items on
> the normal page, use style inheritance to link to the original MP object.
> b) never change the MP original when editing a normal page (not sure
> if you meant it that way,
> but it sounds like it)
> c) definitely allow to change content of MP objects on the normal page.
Yes, I pretty much agree with everything you're saying.
More information about the scribus-dev