Small images within a list item or paragraph do not align

[janeenm]

I have several bulleted list items or paragraphs that contain a small image icon. However, for some reason in Flare, the icon is misaligned with the rest of the sentence. Either that, or the number and/or some of the text within the sentence is misaligned. A support rep suggested two things: 1) I remove the line spacing in my CSS, which is not feasible because the rest of the styles contain line spacing, and 2) create a separate style that has no line spacing. I opted for the latter suggestion, but while the text is aligned properly, the icons are still way above or below the rest of the text. It looks very strange and I'm not sure why I was able to effortlessly do the same thing in Word, but have a problem in Flare when I import my doc.

I have attached an image of the effect. Any suggestions on how to fix this will be helpul.

Thanks!

[ChoccieMuffin]

I know how you feel! Rather than messing about with line spacing on the paragraph, I created img.IconInText, which has this code:

Code: Select all

	img.IconInText
	{
		max-width: .5cm;
		padding: 0;
		padding-left: 0pt;
		padding-top: 0pt;
		padding: 0pt;
		padding-bottom: -3pt;
	}

The adjustment to padding helped a great deal. It took a bit of fiddling about, but that might be a suitable approach for you.

[MattyQ]

Code: Select all

	img.IconInText
		padding-bottom: -3pt;

Not to be a bummer, but negative values for padding are invalid in CSS. If that has an effect in Flare, that's probably a problem with their CSS parser and the XML Editor. If that works in browsers, my guess is what you're seeing isn't related to the negative value, but to removing the default padding that certain browsers add to certain elements.

I think, in this case, the more appropriate course is to apply the vertical-align property to the img.IconInText first. This the CSS property that instructs, among other things, where an image in the flow should be rendered.

In this case, you'd probably want:

Code: Select all

img.IconInText {
    vertical-align: text-bottom;
}

text-bottom aligns the bottom of the image with the bottom of the parent's font. So, rather than the folder icon floating to the bottom of the element, it'll sit vertically with the rest of the text.

Now, generally, you may still see your line spacing change a bit, because that image may still be adding extra space between the image and the element above it (this depends partially on the size of the image, and partially on how your stylesheet is already set up). In that case, if you don't want to change the line-height of all your lines (you probably don't), you can add a negative margin value to the img.IconInText class. This will allow the above element to get a little closer to the image. So, as an example, you might end up with something like:

Code: Select all

img.IconInText {
    margin-top: -1em;
    vertical-align: text-bottom;
}

In this case, you'd probably need to decide what negative margin-top value looks best with your project.

Here's a jsfiddle that demonstrates the effect that vertical-align has, and combined with margin-top: https://jsfiddle.net/kp6qfynm/

(I notice my jsfiddle isn't a good example of vertical-align: bottom -- this property would align the appropriate element/image to the bottom of its parent element, rather than the bottom of the text, which is why it's generally not ideal if you want to keep an image vertically-aligned with text.)

[ChoccieMuffin]

Not to be a bummer, but negative values for padding are invalid in CSS. If that has an effect in Flare, that's probably a problem with their CSS parser and the XML Editor. If that works in browsers, my guess is what you're seeing isn't related to the negative value, but to removing the default padding that certain browsers add to certain elements.

Not a bummer at all, MattyQ, but I can confirm that the negative padding DOES seem to have an effect, in the PDF at least, and your vertical-align suggestion doesn't quite work because I want my icon to sit at the very bottom of the glyph, not on the baseline (can't remember the term but I hope you get what I mean).

But I'm hijacking the original thread. Sorry!

[janeenm]

Thanks for the advice! I incorporated both of your suggestions in adjusting the padding and setting the vertical alignment to text-bottom -- which I had already done. However, now I have a new problem: while the icon itself may be OK, some of the text is floating above the line and it looks very strange (see attached pic).

I tried playing with the CSS property styles, but I haven't found anything that has worked thus far. I never had these issues with Word so it's frustrating that this one basic task is causing so many issues.

[kkelleher]

I ran into this back in Flare 10, and it's still an issue in Flare 11. The MadCap Support rep insisted that the problem was the use of outside-head rather than inside-head in our auto-number definition, but I found that:
a) Using inside-head for auto-numbers only fixed the problem in certain cases.
b) The problem appears in paragraphs that don't have an auto-number, but only when they appear in a table.

