[scribus-dev] Editable Master Pages

[Andreas Vox]

Am 06.08.2008 um 00:19 schrieb Louis Desjardins:

> 2008/8/5 "Christoph Schäfer" <christoph-schaefer at gmx.de>
> > Imagine the mess, now. Several layers into a master page... Where  
> will this
> > lead us?! (!!!!!!!!!!!!!!)
> >
> > Master Pages are in fact a locked layer. The containers (empty  
> text and
> > image frames) are locked. The content is uneditable and locked.  
> This works
> > perfectly and has a predictable behaviour, always. At least in  
> Scribus.
>
> I don't think this is correct. Currently, a layer outside the  
> master page is a document layer, not a page layer. And why  
> shouldn't users use layers in master pages? Who are we to tell them  
> they shouldn't?
>
> I didn't say they shouldn't. People do just what they want! I only  
> said it was not much in use among DTP pros (although I am sure you  
> will find dozens who do, but that proves nothing, really). This of  
> course is from my little experience.

Well, right now all master page objects are placed below any ordinary  
objects. We could change that so that MP objects of layer X are  
placed below ordinary objects of layer X, but above ordinary (and MP)  
objects from layer X-1.

>
> ...

>
> > We have this flexibiliy with stylesheets. We can edit endlessly any
> > stylesheet. We can go from idea A to B to C and then get back to  
> A or A'.
> > Maybe what we are looking for lies in stylesheets, not Master Pages?
>
> > When I say, use the Page > Copy as a workaround to editable  
> Master Pages, I
> > know this won't solve an issue such as being able to reposition  
> the text or
> > image frames *after* the pages are created, all at once in one  
> go ? like it
> > was asked recently on the mailing list. This would be the purpose  
> of a
> > Master Page in the old thinking. And it could well be the purpose  
> of Frame
> > Stylesheets in the new thinking. We could even extend this to Page
> > Stylesheet... (is that feasible?)...
>
>
> If you create a page style, formerly known as master page, what  
> problem does that solve?
>
> The Master Page remains as it is, static. The Page Style has all  
> the benefits of any other style. It can be edited and applied at  
> will. People can apply it, and change their mind.

I dont understand the use of "static" here. You can already apply and  
re-apply master pages at will. If you edit the MP, all pages that use  
it change, too.

The only thing that's static is that MP objects look exactly the same  
on each ordinary page, minus page numbers. That's a limitation which  
we need to address, at least for text content (eg. no text content on  
MP -> text object is editable on normal page; MP object has text  
content -> text object is static (minus page  numbers) on ordinary  
page). That's the minimal solution.

Making MP objects editable on the ordinary page (without changing the  
MP definition, that would be insane!) is the maximal solution. My  
proposal was to reuse the styles technology and the locking mechanism  
here.

>
> Also, if master pages were created like styles (ie in a dialog),  
> this would severly limit their use.
>
> I am not following you. I see no limitation here.
>

A dialog as in style manger is inappropiate for master pages IMHO. 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
- resetting some object properties would synch that property with the  
MP again
- deleting the object would remove the MP object from the ordinary page
- a new dialog would allow to re-add deleted MP objects to the  
ordinary page

> Of course we could say that we're going to have page styles for the  
> page itself and object styles for items on a page, but that would  
> make quick changes impossible,
>
> Still not folllowing you. Say you have a styled text. You can still  
> enrich that text, decide to apply another style or no style, etc.  
> Just the same would happen in a page style.
>
> and quick changes are one of the most siginificant reasons for  
> edtable items on master pages.
>
> Just how quick can one edit a paragraph style and how quick can one  
> enrich a styled text?
>
> > We need a hammer *and* a screwdriver.
>
> Like pages and layers? ;)
>
> Like static Master Pages and dynamic Page Styles.
>
>
> > We also need to be able to manage the links between text frames.
>
> What does this mean in the context of master pages? I don't think  
> no one would permit linking text frames on master pages to text  
> frames on real pages. That would be insane, IMHO.
>
> In its actual form, the only way to create a text frame that will  
> be automatically linked to another on another page is to check the  
> "automatic text frame" option at document creation. Then, when you  
> go to Page > Insert, the new inserted pages will have a text frame  
> and this frame will be linked to the one on the previous page, and  
> to the one on the next. [And this works not that elegantly as I am  
> testing for the purpose of the explanation — will have to file in  
> some bug report.]
>
> To be able to decide which frame is the one to be chained to when a  
> number of pages are created, or to be able to decide which two  
> frames or which three frames create a chain is what I call "being  
> able to manage the links between text frames".
>
> That way you could have 2 stories running side by side, for  
> instance, in auto text frame. You could have as many as you want of  
> those text frame chains. You could also set an entire text (for a  
> bilingual book, for instance) with auto frame on and linked to odd  
> pages, while the even pages get the EvenPage Style and get also an  
> auto text frame. So, Spanish on odd pages and Russian on even pages.
>
>

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)
e) Manually linking frames overrides the "auto-link-to" mechanism.
f) Empty text objects from master pages are editable on normal pages  
and use the role/auto-link-to properties.

The current autotextframe functionality would be recoverd by creating  
those textframes with a fixed rolename on the master page.

Louis' scenario for bilingual text would be possible with this proposal.


> > And we need to identify what is a styled frame and what is a  
> regular frame.
> > I guess a styled frame would be locked by default. One could edit  
> the
> > content with no specific permission. To edit the position would  
> require to
> > go to the Style Manager... Of course, at any time, just like for any
> > stylesheet, one could apply the "nostyle" attribute, thus setting  
> this
> > particular frame free. And this idea could be developed, of course.
>
> Yes, but keep in mind the number of mouse/keyboard operations. This  
> sounds to me like a lot of clicking, which would defeat the idea of  
> quick changes.
>
> Don't worry. I always keep in mind the mouse/keyboard operations.  
> And I think so far that Page Style is a path to explore with lots  
> of curiosity and interest.

But does a pagestyle just contain the dimensions (height, width,  
bleed settings) or also content?
For content our masterpages appear much more natural to me.

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