InfoPath Dev

I'm having some major gripes with the designer and setting font sizes.

1. When I set the font size for a group of empty cells, the setting is lost when I go to enter the text in the cells.

2. Whenever I set the font size on some text or cell contents, several white space characters are inserted through out the form. They don't render in the editable form version, so it's a "mostly" a nuisance in the designer view.

However, these extra spaces increase the row height and occasionally, this causes my "auto" row height to become fixed height at the expanded row height - which throws off the layout in the published form (this is more than a nuisance).

> With all these font issues I found hundreds of empty font tags in the xslt. Often they are grouped together in groups of 2 or more(1) or nested(2)

(1)
<font size="2"></font>
<font size="2"></font>
<font size="2"></font>
<font size="2"></font>

(2)
<font size="2">
<font size="2">
<font size="2">
<font size="2">
</font>
</font>
</font>
</font>

You can safely delete them, however they come back... I can correlate any action the number of empty tags or why the nest vs. stack.

Like I said, it's mainly a nuisance in the designer, but I would love to see this fixed, so I don't have to keep going up to every cell and removing the white space.

Is there a hotfix out there for this, or preventing the row from automatically going from auto height to fixed height?

Hi jessel, and welcome to the forums.

We feel your pain. We have had similar issues in regards to these empty font tags. It would be nice if the designer would go through and auto-clean those out on save. Most people would just never know they were added.

I haven't been able to trace down exactly what causes these nested tags to get added. I've had some that were probably 100 or more deep. Not fun for cleanup!

I haven't run into the problem with extra spaces being added. I never try to set a font on multiple table cells at once unless there is content already in them.

As per row height -- beware that any time you click on a row divider line (in the designer) that it fixes the row height. You don't even have to do any dragging - just click. I always make it a point to double check for non-auto row heights every now and then.

Wow, 100 deep? I'm sure if I didn#%92t keep cleaning them out they would accumulate to that.

I'll watch out for the row edit bug and by "extra spaces" I meant carriage returns that expand the row height.

Well, thanks for the consoling, but it sounds like I'll just have to live with it.

If you ever happen to discover what triggers some of these things to happen, let us know, and we'll make sure Microsoft gets notified so we can get these items fixed!!