Images not working correctly on one topic

[awells12]

Flare 10
Small project (15 topics)

I have images in my master CSS set to be responsive to screen size (auto for height and width, 100% for max-height and max-width). All images appear correctly in the build except for one topic. These images are within a table and do not resize as the window shrinks; I can't even scroll side to side to view the entire image. The images do not appear at all in Flare's XML editor, though the HTML code looks correct to me. Also, Flare gives me an error message when I try to work on this topic and the entirety of the XML Editor window turns into a red box with a red X through it.

I created this project 3 days ago from a Word import so I suspect this problem has existed since the project was created. Does anyone know what could be wrong?

[kkelleher]

Someone reported a similar problem in this thread, and Nita made a suggestion ("setting the table's width to 100% correct the problem") that might help. The OP didn't reply, so it's not clear if they reported the issue to MadCap or resolved it, though.

Thanks,

Kristen

[awells12]

I have table width set at 100% in my master CSS so that shouldn't be an issue. I managed to fix the issue somewhat by deleting the img references in the code and then using Flare to put them back in. As I did this, I noticed that when I tried to place images next to each other side-by-side instead of top to bottom, the images disappeared and the same error and red X would occur just as before. I can live with arranging my images vertically if I need to, but I'm not sure why arranging them horizontally would cause an error.

[kkelleher]

And now I've run into this.....

It seems setting the image max-width to 100% actually causes similar problems in my projects. In my case, if a table cell includes two images, Flare begins glitching out in one of a few ways: big-red-x-in-a-box, topic content disappearing entirely, or crashing.

Additionally, the images are the correct size the XML editor and in the HTML preview/output, but in the PDF preview/output, it causes problems. For example, if another cell in the table row includes an image, that image gets resized (to the height of the <p> tag?). It also seems to be causing alignment issues for both the images and the entire table.

In the HTML, it looks okay:

MCF-icons-in-tables-size-position-HTML-okay.png

In the PDF, I have problems:

MCF-icons-in-tables-size-position-errors-PDF.png

I tried creating a new img class that set max-width to another value (such as auto, initial, or none), but that didn't help the issues in PDF, and Flare still glitches out.

Any thoughts?

IMHO, this is a Flare bug that falls into the category of "tables are flaky in Flare." If I survive the release this week, I'll log it to MadCap Support.

Thanks,

Kristen

P.S. - Someone will likely point out that we really shouldn't be using a table for this purpose, and you're right. But we have other cases where a table cell needs to include images. We also had to cut some corners when we migrated from Frame, and we now have 15 projects comprising 2100 pages. We've had higher priorities...

[NorthEast]

I can't tell you why the glitching is happening, but as these images are just icon-sized, then you don't need to set a max-width (and possibly don't need a width either).

Where you have large images like screenshots or diagrams, use an img class which sets the max-width (or width).

[RamonS]

I suggest resizing the images to be text height or use a verbal description (in your example "up" and "down" button). The problem comes from the images to be higher than the text row and you will run into the issue you encountered or into odd line spacing. In my opinion it is more trouble than it is worth.

[Paulie]

I can give a little bit of insight into the red X errors that appear on some topics with images in tables, as MadCap did extensive research on my machine in order to reproduce the bug in Flare 11.

There were two workarounds:

1. Change the Layout to Print. The issue only occurred in Web Layout (this workaround could be specific to my style sheet).
2. Put each individual image in a <span> tag. This seems to solve the problem and allows the WYSIOP editor to render the page correctly.

MadCap confirmed that it was something to do with the max-width:100% CSS property that was causing the issue. I notice that this is still occurring in Flare 12 though, so it obviously wasn't a trivial fix.

[kkelleher]

Thanks, all, for your replies.

these images are just icon-sized, then you don't need to set a max-width

The icons use the base img class (which is where max-width is set) -- nearly all our images do, with a few exceptions. Adding max-width to the base class was the easiest way to fix another issue we had after moving to Flare 11 (many of our images were much larger than in Flare 10).

We've been trying to avoid applying an img class to our scads of larger screenshots, since I'd rather have the team working on higher priorities. If there were a way to automate it, I could see it, but as it stands, I think an actual human needs to review each case and decide if it needs the style class.

my opinion it is more trouble than it is worth

I hear you, but I also think that resizing the images is more work that it's worth, especially since IMHO I'm working around a bug in Flare.

I notice that this is still occurring in Flare 12 though, so it obviously wasn't a trivial fix.

Oh, that's good to know, Paulie! I'll report it right away and maybe we'll see it in 2017. At least we can edit topics that were glitching.

Thanks,

Kristen

[RamonS]

my opinion it is more trouble than it is worth

I hear you, but I also think that resizing the images is more work that it's worth, especially since IMHO I'm working around a bug in Flare.

That is why I suggested to use a verbal description instead. That will also work much better with screen readers. Overall, I think that inserting images inline with text is a bad idea, it disturbs the flow of reading and unless the glyphs are obvious as to what they mean (most are not) the reader has to stop and think about what this button represents.
If buttons or other controls are not showing a text label in the UI then craft a legend that lists all the controls and their name in the order of appearance. That will be necessary anyway when using the highly recommended screen portraits.

[kkelleher]

That is why I suggested to use a verbal description instead. That will also work much better with screen readers. Overall, I think that inserting images inline with text is a bad idea, it disturbs the flow of reading and unless the glyphs are obvious as to what they mean (most are not) the reader has to stop and think about what this button represents.

The icons in my example aren't the ones we use in production; those are much more complicated. A verbal description would be as disruptive as the icons themselves: 'two crossed rulers over the function symbol.' The user still has to pause, and probably say "Oh, those are rulers?" (not to speak ill of our UI). We've found some obvious quick fixes (like moving the icons out of the table), so we're okay for the moment.

Thanks again for your input,

Kristen

[RamonS]

So isn't this suggesting that the glyphs used are not the best they could be? If it it difficult for a user to understand what it means and difficult for the tech writer to describe what the button does the choices should be revisited....just my 2€. I'd at least send a note to the UX engineer.

[subquark]

I came here with a red X issue but mine may not be from images or tables (I've not yet figured it out). It's affecting dozens and dozens of pages.

However, I wanted to toss in my two cents on the span tag idea.

First, I'm glad you figured that out as a workaround - that's some seriously creative problem solving.

However, by placing a span tag around an element, the site-wide CSS won't be able to style that element right?

Since a span tag is inline, it will be the last thing applied and I *think* that means it will override the site's CSS.

Perhaps a "blank" span tag inherits CSS since there's nothing actually declared in the span.

ie, <span style="background-color: yellow;"> versus <span>

Thanks for the idea and helping me reframe my issue. =)