[scribus-dev] Editable Master Pages

[Louis Desjardins]

2008/8/6 Andreas Vox <avox at arcor.de>

>
> Am 06.08.2008 um 00:19 schrieb Louis Desjardins:
>
> 2008/8/5 "Christoph Schäfer" <christoph-schaefer at gmx.de>
>
>> > Imagine the mess, now. Several layers into a master page... Where will
>> this
>> > lead us?! (!!!!!!!!!!!!!!)
>> >
>> > 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.
>>
>> 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?
>
>
> 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.
>
>
> 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.
>
>
> ...
>>
>
>
>> > 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?)...
>>
>>
>> If you create a page style, formerly known as master page, what problem
>> does that solve?
>
>
> 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.
>
>
> 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.
>

Static because the elements that are on the MP can only be edited on the MP.
No possible tweak on the regular page.

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

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

I agree. Styles would allow the maximum flexibility.

>
>
>
>> Also, if master pages were created like styles (ie in a dialog), this
>> would severly limit their use.
>
>
> I am not following you. I see no limitation here.
>
>
> A dialog as in style manger is inappropiate for master pages IMHO.
>

Sure. It may have not been that clear from my part! I didn't mean a dialog
"à la Paragraph Styles". But we do need some way to access some of the
specific options so that an object can automatically appear on a range of
pages. That "dialog" could be a contextual menu. And at some point we will
need a bit more. But of course, the "drawing" of a MP should be done just
like working on a page.

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
>

Contextual menu.

>
> - resetting some object properties would synch that property with the MP
> again
>

We need a small dialog so we see the properties? or can be through a
contextual menu too, what do you think?


> - deleting the object would remove the MP object from the ordinary page
>

Right.


> - a new dialog would allow to re-add deleted MP objects to the ordinary
> page
>

Where would you like the user to be then? On the MP, right-clicking on the
object, making the dialog appear and have the option to put it back on page
X or more? Something like that?

>
> 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,
>
>
> 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.
>
>
>> and quick changes are one of the most siginificant reasons for edtable
>> items on master pages.
>
>
> Just how quick can one edit a paragraph style and how quick can one enrich
> a styled text?
>
>>
>> > We need a hammer *and* a screwdriver.
>>
>> Like pages and layers? ;)
>
>
> Like static Master Pages and dynamic Page Styles.
>
>>
>>
>> > We also need to be able to manage the links between text frames.
>>
>> 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.
>>
>
> 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.]
>
> 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".
>
> 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.
>
>
>
> I have a proposal for that:
>
> 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)
>

In essence, I agree with this proposal. But I am not thinking of any
top/below hierarchy, either on the same page, or on different pages, to set
the link-to frames because from what I understand the user have not all
control on the text flow. Is that right? But I follow you on the main idea
of this "role" attribute and the "auto-link-to". Once a MP is created with
all its frames, some will be linked to all pages bearing the same MP and
some will not.

1. The frames that will be linked need only to be tagged as "to be linked"
to the *same* frame on *next* page to which this particular MP would be
applied. That way, you can set as many chain of text frames as you need.
2. The frames that are un-tagged are created on each page too but are not
linked.
3. Plus, you can also set 2 or more frames to be linked together on a single
page, but not to the next page.
4. And finally, you can have a set of frames in a structure where all those
frames are linked together on a single page and are also flowing in the next
set of identical frames on the next page. That is, the last frame in the
chain gets a tag to be linked to the next first one of the chain on the next
page.

The same can be done on facing pages. With the particularity that we could
set the links to run on the full sequence of the pages, 1-2-3- or 1-3-5 and
2-4-6.


> e) Manually linking frames overrides the "auto-link-to" mechanism.
>

Agree.

If we are to create a new dialog for managing links, I would be incline to
think of a way to link two frames that are far from each other in the page
range, such as "Top Story on Front page" > "continued on Back Page" and be
able to set the link from this back page frame (or on any page) to the front
page frame from within that dialog instead of having to run the link through
all pages with the mouse. But this is a tweak!


> f) Empty text objects from master pages are editable on normal pages and
> use the role/auto-link-to properties.
>

Agree.


>
> 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.
>
>
> > 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.
>>
>> 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.
>
>
> 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.
>
>
> But does a pagestyle just contain the dimensions (height, width, bleed
> settings) or also content?
> For content our masterpages appear much more natural to me.
>

I think we must be able to put content too, just like we can now.

Louis


>
> /Andreas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20080806/c157e7ed/attachment-0001.htm>