Problem with alignment of text in different fonts in tables

[Spectre]

Hi,

In Flare, I'm using borderless tables to position content that was previously dealt with by tabs in the Word source content.

Typically, column 1 is in a Courier font, and contains a small amount of text, and column 2 has a longer description in a serif font.

The text in columns 1 and 2 doesn't align correctly, meaning that the text in column 1 is positioned higher than the text in column 2. So let's say I have a table - it doesn't really matter whether it's based on a table style or not, because I get the same behaviour regardless. Let's say that I have a style that has exactly the same settings except for the font family. I'm using paragraph styles, and I've created a table, assigned the serif style to all columns in the table and added text to both columns. Everything lines up. Now I change the style in column 1 to be my Courier style. Immediately the column 1 text is clearly above the text in column 2.

Any idea how to resolve this? Myself and a colleague have played around with settings, all to no avail. If we set vertical align bottom in a table style, this has the required effect if the text in column 2 is shorter than 1 line. If more than 1 line, then it's not good.

Many thanks.

[ChoccieMuffin]

I'm just guessing, but it could be that the different fonts, even though they have the same point size, have a different baseline position.

Imagine a letter p. In font size 10, the downward tail on one font might be 2 pixels high, but in a different font might be 4 pixels high. Other letters in the first font would "sit" on a different baseline to the second font.

[Spectre]

Thanks CM. Yes, I see how that could be a factor. The difference is quite considerable and I wouldn't have thought that it would be as significant as that, but it could be.

To repeat a test that I did: I can correct the issue, where there is one line of text in either column, by simply setting vertical-align to bottom. Then, both lines sit on the baseline, no problem. But that's no good where column 2 has several lines of text because the text in column 1 is too far down. And, as I say these aren't tables where you would be happy to have vertical align set to middle for column 1, because the table is simply for positioning the text, tab-like.

Cheers.

[Leon Descoteaux]

Courier and Courier New (monospace fonts) have a larger line-height value, by default, than the other serif and sans-serif fonts. (Monospace also applies to the font characters' increased width, as you already know.)

To test this for yourself, assign one of each font to two versions of the same multi-line paragraph of text. Note how much more vertical space is used by the monospace font.

Either play with reducing the Courier line-height value, or simply set the Courier column to align that text vertically in the middle, rather than top or bottom. If you go with the middle placement (against your wishes in your initial post), you might also set borders between rows (horizontal lines only) to reinforce the difference.

Hope this helps...

[Spectre]

Thanks Leon. I can see that line height can position the column 1 text correctly, though I'll need to play with the settings for PDF/HTML.

[techwriter31]

I might be way off base, but another factor to consider for multi-line paragraphs in Flare tables is that when you have a carriage return in the table cell, Flare automatically converts it from a "td" or "th" tag to a "p" tag. In this case, whatever settings you have applied to your default paragraph style are used, including the top and bottom margins, padding, etc., which can also affect the alignment of text (especially if column 1 does not have a carriage return and/or using the "p" tag in the table cell). We've gotten around this by creating "td p" and "th p" complex selectors that mimic the appearance of the default "td" and "th" settings.

However, if both column 1 and column 2 are already using the "p" tag in the table cell, this wouldn't apply!

[Spectre]

Thanks again for your replies.

In the end, I queried with MadCap Support. We discussed in a call, the consultant decided there is a bug, and they suggested a workaround. In a subsequent email, the issue was summarised as follows:

"The vertical-align property is not working fully for PDF output therefore a workaround was provided by using a 4px padding-top in the CSS for the paragraph style to push the content lower. "

At the moment, this workaround seems okay.

Cheers.