[scribus-dev] Editable Master Pages

[Andreas Vox]

Am 06.08.2008 um 15:06 schrieb Louis Desjardins:

> 2008/8/6 Andreas Vox <avox at arcor.de>
>
> No need to change the GUI here, except for how to enter MP mode.  
> For un-synching / synching the user would have to do the following  
> in my proposal:
>
> - unlock the MP object on the ordinary page, then edit it
>
> Contextual menu.
>
> - resetting some object properties would synch that property with  
> the MP again
>
> We need a small dialog so we see the properties? or can be through  
> a contextual menu too, what do you think?
>
> - deleting the object would remove the MP object from the ordinary  
> page
>
> Right.
>
> - a new dialog would allow to re-add deleted MP objects to the  
> ordinary page
>
> Where would you like the user to be then? On the MP, right-clicking  
> on the object, making the dialog appear and have the option to put  
> it back on page X or more? Something like that?
>

I'd say the user has to be on the page where he deleted the object in  
the first place.
Like a context menu on the page background or some normal menu which  
would give you a list of deleted MP objects to choose from.

> ...
> I have a proposal for that:
>
> a) all objects get a "role" attribute, which might be empty.
> b) text frames get an "auto-link-to" property which takes a rolename.
> c) when a text frame which has the "auto-link-to" property set  
> overflows, Scribus automatically links to the next object with the  
> same role as the specified "auto-link-to" name.
> d) The next object is found by looking for objects which are placed  
> below the current object on the current page or which are on top of  
> a following page (yes, that means the text would reflow if you  
> reorder two auto-linked frames on a page. And it's not so easy to  
> create textframe links that run against the page order)
>
> In essence, I agree with this proposal. But I am not thinking of  
> any top/below hierarchy, either on the same page, or on different  
> pages, to set the link-to frames because from what I understand the  
> user have not all control on the text flow. Is that right?

If there is more than one frame with the same role on a page, we have  
to decide which one to take. That's why I propose a "top-to-bottom in  
general and left-to-right if frames have the same y-position" strategy.

> But I follow you on the main idea of this "role" attribute and the  
> "auto-link-to". Once a MP is created with all its frames, some will  
> be linked to all pages bearing the same MP and some will not.

My proposal would allow automatic linking between pages with  
different MPs. just the roles have to match.

>
>
> 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.
>

Hm, that would introduce text links between masterpages. I dont think  
that would work well, since you could apply the MP to a left side but  
not the matching MP to the right side, so the link would get broken.
Easiest to implement would be to disallow any manual links on MPs  
(you can still simulate fixed links if you create unique role names).

/Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20080806/49cf3afb/attachment.htm>