Two issues with the HTML Help target

[chargo]

Hello,

I would like to get some advice or hints regarding the following two cosmetic issues with the HTML Help target. We are experiencing them after having migrated our online Help project from RoboHELP 6 to Flare v5.

1. Related topic controls move after being selected and deselected.
In our project, we use related topics controls a lot. What I have noticed in the generated HTML Help target is that the control's icon and text move a few pixels to the left after being selected and deselected again. The control's position remains the same when the affected topic is subsequently displayed again. However, after I empty the browsing history from the Internet Explorer's GUI, the control's position is reset to the initial value. Such behavior implies that the cosmetic issue must be somehow related to the browsing history of Internet Explorer. Does anyone know of a quick solution to this minor problem?

2. Pop-up topics are displayed with varying degree of bottom spacing.
Topics that are displayed as pop-up topics contain (apart from the mandatory HTML code) only simple paragraphs of text embedded in plain <p> elements. They are displayed without vertical scrolls bars, but the window height of most of them is too large, leaving blank space at the bottom of the text. The amount of space varies without any obvious pattern across the entire set of the topics. Note that such topics displayed perfectly when the HTML Help output was generated with RoboHELP 6: that is, the window size adjusted to the topic text for each single topic. Does this have anything to do with the script MadCapBodyEnd.js whose reference is added immediately before the </body> tag of each topic?

Thanks in advance for suggestions.
Boštjan

[KevinDAmery]

Hello,

I would like to get some advice or hints regarding the following two cosmetic issues with the HTML Help target. We are experiencing them after having migrated our online Help project from RoboHELP 6 to Flare v5.

1. Related topic controls move after being selected and deselected.
In our project, we use related topics controls a lot. What I have noticed in the generated HTML Help target is that the control's icon and text move a few pixels to the left after being selected and deselected again. The control's position remains the same when the affected topic is subsequently displayed again. However, after I empty the browsing history from the Internet Explorer's GUI, the control's position is reset to the initial value. Such behavior implies that the cosmetic issue must be somehow related to the browsing history of Internet Explorer. Does anyone know of a quick solution to this minor problem?

I'm not directly familiar with this issue (I don't use the Related Topic feature at this time) but it sounds like there may be a slight discrepancy in the margin or padding settings in the control's pseudo classes. I would compare the visited class with the base style for related topics in the stylesheet and see if there are any differences in the size or positioning parameters.

[chargo]

I have checked the custom style sheet, but there is no pseudo class :visited defined for relatedTopics. In the MadCap.css style sheet however, the pseudo class :visited is defined, but it does not include any padding values, and its definition is the same as those for the base class and the :link pseudo class. The definition contains values for mc-label, font-size, and font-family.

[KevinDAmery]

How about margin values? Also, are the font size / font family settings the same as the base style? If there are any differences that may be the culprit.

[chargo]

There are no margin values defined. The code for all three classes (base class and pseudo classes :link and :visited) is the following:

Code: Select all

	font-family: Verdana;
	font-size: 8pt;
	color: blue;

[i-tietz]

2. Pop-up topics are displayed with varying degree of bottom spacing.
Topics that are displayed as pop-up topics contain (apart from the mandatory HTML code) only simple paragraphs of text embedded in plain <p> elements. They are displayed without vertical scrolls bars, but the window height of most of them is too large, leaving blank space at the bottom of the text. The amount of space varies without any obvious pattern across the entire set of the topics. Note that such topics displayed perfectly when the HTML Help output was generated with RoboHELP 6: that is, the window size adjusted to the topic text for each single topic. Does this have anything to do with the script MadCapBodyEnd.js whose reference is added immediately before the </body> tag of each topic?

The size of popups is calculated by a Javascript that's part of Flare. The general rule is: The proportions of the popup and the size of that part of the window that displays the topic at exactly the moment when the user clicks the link.
If the size is given in one dimension, the other dimension is adapted to keep the proportions. This is to make it look "nice" - pays tribute to our psychological idea of right proportions and beauty.
E.g.: The popup topic contains a table with fixed width and so the topic needs a certain width. The height of the popup is adapted to keep the proportion ...

I would think it's quite a nuisance to use that mechanism to generate the output format you wish:
- You would have to find out what objects in the popup topic influence the size of the popup in what way
- You cannot know the proportions of the topic display when the user clicks the link ... maybe it's high and narrow (like letter format), maybe it's low and wide ("landscape") ...

[chargo]

The size of popups is calculated by a Javascript that's part of Flare. The general rule is: The proportions of the popup and the size of that part of the window that displays the topic at exactly the moment when the user clicks the link.
If the size is given in one dimension, the other dimension is adapted to keep the proportions. This is to make it look "nice" - pays tribute to our psychological idea of right proportions and beauty.
E.g.: The popup topic contains a table with fixed width and so the topic needs a certain width. The height of the popup is adapted to keep the proportion ...

I understand. My questions now are, if it the above behavior is user-customizable in the sense to get pop-up windows adapt to their contents instead of preserving the proportions, and if it is, if such customization is trivial or not.

[i-tietz]

I understand. My questions now are, if it the above behavior is user-customizable in the sense to get pop-up windows adapt to their contents instead of preserving the proportions, and if it is, if such customization is trivial or not.

At Javascript I'm on beginner level and I wouldn't dare changing the Flare JS files, but if you're a JS professional ... why not?
Every other manipulation would be a real effort.

It's probably easier to post a bug report/enhancement request to MadCap to make the popups customizable beyond the stylesheet, e.g. with priorities to chose. But prepare for a wait.