[scribus-dev] Editable Master Pages

[Andreas Vox]

Am 06.08.2008 um 23:08 schrieb Louis Desjardins:

> 2008/8/6 Andreas Vox <avox at arcor.de>
>
>> ...
>> 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?
>
> If there is more than one frame with the same role on a page, we  
> have to decide which one to take. That's why I propose a "top-to- 
> bottom in general and left-to-right if frames have the same y- 
> position" strategy.
>
> I am thinking of more possibilities but I realize it may be a  
> programming issue. Quark 7 doesn't allow more than one chain on one  
> MP. But this chain can be done with just about any number of frames  
> on that page. The first "frame" to link from is the upper corner  
> link icon that means every page created with this MP will be linked  
> to that chain.
>
> For many years we believe this is a limitation we'd like to see  
> disappear... It's not flexible in heavy layouts such as catalogues.  
> So we end up doing the linking by hand. It doesn't take that long  
> but in fact it is both feet on the brake to any further changes then.
>
>> 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.
>
> My proposal would allow automatic linking between pages with  
> different MPs. just the roles have to match.
>
> I understand but at the same time, we cannot have 2 stories running  
> side by side on odd and even pages. I understood the contrary when  
> you mentionned that the bilingual book scenario would be covered by  
> your proposal. How would you achieve such a book, then? Would that  
> be possible? There are quite a few collections made like that in  
> school edition, for instance.

Easy: on the left MP, create a textframe and give it the role  
"English-Text" and set the auto-link-to property to "English-Text".  
on the right MP, also create a textframe but set role and auto-link- 
to both to "French-Text". Voilà!

You could even place both textframes as columns on the same MP.  
Synching both stories would have to be done by hand, though.

>
>
>>
>>
>> 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.
>>
>
> Hm, that would introduce text links between masterpages. I dont  
> think that would work well, since you could apply the MP to a left  
> side but not the matching MP to the right side, so the link would  
> get broken.
>
> See my question above about the case of a bilingual book.

If there's no textframe with the right role, my proposal would just  
search the following pages for a fitting frame (or display the  
overflow marker if none found). Having a hard link from one MP to  
another would break if the MPs are not applied as a pair.

> I assume that anyone doing such a layout would know what he's doing  
> and would not create a case where a link would be broken. At the  
> same time, I don't really see what is the issue if a link ends at  
> some point. Actually, I don't understand what you mean here!
>
> Easiest to implement would be to disallow any manual links on MPs  
> (you can still simulate fixed links if you create unique role names).
>
> Are you saying here that even if manual linking is disallowed, it  
> will still be possible to link frames on a MP? I mean, without  
> automatic text frame linking? I think that in fact, this is a must!

Textframe linking on masterpages is a must? Maybe. But autolinking  
with roles is very flexible
if you are creative with the role names. Imagine an MP with these  
textframes:

name	role name        	auto-link-to
_____________________________________________
frame1	Autotext           	Frame2-On-MP
frame2	Frame2-On_MP	Frame3-On-MP
frame3 	Frame3-On-MP	Autotext

If you have a sequence of pages using this MP, the story would flow  
as expected:
frame1 - frame2 - frame3 -	frame1 - frame2 - frame3 - ...
     \____ first page ____/    	  \____ second page ____/


In this case the "Frame2-On-MP" role name replaces a manual link on  
the MP. Since the MP
has both link and target, it will never get broken.


More understandable that way?

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