Future of Master Pages

From Scribus Wiki
Revision as of 19:59, 6 August 2008 by Malex (talk | contribs) (New page: Category:Scribus_development == The discussion about the future development of Master Pages == === Scenarios/Proposals === {| class="wikitable" border=1 width="80%" |- ! Scenario || ...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

The discussion about the future development of Master Pages

Scenarios/Proposals

Scenario Proposal Comments


Running summary from scribus-dev at lists.scribus.info

# Author Text Comments
1 Christoph list all master pages in the page list, so that the master page can be directly edited by selecting it in the list. This would have the same effect as selecting the master page in the Document Outline. Avox: Yes, that sounds very sensible.
2 Christoph have a button beside the page
list that would open the master page of the currently selected page for
editing. Again, technically the same as opening in the document outline,
except that the user doesn't have to find out which master page is used for
the current page.
Avox: Yes, that sounds very sensible.
3 Christoph When it comes to editing an item only on the current page, there should
be a second button to switch on the editing mode for master page items on
the currently selected page.
4 Christoph There should also be a spin box to set the opacity of the actual page content, so that users can check how changes to the master page will affect the layout as a whole. Default should be 0%, so that the content is invisible. Avox: I don't follow your opacity explanation there.

Christoph: Perhaps it is clearer if you download the PDF file that's attached to the original posting. My idea was to edit a master page while the original page is still visible. The user could set the degree (transparency) of the visibility.

5 Christoph To disconnect an item from the master page and use it only on the
current page, one could use the "Send to Layer" feature: Each document has
at least one layer, so that sending the item to "Background" (or any other
layer in the current document) should be enough to remove the item from the
master page.
Avox: That's unintuitive I think.

Christoph: If properly documented, I think this would be rather intuitive, because it simply extends the concept of layers (see my reply to Greg).

Louis: Paradoxal. Intuitive means one can figure out the feature by oneself, without reading the manual. At least for experienced users.

Christoph: No. In DTP, nothing is "intuitive". Just remember the many questions regarding very basic operations. "Intuitive" in this context means that there's one way to do it in a certain program (here: the many page features and layers), which can also be followed with other features (master pages).

6 Christoph Once the editing is finished, the user would have to click on the edit
button in the status bar again. Scribus would then bring up a dialog similar
to the current "Apply Master Page" dialog.
Options:
  • Apply Changes to the Current Page
  • Apply Changes to the Master Page
  • Apply to all Odd Pages (ie. those that use the master page)
  • Apply to all Even Pages (ie. those that use the master page)
  • Apply to the following Pages: (ie. those that use the master page, single pages and range)
Avox: Too complicated IMHO

Christoph: Again, this is just the extension of an already existing concept, ie, applying master pages to existing pages. In this case it would just be bit different: applying changes to master pages. From experience I know that people learn things easier, when the concepts seem familiar.

7 Greg Pittman Maybe Master Pages should be abandoned altogether, in favor of allowing all objects to have an attribute that allows them to appear on all pages, odd pages, even pages, or a list of pages. This would be a big change indeed, best put somewhere down the roadmap. Christoph: 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.

8 Avox "From object styles to master objects"


On our roadmap we have the extension of the current inheritable style system from char/paragraph styles to line styles, table styles, cell styles, frame styles, ... to object styles.

A style is just a collection of settings, where each setting can be set or not set. If a setting is not set, it's inherited from the surrounding element (char settings from the paragraph style, paragraph settings from the document).

That's the situation without named styles. When the "based on" field contains the name of a style, undefined settings are taken from that style instead of from the surrounding element.

Ok, so let's say we have object styles which describe all settings of a pageitem, including position (normally we wouldn't want that in a style, but read on).

Now, instead of using a named object style for an object, we could also change the masterpage mechanism such that page items have a "based on" property which points to the corresponding master page item. Those page items would be fully editable locally. Changing the corresponding master page item would automatically change the settings of the descendant page items, unless they were redefined locally. Similar to the "Broom" Button for paragraph styles there would be an option to reset all settings to the masterpage item's defaults.

Applying a masterpage to a page would mean creating additional objects on the page which are based on the corresponding master page items. Those items would be locked by default, so editing a masterpage item locally means unlocking that item first. There should be another lock mode which fixes all settings except for content (text or images).

Deleting such an item would remove the item just from this page. There should be an option to recreate items which were deleted that way.

Applying another master page would remove the additional objects unless they were changed locally. Locally changed objects would stay on the page but loose their automatic masterpage connection (or they could be deleted anyway, what do you think?).

That mechanism should also work for hierarchical masterpages (is there already a feature request for this? :-) ) and for more than one masterpage per page. Come to think about it, it's also very similar to Inkscape's clone objects.

