<div dir="ltr">2008/7/31 "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;">
Hi all,<br>
<br>
In reply to Louis' and Greg's recent postings:<br>
<br>
Louis:<br>
<br>
"What I am missing in this discussion is the many non-said things about<br>
Master Pages. We seem to assume too many things from our experience without<br>
naming them. To me, the first steps towards a solution to any issue, is to<br>
identify clearly the problem. I think this still needs to be done. So,<br>
before going into the "solution mode" we should establish clearly what the<br>
problem is, make a list of what we like in the current way and what we<br>
dislike or find unefficient."<br>
<br>
I hate do disagree, but the issue has been discussed for years now, on the ML, on the bugtracker and on IRC. Just read the logs or the archives. So there's no need to start from scratch. If anyone wants know what people try to do with master pages and why they want this feature, it can be easily searched for. I wrote that text as a reaction to Craig Bradney's comment that we should be clear on HOW to implement it.<br>
<br>
People want to _edit_ items on a page that are visible but placed on the master page. Use cases: last minute changes, quick changes like removing the page number for a certain page without having to create a new master page. Users want to move items between master pages and normal pages. Users want to create a basic item that shows small changes on different pages, for instance a coloured frame that has different text content etc. There are workarounds for some of these uses cases, of course, but a workaround is an idicator that something's missing. We have seen related questions over and over again. Why should we now start discussing anew?</blockquote>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Moreover, we kann dream up 1000 use cases, but we still can be sure our users will come up with at least 100 other ones we didn't contemplate. The purpose of my draft from the user perspective was to set no limits as to what a user can do, and I really think the approach is flexible enough, quite fast from a usability perspective, and also easy to use (in contrast to QXP and ID).<br>
<br>
Louis:<br>
<br>
"In other words, I respectfully think your proposal arrives too early in the<br>
process."<br>
<br>
No, it's rather late ;)<br>
<br>
Louis:<br>
<br>
"What I would propose instead, if I had the time and if I felt this issue to<br>
be a high priority would be to set a Google Doc such as a calc. sheet so we<br>
have a rows and columns document and I would state what we want to achieve<br>
in the rows and how it's implemented or if it is at all possible in current<br>
Scribus and in ID and QXP, and maybe another one (I can't think of now), in<br>
the columns. There could be a comment field for users and one for the coders<br>
so the various points of view are expressed. Of course, this table could be<br>
organized in any convenient manner so the ideas remain clears. What I say<br>
here is only a suggestion."<br>
<br>
Sounds quite complicated to me. We can discuss the issues here and then add to the bugtracker once they are resolved. Wouldn't that be easier?</blockquote><div><br>A table seems to me more convenient than flowing text, for this kind of discussion.<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>
Louis:<br>
<br>
"As I mentionned, it's been over<br>
20 years we have DTP apps and the Master Pages concept is still a<br>
work-in-progress. "<br>
<br>
I'd say it's a rather mature concept.</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;">
"This means it's a fairly complex issue and it also means<br>
that the way of implementing this is not as obvious as it seems."<br>
<br>
Hmm, what do you mean exactly?</blockquote><div><br>I will go over this rather quickly. I can complete later if needed.<br><br>There are actually 3 proposals out there.<br><br>Scribus' is tight and allows no change outside the Edit Master Pages.<br>
<br>Quark allows any changes to the Master Page once it is applied to any page and vice versa. What people miss here cruelly is a way to find out what object came from the Master Page and what didn't. And when they make a change on the wrong "page" (ie, the Document Page instead of the Master Page) not only those changes will not apply to all related pages but that very page they modified by error will not be affected by the Master Page changes while the user expect the opposite. Once the link to the Master Page is broken, there is no way back. Also, linking text boxes from within a Master Page is possible but the procedure is not obvious and for this reason many people prefer to do this by hand...<br>
<br>ID tried to solve the Quark dilemma and offers the possibility of making the Master Page and the page it applies to in a sync way or in an un-sync way. I am not familiar enough with ID to give a full explanation of how it works but I fully trust it's also a bit complicated... (outside the theory, in the real life, that is!).<br>
<br>The result of all this is often only power users make a proper use of Master Pages and even then they get mixed up sometimes. This is why I say it is a work in progress. The concept of Master Pages might be simple to be expressed in a few words, but when it comes to implementation, it is not that obviously simple.<br>
<br>Sorry to repeat myself but I do believe a summarizing table would help here. Once we have put that together and get our ideas straight, it's going to be a matter of choice and because of this, we will not make everyone happy.<br>
<br>The actual Scribus ways has drawbacks but Scribus is not alone on that field. The other two big players have drawbacks too.<br><br>The Scribus way has the merit of being completely clear. The other two are not as clear, although they seem to have more flexibility. And they actually do, in a way. But there is a steep price for this flexibility, sometimes.<br>
<br>(It's a bit like the PDF not being editable... It was not meant to be, but then people complained so much...)<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>
Greg:<br>
<br>
"Nonetheless, we have a prototype of what we<br>
might consider "editable" content with page numbering, so that anything<br>
editable might be considered in the same context, ie, not freely<br>
editable, yet allowed to incorporate a list of items/data that might<br>
change from page to page (something like using a database of some sort)"<br>
<br>
I doubt users would appreciate such an approach, as it's everything but obvious. It also sounds a bit complicated.<br>
<br>
Greg:<br>
<br>
"In that sense, Master Pages might be considered to align with content<br>
management of the likes of Drupal for websites."<br>
<br>
I don't know Drupal, but if you could elaborate, some good ideas may be derived from its concept.<br>
<br>
Greg:<br>
<br>
"Maybe Master Pages should be abandoned altogether, in favor of allowing<br>
all objects to have an attribute that allows them to appear on all<br>
pages, odd pages, even pages, or a list of pages. This would be a big<br>
change indeed, best put somewhere down the roadmap."<br>
<br>
Sounds complicated again, but who knows. I'd like to know more about the consequences. Also, master pages have been used for at least a decade, so I think the concept is familiar and even expected by many users.</blockquote>
<div><br>I think we have a couple of things to do. First, complete that documentation so people know what is going on and how to use this feature the way it work now.<br><br>The idea of abandoning the Master Pages will certainly raise a couple of eyebrows... Nonetheless, I would explore that path with much more confidence than trying to resolve a somewhat complicated equation where you want things to be static and dynamic at the same time... Or... we keep it as it is AND we add the Object Attribute...<br>
<br>By the way, when duplicating pages, if we could at the same time manage the text frame linking, it would solve another 5% of the cases where editable Master Pages are necessary... (should I file a bug report for this one?)<br>
<br>Object attribute... object attribute. I will give this more thoughts. Sounds very sane to me, and not that complicated (from the user perspective). Plus, it could then be part of a style sheet attribute... Even saner?! But this would mean that no matter where you are in your layout, if such an object is set to be "tied" with another one, a move on any page where that object is would affect the others... Glup! Maybe some more thinking is needed!<br>
<br>We have to think more.<br><br>Maybe what we need is the possibility to simply add content to an object created on the Master Page, while being in the Edit Document mode?<br><br>We need to summarize. We need a table to summarize the ideas that were expressed over the years in the bug tracker on Master Pages.<br>
<br>It's getting interesting, isn't it?<br><br>Louis<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;"><br>
<br>
Best<br>
<br>
Christoph</blockquote></div><br></div>