[scribus-dev] Editable Master Pages

[Louis Desjardins]

2008/8/6 Gregory Pittman <gpittman at iglou.com>

> Louis Desjardins wrote:
>
>> 2008/8/6 Andreas Vox <avox at arcor.de <mailto: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
>>>    <mailto:christoph-schaefer at gmx.de>>
>>>
>>
>> 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 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.
>>
> 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.


Isn't the actual behaviour fine? It seems pretty straightforward, no? Select
first frame, select the chain tool, click on second, click on third, click
on fourth and then click outside any frame to end the linking process.


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


I am not sure to understand your idea here. The main purpose of managing
links is to set the behaviour of a frame (or frames) on a page that will
then be used as a MP, so other pages could be set the same *and* linked one
to another. So, really, it's only a matter of setting in a few steps the
behaviour of a "master frame" for an entire document. With the idea of have
a specific attribute for this, we have the possibility to create as many
chain as we need, from page to page.

I am not sure that naming/renaming the frames will be faster or easier than
using the actual link/unlink tools and I am not sure either that this will
be more intuitive than having this new possibility of link-to attribute
Andreas is talking about.

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


As far as I can tell, people are expecting to be able to
a) _put content_ into a frame that would have been created only once on the
MP
b) _reposition or resize_ this text frame on the MP, so the changes made
reflect through the entire document (where this particular MP was used),
without affecting their content (other than how it is framed).

One issue is dealing with exceptions — the quick changes Christoph is
talking about. Thus, based on a given MP, you have this particular page
where you need a frame to be modified a bit, without affecting the overall
layout. The actual way won't allow this, of course. And in XPress, doing so
will de-sync that element from the MP and thus further changes made to that
MP will not affect that page. And you also have no mean to know this unless
you experience it or you read the manual! In QXP, the MP element are no
different than the regular page element once you are on a page. ID has come
up with a re-sync option and all this proves to be not-so-obvious to work
with although in theory, it seems to be.

If we work it out with the Style technology, small changes like that would
not de-sync such a frame. In fact it would be this style+ just like adding a
word in italic into a styled paragraph set in roman. But we could also not
prefer to implement such a solution for other drawbacks I can't think of
now.

It is clear there is a need for much more flexibility and the ability to
make round trips while establishing the layout. Going back and forth, trying
and testing, all this is a big part of the creation process.

Louis

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