File Format for Scribus 1.3.x

Introduction
The introduction of the new, 100% XML compliant Scribus file format and its DTD is planned for the 1.3.2 release. The current Scribus file format has some limitations, which should be polished in order to speed things up in Scribus. Please use this space to bring in your ideas and comments.

Current status
I'm working on it. Will post a link to my arch repository when the first working version is out. Then people can pour in suggestions and patches.
 * Feature request 111 - assigned to malex

Things to improve
Done - I've already incorporated this into the new DTD. After a discussion with other devz it seems the consensus is that the numerous smart hyphens and spaces should be processed as Unicode chars - no special elements will be used in the file format. So, I'm removing the element I made for this.
 * 1) Better implementation of hyphenation -- see bug #1475

Community Input Requested
Character Styles - please help making a complete list of attributes of a character style with proper DTP terminology.

Suggestions for styles to be stored in the file format
I have no idea whether this is too late in the discussion/development, but just in case, I add a list of items that could/should be stored as styles in Scribus files.

Proposal for styles in Scribus:


 * Characters
 * Paragraphs
 * Lists
 * TOC
 * Indices
 * Footnotes
 * Endnotes
 * Page numbering
 * Hyphenation
 * Masterpages
 * Frames
 * Colours
 * Colour sets
 * Gradients
 * Lines
 * Tables
 * Table items
 * Guides
 * Polygons
 * Shapes
 * Tabulators
 * Barcodes
 * Layers
 * Pictures
 * Output
 * Export
 * Import

A Tables feature for a real DTP is a schema element
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.

Contributed by Jcarroll