[scribus-dev] Editable Master Pages

[Louis Desjardins]

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

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

Great!

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

Understand.

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

Indeed. It is cristal clear! I believe this is a nice way to address this
task.

Thanks!

Louis

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