Constraining image sizes

[AlanKearns]

I have have been sent a lot of screenshots to include, and have followed the Flare manuals' advice of creating an img.largeimage class which displays them as a thumbnail until clicked. That works fine.

The trouble is, when clicked, they display at their full pixels size - almost full-screen and so much too big, so I am looking for a way to constrain them, and avoid resizing the actual files. I've tried setting the max-height property on the .largeimage class, but it doesn't have any effect. I tried setting it on the img tag itself instead (as a test, that's not practical as it's too all-encompassing) and it strangely constrained the height but not the width, distorting the image. That seemed to contradict the docs, which suggested that aspect ratios would be preserved.

When I look at the output HTML, there are large pixel counts in the IMG relating to the images' height and width, even though my XML sources are clean. Sorry I can't remember the actual parameters, but I don't know where they are coming from as my source XML files are clean, just specifying the iMG's style class.

I'm using Flare 10, IE8, and building to Webhelp (and HTML5 and IE10 shortly).

Anyway, what I'm looking for is something to make my .largeimage class not only display as a small thumbnail, but alsoa reasonably-sized when expanded, maybe no more than 1/2 the height of the browser window. Has anyone had this issue or have a suggestiion?

Best regards

AlanKearns

[Paul Griffiths]

Hi Alan, how's things?

I think you're screwed here. If you've looked at the output HTML you've no doubt noticed the data-mc-width and data-mc-height attributes that Flare has added to the img tag. Flare seems to have got this information directly from the image itself, and you've also probably guessed that somewhere in Flare's javascript there's code that picks up those values and uses them to work out the expanded display size. In fact, if you edit those numbers post-build, then you do indeed see that this affects the size of the expanded image. Assuming you don't want to edit Flare's original javascript files, there's only one thing I can think of that might even remotely work, and that is to write a bit of jQuery javascript of your own which can change the values of the data-mc-width and data-mc-height attributes on the fly as the topic loads, and TBH that sounds like too much effort.

Sorry I couldn't be of more use.

[SteveS]

Is it possible to resize the image you are displaying when the thumbnail is clicked?

Snagit offers a batch processing tool that can be used to resize all images (or those selected) from a source folder. You could, for example, resize images to 50% of the original.

[SteveS]

...you can also resize to a set width, such as 550px...

[NorthEast]

If you want to fix this for WebHelp using styles, try adding this to your stylesheet:

Code: Select all

img.MCPopupThumbnail_Popup
{
	width: initial !important;
	height: initial !important;
	max-width: 80% !important;
	max-height: 80% !important;
	top: 10% !important;
	left: 10% !important;
}

In short, that will reset the image size to its default (width/height - initial), and also set a maximum size (max-width/height - 80%), and indent the image (top/left - 10%). The !important property is used to override any inline styles that Flare will set on the img tag.

In WebHelp, all thumbnail popup images use this style in the output (.MCPopupThumbnail_Popup). They're all displayed out of the normal page flow, so they'll always appear to be sitting on top of the topic, rather than 'in' the topic.

You won't have any problem with HTML5 help, as that restrains the popup image size to fit the topic.

[Paul Griffiths]

Having read Dave's excellent response, I realise that I mis-read the original post as referring to HTML5 output. I thought Alan was unhappy about the size of the popup image even though it fitted within the topic.

Apologies.

[AlanKearns]

Thanks all - I'll have a try with that. And hello Paul!

For those wondering, we worked together 15 years ago. And with me doing only a few years of CSS and next to no Flare during that time, Paul is clearly way ahead of me!

[Paul Griffiths]

And Dave is light years ahead of all of us!