View Issue Details

IDProjectCategoryView StatusLast Update
0003672ScribusGeneralpublic2017-10-19 16:20
Reportermkoren Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status feedbackResolutionopen 
PlatformanyOSanyOS Versionany
Product Version1.3.3.1 
Summary0003672: object sequences with relative properties
DescriptionI think it would be generally useful to have support for ordered sequences of objects with related properties. E.g., allowing a string of objects to automatically keep a fixed gap between them even if you change the size of one, or keeping a group of objects equally spaced around a circle as you add or remove members.

In general a sequence would be an ordered group in which the properties of each element, including position, size, or any other attribute, could be defined relative to the previous element or in terms of its index number in the sequence. So you could say "the height of this object is 10% more than that of the previous one" or "the rotation of this object is n * 15 degrees" where n is the element number, etc.

Any of the align and distribute settings, for instance, including requested features like 0000923, 0000924, and 0000344, could be applied persistently to a sequence, as well as rotation offsets, group reflections, and the like, simply through proper sequence definitions.
Additional InformationI think that with appropriate options for nesting, relative positioning (by gaps, definable anchor points, etc.), and content flow these would allow a wide range of user-definable constructs that would greatly simplify managing complex documents. These could be saved and reused as styles, and could possibly reduce the need for some specialized built-in functionality.

This could could encompass lots of desired features like customizable schemes for formatting equations and music, managing multi-story linked text chains, on-canvas imposition, and text-anchored marginal notes.

I suspect we could come up with a lot more.... :)
TagsNo tags attached.
Patch

Relationships

related to 0003708 feedback group-level inheritance of defaults and style definitions 
child of 0003812 acknowledged Metabug: Grouped objects 

Activities

mkoren

2006-04-23 00:26

reporter   ~0010349

I'm including a mockup screenshot to show how sequences could be used to automate formatting of mathematical texts, including equations and marginal notes, as well as define complex line styles and text flow modes. I want to emphasize that none of the formatting styles shown here would require any more specialized functionality from scribus besides positioning and formatting objects in sequences, as I've attempted to show in the mock style and object browsers on the sides (which however you should probably ignore at first for simplicity :).

I hope it's clear how I'm using sequences in these examples; ask me if not. :) I'm applying the concept very generally to all sorts of placement and formatting, including frame-, line-, and text-based layout.

I think that the capability to define complex styles using sequences in this way could really add a whole new layer of power and flexibility to scribus as a layout application, by allowing users to automate exactly the kinds of relationships they use frequently in a document, with only the addition of this single relatively simple concept. Existing and planned features such as tables, columns, and possibly footnote support could all be internally represented within this framework, making user customizations for special use cases trivial without having to change the source code.

This would effectively dramatically expand the number of potential contributors, in accordance with the open source paradigm, as non-programmers could design sophisticated layout styles that they find useful and share them with others, while preserving the integrity of the core application and allowing the main developers to focus on refining the central framework.

I'm very curious what other people think of this idea?

2006-04-23 00:27

 

sequence_examples.png (234,960 bytes)   
sequence_examples.png (234,960 bytes)   

avox

2006-05-02 01:50

updater   ~0010761

Sounds complicated.

As an alternative I plan to give special positioning options to
frames embedded in a textframe, including anchors,
relativ positioning to frame/pageborder/currenttext pos, etc.
That would make creating margin notes very easy and might
help with some other applications you have in mind.

Math formulas, tables and footnotes need more specialized
code anyway IMO.

PLucAuclair

2006-05-02 18:27

reporter   ~0010797

I would agree on the idea on a general basis. But it's very complicated to design, I wouldn't try it without a real test case. I'd have a few ideas but I'm not all too sure of how it should work.

mkoren

2006-05-02 19:49

reporter   ~0010802

Inline frames in text is one of the modes I had in mind. Text flow in a frame is really the one built-in example of relative positioning we have now, i.e., each glyph or inline frame is placed sequentially after the last, wrapping at the frame edge.

Embedding frames in text could be thought of as applying the text-flow relative placement paradigm to arbitrary frames or objects besides glyphs.

Essentially I would propose to add a few more relative placement modes to handle sequences where the place-horizontally-one-after-the-next paradigm isn't what you want. The most useful would be arbitrary relative positioning, where you specify a coordinate offset (or angle and distance) between successive objects, either by their centers/basepoints or as a distance between their frames. (Or alternatively, as I said above, using a mathematical expression like 342 + index number in sequence.) And these alternate modes could apply equally well to sequences of glyphs, paragraphs, frames, groups, etc. Very flexible.

I'll acknowledge that designing the system right for nontrivial uses needs care, but I think it would be worth it given the incredible power that placement styles would have to make managing complex documents trivial, especially given the ability for users to share custom styles as mentioned above. I predict that such features will be considered standard in layout apps within ten years. :)

What I would suggest is that we at least consider it enough to include support for sequences in the file format now, and provide user support for them where doing so is trivial. Then any major new support needed (if any) could come in 1.5.x or so.

PLucAuclair, I have thought of many specific test cases in working out this idea. One is creating layout styles to manage charts like in the screenshot in 0003555. Imagine making border frames for groups of the small frames that maintain a 3pt gap around their contents, ensuring consistent size, color, and spacing of the little boxes in each group, maintaining left-right symmetry automatically as you change the layout on one side, arrows that snap neatly between boxes and have text fields around them, etc., etc.... And I have a real idea how that would all work together, not just a fuzzy concept.

And avox, I also have a clear idea how a user could format an equation without any special code--not create it with a GUI, but write it as text and format it--like shown in my screenshot here.

I'd be happy to discuss this further if anyone wants to pursue it.... I think a lot of people could find very useful applications of this.

eudoxos

2017-10-19 16:20

reporter   ~0044557

Related to this one, I had the idea of preliminarily using object attributes (can be anything) to specify conditions for width, height, position, rotation and so on. The expression could be fed to e.g. Python on-demand (with specially defined variables with attributes, so that you can say e.g. this.x=Text321.x+40*mm, this.y=Text12.nw.y) which would adjust the real positions in scribus; one-pass only, no dependency tracking and fancy stuff like that. It could be already useful, especially with automatically-defined anchors, like n/nw/w/sw/s/se/e/ne (of the bounding box), "c" for center; and perhaps p1, p2, p3, ... for points where respective paragraphs starts (think of parallel text), guides (named? or simply indexed) so moving the guide would adjust the objects snapped to the guide (plus manually noted as attribute). That would be useful for prototyping without having to modify the core and dealing with the UI for that.

Issue History

Date Modified Username Field Change
2006-04-17 21:55 mkoren New Issue
2006-04-23 00:26 mkoren Note Added: 0010349
2006-04-23 00:27 mkoren File Added: sequence_examples.png
2006-05-02 01:50 avox Note Added: 0010761
2006-05-02 13:16 mhanski Status new => feedback
2006-05-02 18:27 PLucAuclair Note Added: 0010797
2006-05-02 19:49 mkoren Note Added: 0010802
2006-05-13 16:56 christoph_s Relationship added child of 0003812
2016-12-12 18:29 Kunda Relationship added related to 0003708
2017-10-19 16:20 eudoxos Note Added: 0044557