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