<div dir="ltr">2008/8/2 "Christoph Schäfer" <span dir="ltr"><<a href="mailto:christoph-schaefer@gmx.de">christoph-schaefer@gmx.de</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In reply to Greg:<br>
<br>
"Hopefully, such scenarios can be real ones from the mailing list or from<br>
people's experiences rather than theoretical ones. Theoretical uses have<br>
no boundary, but at some point we have to be reductionists."<br>
<br>
I don't think so. We have proven ways to work with Scribus quite flexibly. Why not adapt them to master pages?<br></blockquote><div> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
"In a sense, Master Pages represent a special layer. Why can't they be<br>
more like a regular layer? Why can't the things you can do with a Master<br>
Page be applied more generally -- perhaps have the ability to apply all<br>
the objects on a given layer to as many pages as you want."<br>
<br>
The problem is that a master page may contain several layers.</blockquote><div><br>Imagine the mess, now. Several layers into a master page... Where will this lead us?! (!!!!!!!!!!!!!!)<br><br>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.<br>
<br>Maybe the problem is not named correctly? Thus, it may lead us to think the issue is the Master Page. It may well be elsewhere. The issue now is to allow going back and forth while editing the layout, from idea A to B to C then back to A or A', endlessly. And this of course defeats the idea of the Master Page concept. If a Master Page can be further edited downstream, this can have many effects on the operations downstream too. Such as proofreading, quality control, and finally, printing. And costs, of course.<br>
<br>Because the problem is not well identified, the solutions will always be akward. ID has come up with a complicated sync and de-sync options, while QXP has not solved the issue of the de-sync'ing... Maybe the solution doesn't lies there? I don't pretend to have the solution. I am only asking questions at this point.<br>
<br>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?<br>
<br>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?)...<br>
<br>Really, what people want is more flexibilty on one aspect while they need stability on the other. In my opinion, trying to achieve both goals with the same tool might just lead us nowhere. We need a hammer *and* a screwdriver. We need duct tape *and* a wise-grip. And $100 can't hurt too! (joke from IRC...)<br>
<br>Repeat: Master Pages in Scribus are sane.<br><br>What we need is to find a way to position a frame precisely somewhere on a page and be able to create a 1000 pages with the same layout and then be able to change our mind and position this frame somewhere else, with precision, without altering the content. If there is no content yet, then Page > Copy is the way to go.<br>
<br>We also need to be able to manage the links between text frames.<br><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">My proposal tried to extend the current implementation of layers to avoid the mess seen in QXP and ID by listing layers in master pages separately (they'll need a visual indication) and to move items between layers on real pages and layers on master pages or even complete layers if the user wants to do that. The Document Outline is one place to do this easily, but there could be others (eg the Layers dialog if layers should be moved to between regular pages and master pages.</blockquote>
<div><br>In my opinion, layers have to remain what they are. This is already something to deal with them. Let's not complicate the concept more and more. Honest, we will never see the end of this. Bad idea.<br><br>By the way, the stylesheet concept has already been thought of nearly 2 years ago...<br>
<br><a href="http://bugs.scribus.net/view.php?id=4606">http://bugs.scribus.net/view.php?id=4606</a><br><br>Only, I would keep the static Master Page as they are, and use the stylesheets as described above.<br><br>Hope this helps.<br>
<br>Louis<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Christoph<font color="#888888"><a href="http://www.gmx.net/de/go/multimessenger" target="_blank"></a></font><br></blockquote></div></div>