Future of Master Pages
The discussion about the future development of Master Pages
Scenarios/Proposals
Editing objects on master pages for one or more particular regular pages.
This table is still empty and will be until a working agreement is reached about the scenarios and proposals to solve them.
| #/Author | Scenario | Proposal | Comments |
|---|---|---|---|
| 080812/a.l.e | layout of a multilanguage flyer (same layout, partially adapted images, content may have small differences in length | t.b.c. | |
| 080813/a.l.e | synchronise columns in side by side translated text | set a mark in both text and they will be set at the height of the later one (they could be set for the titles) | t.b.c. |
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:
|
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"
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.
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. |
Christoph: The problem is that a master page may contain several layers. 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. Louis: Imagine the mess, now. Several layers into a master page... Where will this lead us?! (!!!) (SEE #18 for a counter proposal) |
| 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 | Unknown (to me) | 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. | Christoph: 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?
Louis: 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. Avox: 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. |
| 16 | Unknown (to me) | 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. | Unknown: 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.
Louis: Static because the elements that are on the MP can only be edited on the MP. No possible tweak on the regular page. |
| 17 | Unknown + Louis | > 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. I follow you on the second part of your sentence but on the first, I have some reserve. Putting content in a text frame does not affect the structure (ie, the text frame doesn't move). In XPress, putting text into a frame won't de-sync that frame and I can only guess it is the same in ID. What de-syncs an element is when you modify its shape or position on the page. I agree that the minimal solution would be to let users put content into a text or an image frame that would have been first created on the MP. As a side note, I trust that doing so would take care of a high percentage of the complaints, questionning or frustrations we hear about the MP. Sure, people would want even more flexibilty, but once this minimum is addressed, I am sure we'll hear less noise! |
|
| 18 | Louis | 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. 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. 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. 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?)... 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...) Repeat: Master Pages in Scribus are sane. 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. We also need to be able to manage the links between text frames. 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. 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. By the way, the stylesheet concept has already been thought of nearly 2 years ago... http://bugs.scribus.net/view.php?id=4606 Only, I would keep the static Master Page as they are, and use the stylesheets as described above. |
Gregp: Maybe having a Copy To... function would help -- where you could copy to
the same page with particular coordinates, a different page with the same or different coordinates, all pages, or a range/selected pages. I don't have a fixed opinion about this idea of being able to edit one copy then have all of them sync together -- maybe the best thing there would be to use the Action History to go back to the point before you did a Copy To..., edit the original, then Copy To... once again. OR, have a dialog with a list of objects in the document, where you can click one or a number of them and carry out a collective operation, including delete -- perhaps just adding capabilities to the Outline dialog. Avox: 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. 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 Louis: Static because the elements that are on the MP can only be edited on the MP. No possible tweak on the regular page. I follow you on the second part of your sentence but on the first, I have some reserve. Putting content in a text frame does not affect the structure (ie, the text frame doesn't move). In XPress, putting text into a frame won't de-sync that frame and I can only guess it is the same in ID. What de-syncs an element is when you modify its shape or position on the page. I agree that the minimal solution would be to let users put content into a text or an image frame that would have been first created on the MP. As a side note, I trust that doing so would take care of a high percentage of the complaints, questionning or frustrations we hear about the MP. Sure, people would want even more flexibilty, but once this minimum is addressed, I am sure we'll hear less noise! I agree. Styles would allow the maximum flexibility. Gregp: I think you also have to think about streamlining the process. For one thing, without changing the way links work, they could be easier to work with. Make the linking something like making a Bezier curve, where you activate linking, then left click, left click, left click, then when you're done, right-click or ESC to end linking and turn it off, with a message or tooltip to tell you this. As far as auto-linking, maybe there should be some semi-automated naming of frames, so that you could have families of text frames with similar names (think of the way that KSnapshot helps with naming screengrabs by automated numbering: eg, snapshot.png > snapshot1.png > snapshot2.png, and so on). This would facilitate auto-linking. It might also allow for rearranging the linking simply by changing names of the frames. What about the idea of having, for example, an empty text frame on a MP, which in a sense "links" to an editable frame on a regular layer on every page where that MP is used. The content could be edited in the usual way, but you could go to the MP and change position and size, which then would change the position and size of the editable frame on the editable layer without changing content. Could/should you be able to change position/size on the regular layer? Perhaps, but you'd have to decide whether this might change the frame on the MP -- might be a problem, and perhaps might "break" this MP link, at least on that page. I'm trying to think in the terms of the complaints that people seem to have, but also preserving the "integrity" of the MP. Avox: I'd rather see something like in Pagemaker: clicking on the overflow indicator goes into link-mode. Shift clicking will create new textframes as necessary. Unlinking is available via context menu. I think role names are a cleaner approach than some elaborated naming scheme. |
| 19 | Avox | 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. |
|
| 20 | Christoph | Editing means just that: everything they could do to with an object on a regular page. This includes deleting an item or moving it to the regular page (which is the same as desynchronising). | Christoph: There's nothing more we need to address
Louis (??): 1. Changing MP objects locally on the regular page goes somewhat against the spirit of master pages, so this will be discussed some more I think. It might be worthwhile to have restrictions on how MP objects can be cahnged, eg. just filling in content instead of changing size / shape / position / color / whatever. 2. Desynchronized MP objects can be a burden: quick changes sometimes hamper the possibility to edit the document in the long run. After all the main purpose of master pages is to give a set of regular pages a consistent look. Christoph: 1. Do you think Scribus should offer a more fine-grained approach, ie. with (customisable?) restrictions/permissions? 2. Desnychronised object would simply be regular objects that are no longer connected with their master page, no? Why would regular objects become a problem. Avox: 1. I think a too fine-grained approach would be too much. Currently you can lock the position separately. I think we also need a lock option that locks anything but the content. Another intermediate option might allow additional stuff that covers most user's needs (position, size, fill color, visibility, columns, text style?) 2. Only in so far as you get into problems when you don't work with MPs to keep your work consistent. Not a problem per se, but it goes against the purpose of MPs. |
| 21 | Christoph | Perhaps a user would want to add an item from a regular page to a range of master pages or a static master page. I don't know why someone would do this, but you never know what users come up with. | |
| 22 | Christoph | How can a user access an item (or more) on a master page quickly without having to jump through many loops? | |
| 23 | Christoph | How will the changes be applied?
|
Christoph: What part of the object style would be related to the status on the master page? Do you mean a special option? Would there be a special object style for items on a master page? I think Louis' idea with setting the status via context menu would be easier and faster. Or maybe there should be both options? |
| 24 | Christoph | As for using styles, master pages are already styles in a sense: change a style and all text/lines with that style will change, change one MP, and all pages that use the MP will change. I agree that one could use the style "mechanism" like overriding styles with local formatting, but this has a serious drawback, which is already hurting us: if a paragraph style is being changed or another style is applied to the text, what happens to the local changes? Which one is preferred, the new style or the local change? There is no easy answer, and that's why I don't think the style mechanism should be used. It just gets in the way for quick changes and is probably overhead. | |
| 25 | Christoph | Louis' idea of using the context menu is correct, but we should keep in mind that it's already quite bloated. My purpose was to use existing features that are already there, ie. layers. Detaching objects from a master page by moving them to a document layer is quite easy. Frankly, I don't care if DTP people did fine without layers for years. The technology is available in Scribus, it works
reliably, and it's known to our users (and will be fully documented in the manual). Why not use it to save time and provide something easier than InDesign's insanely complex way? It would take four mouse clicks to detach an object ort to delete it
|
Louis: A context menu can be less bloated in a given context. We can strip it down in the MP context, for instance.
It would be great to explain what works and what doesn't in the "insanely complex way" of ID. |
| 26 | Christoph | The same goes for editing items:
I can't think of anything easier. |
Christoph: The linking of text frames is IMNSHO totally unrelated to editable master pages. This should be discussed in a separate thread. Andreas' idea of roles is probably the way to go, but before that can be introduced, the linking of text frames should be fixed and brought on par with ID. That will be enough work, I think, for the near future. Andreas has quite a few great ideas here, IIRC. In this context, we probably also need to discuss changes to the page numbering, as we'd need to be able to have parallel numbering schemes for facing pages with different languages. I think there's already a bug report for this. |
| 27 | Louis | Well, for paragraph styles, the most common change is enriching text.
Nothing to hurt. I agree however that changes to a MP could be far less trivial and thus it may not be advisable to have this Style+ I was thinking about. But before throwing the idea away, I would still consider it and give it a second thought. After all, it is up to the user to determine what he wants on the MP. He'll see right away if the change made is in contradiction with his own layout. So, in fact, I see no real problem to the Style approach. Which one is preferred, the new style or the local change? Good question. It could well be an option. And if it isn't, I am still inclined to think the Style+ way is fine. |
|
| 28 | Louis | There are tons of case scenarios where linking is important at MP level and where it does save lots of time. The importance of this will also increase as Scribus text handling capabilities get better. Text formatting for one thing could be done in one single "formatting" document (just like galleys used to be) and then this formatted text could be copied and pasted to an entirely structured and linked empty "layout" document. Being able to link text frame in the MP can save hours of work, depending on the complexity of the document. Catalogs, for one piece of work, with lots of text levels and formatting can be done in days instead of weeks. | Gregp: We clearly need to reduce much of the rigidity of MPs, so that changing
one's mind about a layout doesn't end up being a lot of undoing and redoing of time-consuming work. I think it's also clear this is not just a matter of tacking on a bunch of new functions to MPs. |
| 29 | Avox | I think usability 1 can be discarded, no approach should be noticably
slower or faster than any other. For the first criterium you have to keep in mind that development time is also correlated to coding fun :-) ( difficult -> more time needed and more fun to implement) I'd like to add usability 3: long-term intuitivity. Some MS products have features which are fast to learn, but they are so stupid that I forget how to use them right away.
Please note that my assessment is independent of the UI (what context menu / editing mode / buttons / palettes are needed). For any approach there are different UI options which might affect learning curve, long-term intuitivity and consistency. I'm also convinced that the "just content editing" would cover more than 80% of user requests. So I vote for implementing that and reserving the style-based approach for version 1.5+ |
Gregp: It's hard to know if I agree with the assessment, yet nonetheless I like it, though I'm worried about this 'high' assessment of learning curve for
the style-based approach. Hopefully there might still be some basic "MPs for Dummies" operations that could be very simply used, like page numbering or putting banners on pages. Louis: > I'm also convinced that the "just content editing" would cover more than > 80% of user requests. I am convinced of this too. > So I vote for implementing that and reserving the style-based approach for > version 1.5+ This sounds pretty reasonable to me. I second this with enthusiasm! |
| 30 | Avox | In response to comments on Christoph's #20.
Ok, time to elaborate on my styles mechanism: The way I see objects they can be divided in three parts (item paginarum est divisa in partes tres): * Content: either text or image or none
flow-around-options, linestyle and fill color, role, attributes, text style, image settings
lock status Named object/frame styles should IMO only affect the properties for the Frame/Shape part. They would basically work just like paragraph styles (allows to set object style, local overrides, has broom action to revert to parent style). These object/frame styles would contain other styles as substyles (eg. paragraphstyle for text, image style for image settings, line style for frame, fill style/pattern for background) just as paragraph styles contain a character style. So far this has nothing to do with master pages. Now imagine a super object style, which contains *all* object properties. We wouldn't name those styles, but instead place them as objects on a masterpage. When you apply this masterpage, on the regular page Scribus creates one object for each master object, and sets that master object as parent to the regular object. Automatically the regular object would inherit all properties of the master object, except for its page affiliation and maybe its name. That's what I mean with using the style mechanism for master pages. Those super object styles would not be edited with the style manager; they would be edited as master page objects, just like they are now. But they would use the inheritance mechanism to synchronize with the masterpage. Masterpage objects on a regular page would now be regular objects which use a super object style. Technically it's possible to override locally any setting from the super object style (the masterpage object). That's why I would create those items locked when I apply a masterpage. Unless they are unlocked, they would behave exactly as masterpage items behave now. Please understand that this is just the technical side of master pages. It would allow all possibilities as in InDesign and maybe more. The number of clicks might be different, though :-) The operations needed to edit an MP object would be: 1. editing content works exactly as for regular objects 2. other proerties: (position, size, shape, etc.): a) use the context menu on the regular page to unlock the MP object b) edit the MP object on the regular page c) optionally lock the MP object again. If the MP object is changed on the master page, the regular object will receive all changes except for the properties that where edited locally. The context menu of the regular MP object would have an additional "broom option" which would reset all local settings to the default on the MP.
>> Frankly I don't like that approach. I don't want to tie the MP >> concept with the layers concept. > > Well, in a sense it already is, since one can use layers in master > pages. > Yes, but is has no meaning for MPs, it's orthogonal. I want layers to work independently of MPs. I think ID does is right: if you use layers on the MP, the MP items of that layer get sorted just beneath the regular page items of the same layer. So you have layers on regular pages, you have layers on MPs, and applying a MP with layers just stacks the items in sequence: MP items layer 0, regular items layer 0, MP items layer 1, regular items layer 1, ... |
Going the KISS way (the "Scrapbook" approach)
The whole discussion on the mailing list has taught me, that handling dynamic content in a master page is a difficult matter which hasn't been done right in any DTP software.
This proposal tries to figure out, how this goal can be achieved using -- mostly -- features which are already implemented in scribus (following the rule to Keep It Simple... Sir).
In short:
- The master page contain elements which are exactly the same on every page based on it
- The master page can contain variable content like the page numbers
- The scrapbook contains elements which can be modified after having been inserted into the document
- It should be easy to add to the scrapbook elements at a fixed position
- The elements inserted are independent from one another
- Those elements are not updated if the scrapbook item changes
- There should be a way to apply changes and formatting to all similar elements (based on the way filters are created and applied to emails).
Features and limits of the Master Pages
The master pages are basically ok as they are and will contain elements which are identical on every page based on them.
There could be some enhancements:
- There may be some more variables like the page numbers.
- There may be several "versions" of a master page which get applied when a predefined condition is met: first page, left page, right page, last page.
Role of the scrapbook and enhancements needed
The elements inserted from the scrapbook aren't linked to the "original" element in the scrapbook: if the original gets changed, the element remains in the state it was as it has been inserted or as it has become after being modified in the context of the page it has been inserted into.
In order to be able to use the scrapbook as a replacement for more dynamic master pages, a new lock status has to be added: "Lock position". If its position is locked, the object will be inserted from the library will have exactly the same position as it had at the moment when it has been added to the scrapbook.
I propose to leave only one lock button in the Properties Palette:
- which will full lock/unlock the frame if clicked
- and -- if the mouse is kept clicked -- shows a context menu with the following items (checked / unchecked):
- lock size
- lock position
- lock content
Notice: Personally, I'd prefere not to have that small triangle. It's acceptable here since it does what a basic use wants when clicking on the button: lock and unlock (only the extra functionality is hidden).
There could be some further enhancements:
- It should be possible to edit the scrapbook items in a virtual page (opened by right clicking on the element in the scrapbook, without inserting it into a page first and recopying it into the scrapbook afterwards).
Context aware scrapbook
The element in scrapbook which relate to a master page, may only be shown when the current page is build on the related master page.
Tagging, Selecting and Batch Processing
A tag system could be built on the the base of the attributes editor. And every frame could get be assigned a set ot tags.
This could be implemented as a plugin.
A separate plugin implements a way to select and batch process frames based on their tags and some other characteristics. This plugin will work in a similar way as the filter editors in the mail programs:
Another KISS way (the "prototype" approach)
Forget automatic synching for the time being (according to Louis the confusing part anyway)
Master pages contain two kind of items: background items (that's the kind we have now) and prototype items. When applying a masterpage to a regular page, copies of the prototype items are placed on the regular page with size and position initially locked. Those copies can be edited in a normal way.
When a regular page is displayed, Scribus will render only the background objects from the masterpage and then the objects from the regular page (normal ones and the copies of prototypes).
In effect the objects based on prototypes are automatically detached. One could provide an option to manually synch them with their prototypes, either on a per-object basis or when the masterpage is re-applied.
In a later Scribus version we could use the style-based approach to keep objects in synch with their prototypes (manually synch would correspond to the broom function of styles)