Discussion: Practical Needs in Layout Software

Identifying which properties and which features layout software should provide to be suitable for real-world productions is cumbersome. Thats partly due to hobby users confusing layout and word processing, and partly due to professional designers who take the software they are used to and trained on as the only right thing they can image. Commercial layout software apparently takes the all-features approach, bloating the program trying to suite everybody's needs. But they have a point: The process of creating print products highly differs depending on the type of product and the people involved. While simply copying all features of InDesign might provide a competitive but free product, that's not an advisable course of action. The Scribus developers don't fall into that trap, and that's great.

This text tries to outline some of the less obvious but more important issues that arise when creating a printed magazine. It won't delve too deep into the details, but rather outline the basic needs and ideas and explain why certain functionality is important. It doesn't talk too much about the functionality that is already available in scribus 1.3.3. Scribus 1.3.4/1.3.5 implements lots of the suggestions made here.

Layout software should both produce high quality results and allow the designer to be work efficiently. Magazine designers need to get their job done quickly. This basically means: interactive responsiveness of the application, tools and features helping with repetitive tasks, having shortcuts for often-needed operations and of course be able to create a consistent and professional layout.

Text

At the foundation of a printed magazine is, of course, text. High quality typography should be the most important goal. Enough books have been written on that topic and with TeX the free software world has a kind of reference implementation that stands out. Starting with micro typography, there are several points that prove to be difficult, eg. using the proper quotes and apostrophes.

Getting quotes right is relatively easy, but at times it is hard to automatically differentiate closing singe quotes from apostrophes. Whatever automatic mechanism is used to insert typographer's quotes, it needs to be careful to not stand in the way. Depending on the type of content (like embedding source code listings) the layout software should even refrain from using typographer's quotes at all. This often proves to be surprisingly tricky in existing software.

Proper Spacing should never depend on the availability of Unicode space characters in a font like Scribus apparently does. If it's not there, the layout software should emulate the correct spacing. The same is true for all variants of dashes. And, of course, the layout software should use ligatures automatically where the are available in a typeface.

Visually correct kerning and spacing of pairs of letters is highly important to create a well balanced text flow. Some fonts have ugly settings per default, especially regarding some program languages' quirks: in "C++" the plus symbols often receive way too much spacing, while in "--verbose" the two dashes are too close. It would be great to be able to modify the kerning table for those corner cases and do that in Scribus, not by modifying the font itself.

These are all valid points, I think, but as you acknowledge yourself, not only difficult to decide proper behavior for an individual person, but even harder to generalize for many users. The issues with quotes differ depending on the language of the text. Sometimes users can be helpful by offering their workarounds. There might be a way to facilitate creation of keyboard shortcuts for true apostrophes. User:Gpittman

Fonts and type styles