9 Terry Green (through Gregp) Thanks for the advice, will try and work round the problems with extra

master pages etc, one thing with the way they work in Indesign is I could put all the text boxes I needed on the Master page and set the different styles for each text box ie; Font Style,Size,Color,Fill color etc, then when I enter text into it on any page based on that master the styles and formatting and everything else with that text box or Image box stays the same, maybe Scribus in the future may have these features, it sure saves a lot of time.

10 Greg Pittman I don't know that changing Master Pages to meet his "needs" is a very good

answer. It sounds to me that what he really might want to use is a Template, or actually just a template page. Maybe this could be in some way linked to a Master Page, but I think that it needs to be a separate layer.*

As I look at 1.3.3.13svn, I see that you can't insert a page from a Template - at least I couldn't seem to make it work when I tried to import a page from one. Furthermore, there would need to be some facilitated way to find templates from the Import Page dialog - I found it because I knew where to look.

I think this may be only a slight modification of current capabilities, and therefore not so much of a coding challenge.

  • This of course brings up possibilities of other kinds of external

linking from Master Pages that might serve other purposes - even though a Master Page cannot be (easily) edited, something that links to it might be.

MrB: Actually, this is how master pages would work anyway in the future. A frame on a master page will be able to be formatted, so any text typed into it on a normal page will take up those settings unless overridden on that normal

page.

Templates are somewhat broken and need reimplementing anyway - I would not start to base any functionality on those that depends on the current operation/look or that would confuse two commonly mixed up phrases like master and template pages.

11 Louis Scribus' is tight and allows no change outside the Edit Master Pages.

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

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

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.

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.

The actual Scribus ways has drawbacks but Scribus is not alone on that field. The other two big players have drawbacks too.

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.

(It's a bit like the PDF not being editable... It was not meant to be, but then people complained so much...)

12 GregP Well, it would seem to make sense to me to have a listing/table which in

one column lists scenarios in which the current implementation of Master Pages is a roadblock or completely unintuitive. Another column indicates either the desired use or the intuitive approach, and trying to stay with the layout concept rather than conceiving of a particular software solution.

Hopefully, such scenarios can be real ones from the mailing list or from people's experiences rather than theoretical ones. Theoretical uses have no boundary, but at some point we have to be reductionists.

In a sense, Master Pages represent a special layer. Why can't they be more like a regular layer? Why can't the things you can do with a Master Page be applied more generally -- perhaps have the ability to apply all the objects on a given layer to as many pages as you want.

One might argue that this defeats the purpose of a Master Page, but it is appropriate to ask if Master Pages as they currently exist are even necessary.

13 Christoph Now, instead of using a named object style for an object, we could

also change the masterpage mechanism such that page items have a "based on" property which points to the corresponding master page item. Those page items would be fully editable locally. Changing the corresponding master page item would automatically change the settings of the descendant page items, unless they were redefined locally. Similar to the "Broom" Button for paragraph styles there would be an option to reset all settings to the masterpage item's defaults.

Applying a masterpage to a page would mean creating additional objects on the page which are based on the corresponding master page items. Those items would be locked by default, so editing a masterpage item locally means unlocking that item first. There should be another lock mode which fixes all settings except for content (text or images).

Hmm, this seems to have a lot of potential, but how would you go the other way, ie, adding an item from a current page to the master page or a range of them? And is there a way to remove an item from a master page on a real page without deleting the master page?

Deleting such an item would remove the item just from this page. There should be an option to recreate items which were deleted that way.

Would recording it in the Action History not be enough?

Applying another master page would remove the additional objects unless they were changed locally. Locally changed objects would stay on the page but loose their automatic masterpage connection (or they could be deleted anyway, what do you think?).

I predict a lot of confusion if we do this ;)

That mechanism should also work for hierarchical masterpages (is there already a feature request for this? :-) ) and for more than one masterpage per page. Come to think about it, it's also very similar to Inkscape's clone objects.

Yeah, that would be a great extension, but maybe we should resolve the basic issues first.

14 Louis Also, layers may be well used in image editing but in DTP, believe me, they

are not. And I doubt this is going to change. People might get the concept rapidly (after all, a layer is a layer and this is easy to catch) but they often don't have a clue about the real use and benefits — and drawbacks, of course, of layers.

Christoph: They are used a lot, of course. I don't know of you, but for testing bugs I must have downloaded dozens of sla files, and I guess 40% of them

contained layers.

15