<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br><div><div>Am 06.08.2008 um 00:19 schrieb Louis Desjardins:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">2008/8/5 "Christoph Schäfer" <span dir="ltr">&lt;<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;"> <div class="Ih2E3d">> Imagine the mess, now. Several layers into a master page... Where will this<br> > lead us?! (!!!!!!!!!!!!!!)<br> ><br> </div><div class="Ih2E3d">> Master Pages are in fact a locked layer. The containers (empty text and<br> > image frames) are locked. The content is uneditable and locked. This works<br> > perfectly and has a predictable behaviour, always. At least in Scribus.<br> <br> </div>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?</blockquote> <div><br>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.</div></div></div></blockquote><div><br></div><div>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. </div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><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;"><div class="Ih2E3d">...</div></blockquote></div></div></blockquote><br><blockquote type="cite"><div dir="ltr"><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;"><div class="Ih2E3d"><br> > We have this flexibiliy with stylesheets. We can edit endlessly any<br> </div>> stylesheet. We can go from idea A to B to C and then get back to A or A'.<br> <div class="Ih2E3d">> 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<br> > know this won't solve an issue such as being able to reposition the text or<br> > image frames *after* the pages are created, all at once in one go ? like it<br> > was asked recently on the mailing list. This would be the purpose of a<br> > Master Page in the old thinking. And it could well be the purpose of Frame<br> > Stylesheets in the new thinking. We could even extend this to Page<br> > Stylesheet... (is that feasible?)...<br> <br> <br> </div>If you create a page style, formerly known as master page, what problem does that solve?</blockquote><div><br>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.<br> </div></div></div></blockquote><div><br></div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Also, if master pages were created like styles (ie in a dialog), this would severly limit their use.</blockquote> <div><br>I am not following you. I see no limitation here.<br> <br></div></div></div></blockquote><div><br></div><div>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:</div><div><br></div><div>- unlock the MP object on the ordinary page, then edit it</div><div>- resetting some object properties would synch that property with the MP again</div><div>- deleting the object would remove the MP object from the ordinary page</div><div>- a new dialog would allow to re-add deleted MP objects to the ordinary page</div><br><blockquote type="cite"><div dir="ltr"><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;">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,</blockquote> <div><br>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.<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;"> and quick changes are one of the most siginificant reasons for edtable items on master pages.</blockquote><div><br>Just how quick can one edit a paragraph style and how quick can one enrich a styled text?<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><div class="Ih2E3d"> > We need a hammer *and* a screwdriver.<br> <br> </div>Like pages and layers? ;)</blockquote><div><br>Like static Master Pages and dynamic Page Styles.<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> <div class="Ih2E3d"><br> > We also need to be able to manage the links between text frames.<br> <br> </div>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.<br></blockquote><div><br>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.]<br> <br>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".<br> <br>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.<br> <br><br></div></div></div></blockquote><div><br></div><div>I have a proposal for that:</div><div><br></div><div>a) all objects get a "role" attribute, which might be empty.</div><div>b) text frames get an "auto-link-to" property which takes a rolename.</div><div>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. </div><div>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)</div><div>e) Manually linking frames overrides the "auto-link-to" mechanism.</div><div>f) Empty text objects from master pages are editable on normal pages and use the role/auto-link-to properties.</div><div><br></div><div>The current autotextframe functionality would be recoverd by creating those textframes with a fixed rolename on the master page.</div><div><br></div><div>Louis' scenario for bilingual text would be possible with this proposal.</div><div><br></div><br><blockquote type="cite"><div dir="ltr"><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;">> And we need to identify what is a styled frame and what is a regular frame.<br> <div class="Ih2E3d"> > I guess a styled frame would be locked by default. One could edit the<br> > content with no specific permission. To edit the position would require to<br> > go to the Style Manager... Of course, at any time, just like for any<br> > stylesheet, one could apply the "nostyle" attribute, thus setting this<br> > particular frame free. And this idea could be developed, of course.<br> <br> </div>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.</blockquote><div><br>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.<br></div></div></div></blockquote></div><br><div>But does a pagestyle just contain the dimensions (height, width, bleed settings) or also content?</div><div>For content our masterpages appear much more natural to me.</div><div><br></div><div>/Andreas</div></body></html>