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 widows. The 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.