What's the difference between balancing columns and aligning them?

We're currently on XPP 8.4.

Chapter 11 of styles.pdf contains a very detailed explanation of how the "Balance/Align Columns" setting affects the composition process, but I'm having a hard time understanding what the difference is at a high level. I have a two-column layout. I tried experimenting with my Pagination Style changing between "align" and "balance", and the output seems to be the same. On pages that are not completely filled, text is evenly distributed between the two columns. Why might someone use "align" instead of "balance"? Are there specific scenarios where one is more appropriate than the other?

On a related note, the description for "align" says:

Fills all columns equally, aligning the baselines of subsequent
columns with that of the shortened depth of the first column.

I'm familiar with the term "baseline" as it applies to a single line of text. What is the baseline of a column?

  • Cheran, very interesting question.

    Now I could be wrong but the way I have understood the difference is that the difference lays in the way the system decides on how to create columns of equal length. When you use balance the system will do several tries in order to find the best 'balanced' look in order to avoid columns that looks really squeezed next to columns that have a lot of air (white space) in them. It will try to find a way to distribute the text in the columns so that white space between columns is similar in all the columns.
    The align possibility will go for a more crude way, just making sure that columns are of equal length.

    Note however that the system will always try to fill out the columns completely as it tries to put as much text as possible on a page.
    So when you VJ settings are rather generous in most cases it will be able to fill out the columns to the complete length of the page and for those pages the balanced/align/no setting will not make any difference, since the system was able to fill the complete columns without violating the VJ rules you gave it.
    I don't even think that in those cases the system will try to balance columns in order to get a more even look.

    But I leave it up to engineering to gives us the final answer on all of this.
  • Hi Cheran,

    I agree with Bart that it's a good question.

    As I looked to craft an answer, I did notice that the area of the documentation you pointed to (Chapter 11 of styles.pdf) does in fact have some deficiencies (especially in the "align" section) that are making it harder to understand the difference between what happens for "balance" versus "align".

    First I'll address your question about the "baseline of a column" mentioned in the doc in the "align" section. All that really means is the baseline of the last line of a column.

    Next to clear up some of what is stated about what "align" does and how it's different than "balance".

    In the section about balance are some of the following statements (with highlights added by me):

    Re-composition can occur many times when trying to balance columns.

    ...

    After the columns have been filled, a re-examination of the resulting balance depths occurs. The block depth can be changed and the columns re-composed again. This occurs repeatedly until the blocks are justified or a non-balancing situation arises.

    When examining the balance columns. Compose uses the vertical justification spread and error values to make a new “guess” at the balance depth.

    ...

    If there are common spread amounts, Compose removes the least common amount from all the blocks. It then uses the rules in the Item Formats Spec and the Pagination Tries Spec for vertical justification and widows. These rules must be flexible enough to enable Compose to balance the columns.

     

    In the section about align it says the following (with red added by me to indicate incorrect or misleading statements):

    Fills all columns equally, aligning the baselines of subsequent columns with that of the shortened depth of the first column.

    Compose reports a Block improperly justified message for the first column, indicating that it does not meet the block depth requirements. Subsequent columns that align to the first column are considered justified, otherwise, Compose reports a Block improperly justified message.

    Compose uses the rules in the Item Formats Spec and the Pagination Tries Spec for vertical justification and widows. These rules must be flexible enough to enable Compose to balance the columns.

    This is what it should say about align (with highlights added by me to point to corrections/clarifications):

    Fills all columns equally, attempting to align the baselines of subsequent columns with that of the shortened depth of the first column.

    Compose reports a Block improperly justified message for the first column, indicating that it does not meet the block depth requirements. Subsequent columns that align to the first column are considered justified, otherwise, Compose reports a Block improperly justified message.

    Compose uses the rules in the Item Formats Spec and the Pagination Tries Spec for widowsThe depth of header lines and leading compared to that of paragraphs within the different columns must enable Compose to align the columns.

    I do want to mention that the incorrect documentation on "align" mentioned above has just been revised for the soon-to-be-released XPP 9.3.0 version of the Managing Document Styles manual - so the revised PDF will soon be publically available on the docs.sdl.com web site (in about a month from now).

    So "align" does not apply any of the "expand/squeeze" rules that are part of doing the more advanced "vertical justification" of columns, which is done for "balance". For "align", only the widow/orphan and different "keep" rules are applied in order to determine where a valid "break" between columns can occur. For "align", the widow- and keep-related values used in the PT spec are always those of the first Rule of the Tries Table being used (no other PT spec rules than the first one of a Tries Table are used for "align").

    And "align" depends on the header line + leading total depth being a multiple of paragraph line + leading total depth in order for composition to be able to successfully align the baselines of the columns. If the characteristics of the text in the columns does not lend itself to a fully aligned result, there is no attempt to apply any advanced "vertical justification" in order to get the column depths to be exactly equal (that's only done for "balance"). Composition will only attempt to choose a different point to break text between columns in order to get the "best" result. So with "align", a lot of the responsibility lies with the "user" and that there are appropriate text characteristics being used across the columns in order to get truly balanced results.

    And "align" is pretty much a one-pass process in determining the results for the columns, whereas for "balance" composition can spend a considerable amount of time making multiple passes re-composing the columns with different (lower and higher) depths in order to determine a "best" balanced result.

    Hopefully, I've described things correctly and accurately described some of the differences between how "balance" and "align" work differently. If not, I'm sure other SDL colleagues (or customers) will correct me.

    A lot depends on the characteristics of the text across columns as to whether you'll see any difference in results between using "balance" and "align". For the simplest types of text content (as to line + leading depth variations, rather than "generous" VJ settings) and a smaller number of columns, you will not see any difference in results. When the text characteristics has much more variation in line + leading depths (or complex things like pickups and tables), you will probably need to use "balance", and also have strict followed by fairly "generous" VJ settings, in order to always get good balance results.

    As to more on why someone would use "align" instead of "balance" or on specific scenarios where one is more appropriate than the other, I really cannot speak from experience on that (I'm only a developer after all, and not really a publish "user" or "designer" [;)]).

    From the standpoint of a developer looking at (code and) all the different things that XPP composition does and can do, there are just too many factors for me to know what to say. Perhaps other customers can address those topics with regard to their experience with XPP.

    Jonathan Dagresta
    RWS Group/
    XPP Development

  • Jonathan,
    Thanks for the detailed response. That definitely helps me to understand.