View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000363||Scribus||Styles||public||2004-03-25 16:28||2013-11-01 13:21|
|Target Version||Fixed in Version|
|Summary||0000363: differential paragraph styles|
|Description||it would be really really really cool if paragraph styles' definition could be separated into|
- normal (by default)
- first n lines
- last m lines
per default, m=n=0
a combo box on the dialog could let the user switch between the sub-styles...
|Additional Information||-> it's a long term feature request...|
|Tags||No tags attached.|
|related to||0001322||acknowledged||unify Styles and Templates, make them hierarchical (add inheritance)|
|related to||0001546||acknowledged||style import/link ideas|
|has duplicate||0003410||closed||cbradney||depending paragraph styles|
|has duplicate||0004578||closed||avox||Typographic enhancement: First line of paragraph|
|related to||0000204||acknowledged||Drop Cap only for the first paragraph|
|related to||0001132||acknowledged||Styles should be separate from documents|
|related to||0001076||acknowledged||New (Sub) Style definition for Boldface, Italics and Plain|
First paragraph, first n chars, and first n words would also be extremely handy.
This would go nicely with style inheritance.
||What about programmable paragraph styles, ie. small Python programs which format the paragraph according to your need? When the Python interface is decent enough, you could just request the first n lines yourself and apply any charstyle to it.|
That'd work, and if PageItems gain the ability to signal that they've been altered you could have a Python snippet trigger on that signal to apply the formatting.
Honestly, though, I suspect it's better done in the core app. Most people won't want to have to (or know how to) program their paragraph styles.
The other problem is that if you want documents to carry the code around (ensuring the doc is portable) that'd be a horrific security risk. Python is poorly suited to that sort of in-program scripting and automation, as it provides no way to restrict programs' access to the full system APIs. You can read and write files, dlopen(...) libraries, write to the process's memory, execute other programs, and so on. While this is all very useful and powerful when using Python for many embedding tasks, especially with external data or control sources, networking, and so on, it does make it unsuitable for anything that might have to be embedded in a document. It's language is also not really forward compatible enough - it's way too easy for a Python 2.4 user to write code a Python 2.3 user can't run.
Honestly, though, I just don't like the idea of ever having scripts bundled in documents as would be required for this idea. Sure, you can ask the user if they want to run them, but most people won't really understand what that means, and I don't think it's really a good idea to rely on that for things that might be central to the document's function. I know I sure wouldn't want to be responsible for ensuring nothing was available to scripts that could be directly or indirectly exploited to make a macro virus.
Overall, I really think this is best done in the core app if possible.
||How about different styles for each tab field defined in a paragraph style? To automatically format tab-defined columns (right hand column right aligned and italic or something). Based on a mailing list question.|
|2004-03-25 16:28||ale||New Issue|
||Note Added: 0002309|
||Relationship added||related to 0000204|
||Relationship added||related to 0001322|
||Status||new => acknowledged|
||Relationship added||related to 0001132|
||Relationship added||related to 0001076|
|2005-11-01 15:47||avox||Note Added: 0007297|
||Note Added: 0007307|
|2006-03-14 12:38||cbradney||Relationship added||has duplicate 0003410|
|2006-04-12 22:43||mhanski||Relationship added||related to 0001546|
|2006-11-18 02:32||mkoren||Note Added: 0013444|
|2006-12-05 08:52||louisdesjardins||Relationship added||has duplicate 0004578|