Flare 11 glitch?

[ajturnersurrey]

Whilst trying out Flare 11 I have spotted a slightly odd issue.

Flare 11 has an issue with one of my TableStyles .css files. Whenever I have a topic open which references it I get messages of the type:

CSS: V:\Documentation\Manuals\VOS\Content\Menu walk through\Menu parameters.htm: CSS: Invalid border-left-color:
CSS: V:\Documentation\Manuals\VOS\Content\Menu walk through\Menu parameters.htm: CSS: Invalid border-right-color:
CSS: V:\Documentation\Manuals\VOS\Content\Menu walk through\Menu parameters.htm: CSS: Invalid border-top-color:
CSS: V:\Documentation\Manuals\VOS\Content\Menu walk through\Menu parameters.htm: CSS: Invalid border-bottom-color:

Viewing the Table Style does not throw up any errors.

When I read the css I have definitions like

Code: Select all

border-bottom-color: #abb5bb;

which don't look erroneous to me...

Please let me know if I have missed something that has changed about css or about the way MadCap handles table styles in v11?

[GaryUK]

I haven't seen any messages like yours, but my HTML (CHM) output is definitely not the same in V11. Rounded borders missing; bullets missing; shadows missing; content using :after missing... it looks awful.

It works fine in V10, and HTML5 output in V11 is fine.. I have logged a support call.

I also had an issue whereby very old images were appearing in V11 online outputs. These had somehow got into the <OriginalImage> element in the .props files. Apparently V10 ignored this element but V11 doesn't. It was resolved after I deleted all the <OriginalImage> elements from the .props files (using very scary regular expression syntax).

[NorthEast]

I also had an issue whereby very old images were appearing in V11 online outputs. These had somehow got into the <OriginalImage> element in the .props files. Apparently V10 ignored this element but V11 doesn't. It was resolved after I deleted all the <OriginalImage> elements from the .props files (using very scary regular expression syntax).

I'm guessing you (or someone else) previously used Capture to edit these images.

If you edit an image in Capture, the image data is saved in the props file (with everything else), and when you build the target Flare will use this image data to regenerate the image file (e.g. the PNG, JPG) in your output.

I've seen this issue before where people updated the image files (PNG, JPG) without realising they were Capture images, so when the output was built the image file is regenerated from the props file, so the old image appears in the output.

[GaryUK]

Yes Dave. That's the issue. However it never manifested itself until V11. Suddenly I had a bunch of old images instead of my shiny new ones.

[NorthEast]

Yes Dave. That's the issue. However it never manifested itself until V11. Suddenly I had a bunch of old images instead of my shiny new ones.

It's not specific to v11, it's triggered by whether Flare thinks the image needs to be updated; e.g. if you set Auto-size Capture objects in the target.

[GaryUK]

All I know is if I generate it in V10 it doesn't do it. If I generate it in V11, it does.

[SusanL]

All I know is if I generate it in V10 it doesn't do it. If I generate it in V11, it does.

I am having the same difficulty. Old images appear in V11; but not in V9 or v10. I'm planning on deleting the props files, since I am now using SnagIt instead. I also had a problem with "Object reference not set to an instance of an object" error when building a PDF file. Built the same file in V9 and v10 -- built fine with no errors. I'll let MadCap support know.

Susan

[ChoccieMuffin]

Don't the .props files also contain conditioning information? I have conditions on quite a few of my screenshots, and some of them have .props files while others don't. I also use SnagIt, though I'm pretty sure some of the screenshots were taken using Capture.

[NorthEast]

Don't the .props files also contain conditioning information?

Yep, the props files also contain any conditions or file tags set on the image (as they can't be saved in the image file itself).

[GaryUK]

In resolving this, I only deleted the <OriginalImage> element, not the whole props file. All of my superimposed information was retained and remained editable in Capture. The element comes back if you edit the image in Capture, but it is correct for the latest image.

When dealing with Support they said "... It seems that in V11 that it was respecting this property applied to the image while in V10 it was not..."

Incidentally, the issue I had with the styles of my images in CHM output (border radius ignored etc) has also been resolved. To overcome it, Support told me to replace the meta tag on the Advanced tab of the CHM target to this:

<meta http-equiv="X-UA-Compatible" content="IE=7,8,9,10" />

For some reason, V11 only includes IE7 in this field. It seems fine now, although I am surprised there have not been more issues raised.

[tyip]

So what's the resolution to the invalid border color error messages? I'm getting these error messages. Thanks.

[ajturnersurrey]

Sorry - I still don't know!

All my targets seem to carry on building as usual, despite these messages getting thrown up when I open certain topics, so I am carrying on regardless, but it is disconcerting.

[paul_collins]

This may or may not help, but I have just had a similar problem that turned out to be an issue with image styles.

My image style included definitions such as:

Code: Select all

border-left-style: none;
border-left-width: ;
border-left-color: ;

Flare v10 didn't mind, but v11 complained with invalid css messages about the border-left-width and border-left-color properties.

If I edit those styles via Flare v10 it leaves the undefined properties in the stylesheet, but when I edit the same styles in v11 it removes the undefined properties (and hence the css errors go away).

I don't know if earlier versions of Flare were responsible for putting those undefined properties in the stylesheet in the first place (I typically edit the css manually, but some of the content may have originally been generated via Flare's css editor), but v11 seems to be a bit more strict and tidy in this respect.

[tyip]

That's it!!! Thanks, Paul.

This is not just for image or table styles, but for all styles that has border properties.

If you edit your style sheet in a text editor, search for undefined border properties and correct them (see Paul's screenshot).

If you edit your style sheet in Flare, look for border properties with a gray box instead of "(not set)" and correct them (see screenshot).

border.png

Techie details:
Flare 11 added some border properties that are not in Flare 10 such as border align and border length (there may be others). When the new properties were added to the style sheet, some other border properties got messed up and Flare 11 sees these as errors (gray box instead of "(not set)". Changing the gray box fixes the problem.