So the rep opened a case (#52713). It seems that the issue arises when a paragraph includes both an image and a span on the same line, and is placed in a table (note that auto-numbered lists (i.e., numbered lists that don't use <li>) are implemented under the covers as tables).

Our workaruond was to create a new image style that set the vertical alignment to top:

Code: Select all

img.AlignTop
{
	vertical-align: top;
}

This winds up looking like the the second example in this screenshot:

MCF-numbered-list-alignment-incorrect.png

Please also log this problem with MadCap so it has a better chance of getting fixed. The workaround works, but it's basically a kludge and, in our case, involved updating a lot of images with the new style.

Thanks,

Kristen

[LTinker68]

(note that auto-numbered lists (i.e., numbered lists that don't use <li>) are implemented under the covers as tables)

I don't think that's quite true. If you used outside-head, then it created that effect by putting it in a table when you generated the output. If you left it at the default option of inside-head, then it doesn't result in a table in the output.

For images inside the line, I usually adjust the vertical-alignment on the img tag and/or shrunk the image itself a little bit. Depended on how much the gap on the line annoyed me.

[kkelleher]

I don't think that's quite true.

Hmmm. I got this idea from a colleague and ran it by MadCap Tech Support, who seemed to agree (though looking back at the email thread, they never said, "Yup, that's a table alright.")

In my source, our number lists look like this:

Code: Select all

<p class="Numbered_First" MadCap:autonum="1.">Click <span class="UI">View <MadCap:variable name="JasperVariables.Arrow" /> Repository</span>. </p>
<p class="Indent"><MadCap:keyword term="OLAP views:folder" />The repository appears. </p>
<p class="Numbered" MadCap:autonum="2.">Scroll through the repository to select an OLAP view or, type the name (or partial name) of the view you want to see in the search field at the top of the page.</p>

In the output, the HTML looks like this:

Code: Select all

<p class="Numbered_First" MadCap:autonum="1.">Click <span class="UI">View <MadCap:variable name="JasperVariables.Arrow" /> Repository</span>. </p>
<p class="Indent"><MadCap:keyword term="OLAP views:folder" />The repository appears. </p>
<p class="Numbered" MadCap:autonum="2.">Scroll through the repository to select an OLAP view or, type the name (or partial name) of the view you want to see in the search field at the top of the page.</p>

So there's no sign of a table. I can't explain why it happens in numbered paragraphs but not in 'plain' paragraphs, like p (except when they're in tables).

Thanks,

Kristen

[MattyQ]

So there's no sign of a table. I can't explain why it happens in numbered paragraphs but not in 'plain' paragraphs, like p (except when they're in tables).

Are you seeing that in the output, or just in the XML Editor?

As a general PSA, I've found the XML Editor doesn't seem to do a good job of rendering where the image will actually be in the output when you're using inline images.

If you're seeing it in the output, there's a few potential culprits, I'd think. If you say it happens when a span and inline image are on the same line, it sounds like you could potentially have something on either of those elements that is forcing the parent element to have a greater height than you expect. My instinct would be to open the output in Chrome, open up Developer Tools, and check the computed styles for the image, the span, and the paragraph itself. At the top of the pane where it shows the computed styles there's a box that reflects the proportions, the padding, and margins for the element, and shows what stylesheet and where on that stylesheet the styles being applied to the element are coming from. That should give you a good clue as to why your images are appearing where they do in the output.

[kkelleher]

Thanks for the input, MattyQ.

As a general PSA, I've found the XML Editor doesn't seem to do a good job of rendering where the image will actually be in the output when you're using inline images.

It renders correctly in the editor, but in the HTML output, the alignment is wrong (so I agree that the editor isn't doing a good job!).

My instinct would be to open the output in Chrome, open up Developer Tools, and check the computed styles for the image, the span, and the paragraph itself.

I inspected the elements, and lo and behold, each of these numbered paragraphs is actually a table in the running output. Here are a couple of examples: the first shows the 'default' behavior; the second shows my workaround, which is to apply an img class that aligns the icon to the top.

Default:

MCF-numbered-list-inspect-zooom-on-drill-1.png

Workaround:

MCF-numbered-list-inspect-zooom-on-drill-2.png

Thanks,

Kristen

[LTinker68]

I inspected the elements, and lo and behold, each of these numbered paragraphs is actually a table in the running output.

Yes, as MattyQ said, the WYSIWYG editor is only giving you an approximation of the final appearance, but it won't be entirely accurate, because 1) Flare has stylesheets that it adds to each page as it builds the output and something in those stylesheets could affect the appearance, and 2) a lot of Flare features result in numerous tags being used to render the final effect. You see in the XML Editor a single tag, but the resulting output could have div inside div inside div, or in this case, converts the content to tables. And in that case, the output is inheriting the default table, td, and th styles because, hey, it's a table! That always annoyed me to the point where I don't use outside-head.

[kkelleher]

2) a lot of Flare features result in numerous tags being used to render the final effect.

This is one of those Fun Flare Facts that I *know* at some level, but then never remember when I get into trouble.

We've gone back and forth about ditching outside-head. Next time that discussion comes around, maybe we'll switch.

Thanks again for chiming in,

Kristen