Bold and Italics type styles are a frequent source of frustration. While Quark XPress always provides some bold and italics (and if it can't find the proper font style, will create one), Adobe InDesign at first sight only offers explicit selection of font styles. Under the hood InDesign, of course, has keyboard shortcuts to switch bold and italics which does a pretty good job of finding and selecting the correct style, despite all the quirks of naming font styles in a font family.

But what exactly "correct" means is, at times, not globally determinable. Some fonts have several versions of eg. bold. Scribus could stand out here and do the right thing, that is: Provide the designer with the option to name the bold, italics and bold-italics typefaces that he wants to use, or advise Scribus to create bold and italics by calculating them on demand. I envision a user interface in the font dialog, the paragraph style and the character style with the following settings:

• Shows which bold, italics and bold-italics font styles Scribus would auto-select
• Provide an option to override the automatically selected font styles and explicitly name the three other font styles for a given regular style
• With each of the three styles (bold, italics, bold-italics), provide an option to calculate them from other existing fonts and configure the shearing and amount of greasing needed

So far, at least, I don't think you will find an agreement about the idea of calculating bold, italics, and so on. This is felt to be a feature of Scribus, not a deficiency, that it only uses valid typeface styles, not artificially generated ones. User:Gpittman

Paragraphs

Laying out paragraphs still is far from perfect in Scribus. This is basically due to not providing enough flexibility in H&J settings (hyphenation and justification). InDesign eg. provides the designer with lots of options in this field. Those options are highly welcome when using block justification in narrow columns. Fine-tuning those settings turns out to create much better results than sticking to whatever default setting there might be. A great addition would be an option to select which characters allow a line wrap, like whitespace, dots, dashes, pipe symbols, slashes etc.

The much-praised adobe paragraph composer, on the other hand, often turns out to step onto the foots of editors that do final proofreading and text polishing. This step is required to be done in the layout software, as this is the place to fix wrong hyphenation or to even change text to provide better text flow around images or in narrow columns. The paragraph composer tries to optimize text flow throughout the whole paragraph, so a trivial change in the last paragraph might affect the line wrapping of the whole paragraph and thus create new and possibly wrong hyphenation in the first lines. InDesign provides the single line composer to cope with those issues. This one is conceptionally close to what Scribus does. The moral of that story: It would be great to first have a more or less perfect single-line composer before starting something like the paragraph composers.

Having special characters like discretionary line breaks, discretionary hyphens, soft and hard line wraps is a top need. InDesign didn't have a discretionary line break until version CS3 which is so important to wrap URLs in a sensible way. Both XPress and InDesign treat conditional hyphens at the start of a word as blocking any hyphenation of that word. And it's possible to change hyphenation settings within text styles which is quite useful.

Tabs and indentations are quite usual for any layout software. One great thing about the venerable Frame Maker is its handling of tab positions: Frame Maker counts the absolute number of tab characters in a paragraph to determine the tab position, while Scribus and other software start counting from the last character's position. The Frame Maker approach gets correct tab positions no matter which font size or text amount there is prior to the tab character. Perhaps it would be nice to provide both systems within Scribus. While at it: Using the "indent to here" special character simplifies laying out of eg. bullet lists. This is a great little feature. And Scribus appears to lack right-indent as a paragraph setting.

Attaching rules (lines above and/or below a paragpraph) is used frequently to separate text blocks visually, just like setting the background color of text block. Those rules are part of the paragraph style settings. It would be great to have this option as well in Scribus. Changeing the background color is used, too, to highlight paragraphs. It often turns out to be hard to create a background color that covers the whole paragraph. Perhaps that feature could be added to the rules: Fill all space between upper and lower rule with a background color.

At least some of these things are already available in Scribus, such as discretionary hyphens, protected words (ie, Short Words), so it may be a matter of becoming more familiar with what Scribus can do, and maybe Scribus making these things more obvious. Our upcoming manual may go far to help with understanding the many features which Scribus already has. The text display is getting quite an overhaul in the 1.3.5+ versions, so at least some of these complaints/requests are already in the solution pipeline. User:Gpittman

Styles

Characters, Paragraphs, Text boxes, tables -- all those elements are frequent in a document and should provide a consistent design, that is: follow a style. Having lists of predefined styles for all of those elements is highly important for productivity of the designer and consistency of the product. The paragraph and character styles need to include language settings, H&J settings, baseline settings (snap to baseline grid, baseline offset) and much more.

We all are used to having character and paragraph styles, but having box and especially table styles helps productivity, too. This is basically due to the way lots of magazines are produced: They follow the "text first" principle, where the author and/or editor write the text before they hand it over to the designer. She will import all text, graphics, tables etc. and layout the page. Thus applying a specific style to an element is a frequent task.

Being able to copy styled text is obviously important, but you better also have the option of copying text without any style. That holds true eg. when creating table of contents -- this is usually done manually, not using any automatics like in word processing software. Magazines often have some description of the articles' contents in the TOC and being able to copy text fragments without keeping their original formatting turns out to be a major improvement eg. in InDesign CS3 vs. CS1.

Defining color swatches is a strong feature of Scribus. All that's missing appears to be an option to limit the total amount of color in the CMYK model: Setting all four colors to 100% gives 400% total color which in turn gives bad printing results and thus should trigger a warning. The threshold for that warning should be configurable.

Master pages and libraries

Scribus' concept of master pages is too limited. At times, it is needed to detach objects that are inserted through a master page. Eg. there are page numbers that are a part of the master page, along with lots of other design elements. On a few pages, those numbers do not fit in as there is a commercial ad nearby. Scribus would require to have two distinct master pages, which is not what the designer wants as she would have to update both in case he wants to change anything. It's way more comfortable to simply detach that one element on a single page and remove it from that page, without affecting the master page or any other page.

Along with styles and master pages, object libraries help the layout a lot. One clever feature would be the ability to place an object at exactly the same position it has been when adding it to the library. This would involve inserting the object into the document by the use of a context menu in the library window and some keyboard shortcuts.

Master Pages are still in evolution, and there is an effort to make them more flexible and user-friendly. By any estimation, page numbering needs some work. In the end, there needs to be a balance between flexibility and offering the user so many options that it becomes too confusing to grasp.

I have mixed feelings about how much should be contained within an object sent to the Scrapbook. With Copy and Paste, there already is the feature of placing the copied object at the same X-Y coordinates on whatever page it gets copied to. Does this also need to apply to Scrapbook items? I'm not sure.User:Gpittman

Text wrap paths

In Scribus, the designer can adjust the inset spacing of a text frame. That is the margin the text should keep to the borders of the frame and to any other object. Having this option is great, eg. when using background colors in the text box, to create proper spacing for the text. But this isn't enough: There should be an outer spacing as well, to push aside text in any other text frame that is nearby. This outer spacing should be an option of all design elements, no matter if it is a text frame, an image, a polygon or whatever. InDesign calls that the text wrap path which will wrap text around the object shape or bounding box with positive or negative offsets.

Having multiple text wrapping capabilities allows the designer to reduce the number of objects significantly. This again aids productivity, as a resizing operations only need to be applied to one object instead of several. It even turns out that being able to configure a text frame to not be affected by the outer spacing of other objects is a clever trick when adding headers to text boxes. The box itself will push aside all text from the main text flow to create a nice distance, but the box header should be placed within this distance and thus not be affected.

Within the Text Flows option, there already is an ability to specify what is called the Contour Line for this text flow, which is an editable space separate from the frame contents or the Bounding Box. I do think this could be given some kind of shortcut method, for example, to specify Contour Line at a particular distance all around the frame, but perhaps a short script might accomplish this if all the appropriate commands exist. User:Gpittman

Tables

Tables are a frequent pain for designers and editors. Until recently, most professional layout software wasn't even able to render tables without the help of additional plug-ins. Nowadays, table support is a must have and formatting distinguishes the overall table layout from cell formatting and paragraph styles within the table cells. When producing larger tables, having strong table layout features saves huge amounts of time and prevents errors. Tables should be able to cross page boundaries, especially spreading a double-page.

InDesign only allows tables as child elements within text frames. In cases where the table should wrap and flow over several pages, this seems like a logical decision. But by all means it should as well be possible to have a table as a first-class citizen, just like text and image frames or colored boxes. The second approach is the current Scribus way. It would be great to also add the other solution, just like at times, it is needed to anchor other objects within the text flow. For creating special effects it is even sensible to be able to anchor text frames within other text frames. Using offset values one sould be able to position the anchored frame alongside the main frame, or inside.

Working with objects

Grouping objects is useful for moving them around. Still, it should be easy to change individual elements of a group without ungrouping and regrouping. It would be great to have a special tool for that purpose that will select objects just as if they were not grouped. Editing text in a grouped text frame should always be possible.

Selecting elements hidden behind other objects should be easy by using a combination of clicking and control keys. It's often hard to reach objects that are covered by several transparent or translucent objects above them. Locking an object or a layer should make the object inselectable and thus make it easier to reach elements covered by the locked object/layer.

Objects sometimes need to positioned by the help of grids or guides, by entering their numeric position (including size calculations) or by aligning and/or distributing them within a group. Scribus has all of them, but apparently is missing an option to snap object positions to other objects.

Changing the size and position of images within an image frame should be easy, too. Scribus is missing the resize handles for the embedded image (the image frame has them, of course). An embedded image needs to able to be rotated, flipped, stretched, and fittet into the frame with simple mouse actions. And it would help a lot if the parts of the image that get clipped are displayed semi-transparently while editing the image in Scribus.

Importing graphics should work equally, no matter if it's an image or a vector format. Vector files should fit into an image frame just like images do, together with scaling and clipping features. Importing them as native Scribus elements is great as an option and gives the designer much more possibilities, but the simple approach should work as well.

When resizing a document, it should be possible to select the anchor just like when resizing objects. Astonishingly, this is even missing in InDesign where you can't choose the anchoring while resizing a page. In cases, the elements should stick to their position when measured from the right hand side, adding new space to the left border of the page. This is an important feature when creating title pages that have the back part of the magazine attached to the left side. Setting the zero point numerically (in addition to being able to drag it with the mouse) would help here, too.

It's hard to address all of these individually, but in general I would say that what may be needed is a consensus from various users about the need/desire/features of these kinds of suggestions. One would like to see that any new capabilities are acknowledged and agreed upon by more than a few. There already is the ability to select hidden objects, by holding Shift-Ctrl and clicking to select various superimposed objects. Scribus can only work on one Layer at a time, a feature I think. User:Gpittman

Import and export

The workflow for creating magazines often starts with plain text editing in a text editor or word processor or some kind of database. Scribus can import several text formats, but it would be great to have an equivalent to XPress and InDesign Tagged Text formats. Those formats have a weird syntax, but they focus on text formatting features. A special XML dialect just for importing (and exporting) text would be a great plus. InDesign has very strong XML capabilities, but they often are much more than what is really needed when all you want to do is create some formatted text using styles and direct formatting. This XML should be as simple and generic as possible.

Scribus is known for its high quality PDF export. While this of course is great and absolutely needed, size matters too. Today, a single design often gets published both in print and online and it should be a matter of export settings (with a selection of profiles, of course) to trade quality and size. Whether Scribus is calling ghostscript behind the scenes to shrink the file size or if it writes optimized PDF by itself doesn't matter, but it should be easy to use. The prepress warnings should inform the user when RGB images are included or when the resolution of an embedded image is less than the target resolution (considering image scaling, too).

It would be great to have a variant of the Scribus document format that embeds all fonts that are needed by this document. The goal is to have the Scribus file fully self-contained and cross platform. More often than not, several people work on a single file, and they use their own computers. Requiring to install every font on every client that is used to edit a text is a major pain. And, of course, the wrapping and hyphenation of the text should not change when moving from one client to another, even when crossing platform boundaries. That would be major advantage for Scribus, adding to its fantastic cross-platform nature.

If you've been reading the mail list lately, you can see that the migration toward a more useful and true XML format is in process, at least at the conceptual level.

Shrinking PDFs is already described on the wiki using outside utilities, and quite easy.

This last suggestion is implemented already, not quite in this way, but with File > Collect for Output, where a directory is created, containing everything the file needs, including the option to include necessary font files. User:Gpittman

Text editing

It is often said that text should be edited in a word processor and only at the layout stage should be imported to Scribus an the likes. While this is generally true, there are cases where this statement doesn't hold. For one, there is the alternative workflow "layout first" where the designer will start with her layout and an editor will fill in text later. This workflow is an ideal fit for Scribus as the absence of licensing costs allows having Scribus on every desk. InDesign has the limited InCopy for that purpose.

Even when following the "text first" approach, the text is never 100% finished when it gets imported into the layout software. There will be widows and orphans, badly wrapping text and subheadings at the end of a column. All those should be corrected at the layout stage. And of course, automatic hyphenation always has the probability of failing so even more proofreading and fixing is needed for a high quality publication. Traditionally, this is a job of its own. In any case, some person will be editing the text. So text editing needs to be quick and having a spell checker also helps -- spell checking as available in all major layout software and should not be underestimated. It need not be dynamic (check as you type), it's OK to start spell checking explicitly.

The search and replace dialog needs to have an option to search all text flows in the document, or to stick to the current box like it does currently.

Often, editors want to add comments to their text that they address to the designer or vice versa. One possible course of action is to simply add a text frame with a flashy background color and set it to be non-printing. This ensures that comments never accidentally appear in print. Having a dedicated commenting system, like word processors have, would be nice enhancement, too.

Tools and shortcuts

When developing software, it's just too easy to underestimate the importance of the user interface. Functions that are used frequently need to be easily accessible and available through multiple ways to adopt to the user's personal preferences. The Scribus properties dialog is way too limited in that respect. It's a clever type of dialog for small display sizes. In today's dual or triple head setups, there is lots of space that the dialogs should at least be able to use. It would be advisable to add a "tear off"-capability for the entries of the properties dialog or even groups of that entries. That way, each user could have her own sets of dialog windows and place them where ever she prefers. InDesign even introduces the concept of named workspaces to be able to save and reload a "layout" of properties dialogs (palettes).

The actions that are probably used most frequently when working with layout software are panning and zooming. Scribus borrows adobe's brain-dead idea of misusing an entry key as a modifier key: Both use Ctrl+Space for panning. The space bar is an entry key and as such it's way too easy to accidentally delete some text by overwriting it with spaces. Why not use combinations of real modifier keys for interactive panning and zooming.

Managing and applying styles is a frequent action, too, so those palettes need to be easily accessible, by mouse action and by keyboard shortcuts. It should be possible to assign special shortcuts to frequently needed styles (and library elements, too). And it should be possible to select styles by typing a special key combination, followed by the name of the style or the library element.

Keyboard shortcuts should be configurable and sets of shortcuts saveable and restoreable, to make it easy to share them.

Last but not least, Scribus needs to be real fast when working interactively. This is true for all kinds of interaction, be it opening/closing of dialogs or palette widgets, placing/moving/resizing objects, editing text or whatever.

HTH