Padding not appearing for span selector in print output

[Eric_H]

Hello all,

I've defined a span selector in my CSS to mark white text on a black background in my print output. To prevent the white text from butting right up against the left and right edges of the black background, I've set the left and right padding to 3 mm. See below:

Code: Select all

span.CalloutLabel
{
	color: #ffffff;
	background-color: #000000;
	padding-left: 3mm;
	padding-right: 3mm;
}

In the CSS preview ("This is Madcap Software"), it all looks correct: the white text appears on the black background, and there are three millimeters of black background on either side of the white text.

However, after saving the CSS and importing into my project, it does not look correct in either the XML editor or in the PDF output. The color looks fine, but the padding does not appear; there is zero space between the text and the left and right edges of the black background. My workaround is to add a space on either side of the text within the tag, but that really shouldn't be necessary.

Does anybody have any thoughts? Or, if there is a better way to accomplish what I'm trying to do, I'm all ears.

Thanks,
Eric

[ChoccieMuffin]

Have you tried adding some margins as well? I know that different outputs and different browsers treat margins and padding differently, so adding a margin might be worth a try.

[Eric_H]

Have you tried adding some margins as well? I know that different outputs and different browsers treat margins and padding differently, so adding a margin might be worth a try.

Thanks for the reply! That solution works. I got rid of the padding and added left and right black borders 2 mm wide:

Code: Select all

span.CalloutLabel
{
	color: #ffffff;
	background-color: #000000;
	border-left: solid 2mm #000000;
	border-right: solid 2mm #000000;
}

In the CSS preview it looks fine. In the XML editor, the border is outside of the tags, a bit disconcerting at first. But it looks perfect in the PDF output. On some zoom levels in the PDF, you can see a slight transition between the border and the content, but scroll in or out one level and it looks fine. Probably can't get it 100% perfect, but I'm satisfied now.

I went back to read up on the box model. The padding is transparent, so it seems like it should pick up the specified black background color, but doesn't seem to be for some reason in Flare. In the past, I've spent some time on the phone with Flare support about other CSS items that didn't seem to be working right in Flare, and indeed turned out to be bugs. I have a feeling this might be a bug too.

Anyway, thanks again for the solution. At least now it's all handled by the CSS and I don't have to manually insert spaces inside the tag. Now I just have a whole lot of search and replacing to remove all the spaces I've already inserted throughout my doc set!

Cheers,
Eric

[Eric_H]

Looks like I spoke too soon.

The borders don't respect surrounding in-line text. I didn't notice this at first because I usually use this style in a table, for single numerals or letters standing alone in a table cell with no surrounding text.

But occasionally I have to use it in running text. I just did that for the first time since implementing the border solution and the black borders are overlaying the surrounding content.

Dang. Back to square one!

[ChoccieMuffin]

You might need to use margins AND padding to get things to work.

To make it quicker to see the results, try this:

1. Make a dummy topic that contains examples of all the ways you want to use it.
2. Create a dummy TOC with just that topic in it.
3. Create a dummy target in each output type, and use your dummy TOC.
4. Have a play with your CSS, and build your targets after each change so you can see the impact - the viewer is adequate but not fantastic, and this way it's not too painful to regenerate each time.

[Eric_H]

Thanks CM. I've done some playing around as you suggest. My findings:

Margin and border affect the area outside of the <span> element. Both of these overlay the surrounding content, and aren't suitable for my purpose.

Padding should affect the area inside the <span> element, and ideally is the attribute to suit my purpose. But it truly seems to be non-responsive in Flare. After some googling, I saw that I might need to set the display attribute to inline or inline-block, but neither of these settings had any effect. The padding I specify simply does not appear anywhere except the Madcap CSS preview window. Neither in the XML editor or the PDF output.

I've opened a bug report with Madcap; I supplied a sample project showing the behavior, so we'll see what they say.

Cheers,
Eric

[Eric_H]

One more data point:

I set the styles back to specifying a left and right padding of 2mm, and created a new HTML5 target.'

The <span> style appears correct in the HTML5 output. 2 mm of black background appear on either side of the content contained in the <span> tag.

So the limitation seems to be in transforming the source to PDF; something in that process is not respecting the padding specification in the CSS.

I am not familiar enough with CSS and print to know whether this is expected behavior or not.

[NorthEast]

For HTML5 outputs, the output is displayed by the browser, so the level of CSS support is determined by the browser itself (not Flare).

But for PDFs, the level of CSS support is determined by the engine Flare uses to generate the PDF. This definitely does not have the same level of CSS support that you'd see in a modern browser - some CSS will work in PDF outputs, but some CSS won't.
Unfortunately, I'm not aware of any published details about what CSS does and doesn't work with Flare PDFs.

This is quite a long-standing problem when using CSS with PDFs in Flare - it's a case of trial and error.

[Eric_H]

Thanks for that extra information Dave. I wasn't aware. Now I know I'll just have to cross my fingers whenever I use CSS for my PDF output in the future.

I've not heard back yet from Madcap after submitting the sample project showing the behavior. But it's the result of a bug report, not an actual support ticket, so not sure how much priority it is receiving. When I do I'll share what they say about this particular issue.