Roadmap Suggestions: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
mNo edit summary |
||
Line 49: | Line 49: | ||
* Drawing across pages: putting objects over page borders so that they span over two or more pages - DONE | * Drawing across pages: putting objects over page borders so that they span over two or more pages - DONE | ||
* Different page sizes in one document, with the possibility to redefine sizes not only when creating a new doc, see the [http://bugs.scribus.net/view.php?id=2189 feature request 2189] | * Different page sizes in one document, with the possibility to redefine sizes not only when creating a new doc, see the [http://bugs.scribus.net/view.php?id=2189 feature request 2189] DONE | ||
* The work on the new XML format is an excellent time to lay the groundwork for a professional Tables feature that can support large projects, in the way that the FrameMaker Tables feature does. A Tables feature for a real DTP is a schema element in its own right, with a coherent set of attributes and sub-elements. It's more than a collection of frames with borders that just happen to be next to each other. It has some definite number of columns, and is not susceptible to being corrupted by deleting one cell out of a column -- if a column exists at all, it has a cell in every row. Similarly, a row has a cell in every column if it exists at all. (A cell can be empty, or merged with neighboring cells, but it is incapable of being deleted or resized by itself.) A table has header row elements and footer row elements, which are instantiated automatically when a table paginates. Layout properties of the table, such as cell margins, are inherited by every cell in the table unless locally overridden. And so on. There are many details to consider, and this is an ideal time to consider them. | * The work on the new XML format is an excellent time to lay the groundwork for a professional Tables feature that can support large projects, in the way that the FrameMaker Tables feature does. A Tables feature for a real DTP is a schema element in its own right, with a coherent set of attributes and sub-elements. It's more than a collection of frames with borders that just happen to be next to each other. It has some definite number of columns, and is not susceptible to being corrupted by deleting one cell out of a column -- if a column exists at all, it has a cell in every row. Similarly, a row has a cell in every column if it exists at all. (A cell can be empty, or merged with neighboring cells, but it is incapable of being deleted or resized by itself.) A table has header row elements and footer row elements, which are instantiated automatically when a table paginates. Layout properties of the table, such as cell margins, are inherited by every cell in the table unless locally overridden. And so on. There are many details to consider, and this is an ideal time to consider them. |
Revision as of 09:28, 13 April 2006
Note: While this is a good place to make suggestions, it is best to file this on Scribus Bug Tracker and use severity 'feature' to ensure that all the devels see your request.
- The "Text Connections" needs only be visible when the text is "active"
- The ability to Pan with the middle mouse button, as an option in the menue
- Trapping option (overprint fill, overprint stroke) http://en.wikipedia.org/wiki/Spreading_and_choking
- Command line option to generate PDF files from SLA files without launching Scribus GUI, see the feature request 238
- Consistent reordering of Yes/No/Cancel buttons throughout the whole application, see the feature request 709
- Make it possible to define globally executable JavaScripts in Scribus generated PDF forms (e.g. on document loading)
- Implement radio button behaviour for PDF forms, see the feature request 866
- A new GUI dialog for importing ICC profiles, see the feature request 1728 This has been closed for a more comprehensive solution. DONE
- Add possibility to take on guides when copying pages
- Give option to save a document into a compressed archive complete with all embedded images (handy for sharing editable documents)
- Change the hyphenation scheme to use true discretionary hyphen character
- Have "adjust frame to picture" have the same options as "image visible" , (in the right mouse click area, or on the properties tool bar. In that you can set the default for the frame to always adjust to the size of the imported image. see feature request [1]
- For the rotate frame widget, add the ability to rotate 45 degrees with a click (only needs to be one direction, you would just click as many times as needed)
- Add ability for drop-shadows, with full offset capabilities and Gaussian blur, to individual objects, text frames, etc.
- Automatic creation of guides (split page in x rows and x columns). 1969 DONE.
- LIGATURES: automatic glyph substituting, see also the feature request 1412
- Right indent: Have the possibility of right indent a paragraph / paragraph-style, see also the feature request 1117
- BOLD: although discussion is going how to have the possibility of bold face, it should be done in early 1.3.cvs, see also the feature request 1076
- Baseline-shift: Raising/lowering text. This has also been added to the Character style properties.
- To be a real DTP-Program, Scribus needs to support the Cicero(Didot-Points)-Unit 2140 - DONE
- Function to resize text boxes to the text contained (maintainig the margins from the settings), see the feature request 740
- Possibility to arrange pages individually (not limited to booklet style left/right), see the feature request 2186
- Drawing across pages: putting objects over page borders so that they span over two or more pages - DONE
- Different page sizes in one document, with the possibility to redefine sizes not only when creating a new doc, see the feature request 2189 DONE
- The work on the new XML format is an excellent time to lay the groundwork for a professional Tables feature that can support large projects, in the way that the FrameMaker Tables feature does. A Tables feature for a real DTP is a schema element in its own right, with a coherent set of attributes and sub-elements. It's more than a collection of frames with borders that just happen to be next to each other. It has some definite number of columns, and is not susceptible to being corrupted by deleting one cell out of a column -- if a column exists at all, it has a cell in every row. Similarly, a row has a cell in every column if it exists at all. (A cell can be empty, or merged with neighboring cells, but it is incapable of being deleted or resized by itself.) A table has header row elements and footer row elements, which are instantiated automatically when a table paginates. Layout properties of the table, such as cell margins, are inherited by every cell in the table unless locally overridden. And so on. There are many details to consider, and this is an ideal time to consider them.