Differences between Flare v11 and v12

[sdcinvan]

I'm all for upgrades but it isn't a great idea to make changes that affect projects written in prior versions of Flare; in my case, Flare v11.

Now, I understand that I can likely fix these problems by making Flare configuration changes and editing my master css file(s) but gosh darn, that is going to be annoying!

Here are a list of problems I've found:

Date format change:
Using <MadCap:variable name="System.ShortDate" /> in version 11, printed as (d/m/y) now it is m/d/y. Not a big deal and actually I prefer it the new way. But why did this change in v12?
Easy fix: I just need to change three snippets.

Miscellaneous Margin changes
This is a more significant and annoying problem that will require hours of css edits.
Some of hardly noticeable such as icons shifted about 10 pixels, table columns shifted a few pixels, div caption boxes slightly smaller, etc.

icon margins.png

But others are really a problem. For example the H2 header is inexplicably way off to the left of the margin. Like I said, it is correctable but unless I was previously exploiting a bug, I should have to make corrections after upgrading.

Code: Select all

h2
{
	font-weight: bold;
	color: #737474;
	mc-auto-number-format: 'GH:{n}.{n+}   ';
	/* added 3 spaces after {n+} to correct TOC appearance */
	mc-auto-number-position: float-left;
	text-indent: 61px;
	margin-left: -10px;
	padding-left: -50px;
	mc-disable-glossary-terms: false;
	font-size: 110%;
}

H2 margins.png

I must go now, I will add additional differences tomorrow. Anyone else experience problems after upgrading?

[NorthEast]

The h2 style looks a bit odd - you're floating it left, setting a positive text indent, but also negative padding and margin.

Anyway, since your h3 still appears to work, I'd check what the difference is between these two styles.

[RamonS]

I can see that the H2 style issue is in a need of fixing, but the rest? IMHO the date is still wrong. There is an international standard for noting dates and that exists for ages now. As far as I know only Canada adheres to it. Dates should be noted YYYY-MM-DD and nothing else. In general, start with the most significant and end with the least significant. That is how all reasonable numbering systems are built.
The few pixel shifts...even after pointing them out and seeing them side by side it still took me plenty of time to see the difference. I'd rather worry about the content being accurate rather than obsessing about placement of a glyph. But what do I know, it's your project.

[rob hollinger]

System Dates previously were based off the System Locale.
Now they are based off the Project/Target language.
This might explain the difference.

[sdcinvan]

System Dates previously were based off the System Locale.
Now they are based off the Project/Target language.
This might explain the difference.

Thanks Rob but why isn't this noted in the release notes? http://kb.madcapsoftware.com/Content/Fl ... _Notes.htm

This change isn't a big deal, especially because I caught it right away (once I had a copy that didn't spit out random characters ).

[rob hollinger]

System Dates previously were based off the System Locale.
Now they are based off the Project/Target language.
This might explain the difference.

Thanks Rob but why isn't this noted in the release notes? http://kb.madcapsoftware.com/Content/Fl ... _Notes.htm

This change isn't a big deal, especially because I caught it right away (once I had a copy that didn't spit out random characters ).

Release notes are of bugs fixed that were reported by users.
Additional information on changes made to variables is located in the Help:
http://webhelp.madcapsoftware.com/flare ... iables.htm

Here is a list of what's new in Flare 12:
http://webhelp.madcapsoftware.com/flare ... _Flare.htm

[sdcinvan]

Another change that I am trying to correct is where I wrap screen captures inside a <div> tag box...

In v11 and earlier, the <div> tag box would automatically resize around the contained image. So even if my width was set too small, it would still result in a 'contained' image.
In v12, many of my 'contained' images extend past the <div> tag box. I not exactly certain why this behavior changed. In both versions, the XML view looks good. Only the preview mode and PDF output fail in v12.

[UPDATE] Images still stay within the <div> tag containment. I found that many of my images just need to be reduced in width by about 5 pixels. So, for instance (in the example below)... if I change the image width (and the <div> width) from 640px to 635px, the problem is remedied. However, I still want to know what changed in v12 that no requires me to edit over 100 images. - unless someone has a more efficient solution.

Example:

div captions do not expand to fit 2.png

The HTML:

Code: Select all

      <div class="figure" style="width: 640px;height: auto;">
            <p>
                <img src="../Resources/Images/140_Home_Activity_search.png" class="webthumbnails" style="width: 640px;height: auto;" />
            </p>
            <p class="figurecount" MadCap:autonum=" Figure 1-7: ">Expanded Activity Stream Search Functions. <MadCap:conditionalText MadCap:conditions="Default.ScreenOnly">(click to enlarge)</MadCap:conditionalText></p>
        </div>

The css:

Code: Select all

div.figure
{
	background-color: #ffffff;
	margin: 2px;
	/* horz posn for entire div - non-list only */
	margin-left: 62px;
	border: solid 1px #cccccc;
	/* space inside div */
	padding: 2px;
	text-align: center;
	margin-right: 10px;
	border-radius: 4px;
}

What exactly changed to affect the behavior the <div> tag. Any ideas about what I can do to fix this?

Thank you,
Shawn

[NorthEast]

The styles looks a bit dodgy to me. You appear to be setting the same inline width (640px) on both the div and the image that's supposed to be inside it; but as the div also has padding, then that's going to be impossible.

I'm not sure why it's different from v11 and v12, but you could press F12 and use the browser tools to inspect why they're different.
However, I'd focus on getting your CSS right, because at the moment it might render unpredictably in different browsers.

Anyway, I'd suggest:
* Keep the styles in a stylesheet instead of inline styles (so you don't have to edit 100s of images)
* If you must set any absolute sizes, you can set those on the div only, then you can just set images to width: 100% or max-width:100% to fill the available space.

[sdcinvan]

The styles looks a bit dodgy to me. You appear to be setting the same inline width (640px) on both the div and the image that's supposed to be inside it; but as the div also has padding, then that's going to be impossible.

I'm not sure why it's different from v11 and v12, but you could press F12 and use the browser tools to inspect why they're different.
However, I'd focus on getting your CSS right, because at the moment it might render unpredictably in different browsers.

Anyway, I'd suggest:
* Keep the styles in a stylesheet instead of inline styles (so you don't have to edit 100s of images)
* If you must set any absolute sizes, you can set those on the div only, then you can just set images to width: 100% or max-width:100% to fill the available space.

Thanks Dave.

I haven't touched many of my core styles since I began using Flare several years ago. I guess my poorly constructed styles are an example of "code smell". Never realized they were so bad until v12; definitely my fault and not the new version.

I have since corrected most of the problems but there is one part that I am not entirely clear about fixing...that is, what is the best way to add a fixed space between a header number and the header text? The Flare documents do not describe this kind of scenario (http://webhelp.madcapsoftware.com/flare ... umbers.htm).

Example:
I want to separate the header and header text by the equivalent of 7 spaces. But it needs to be a fixed distance, regardless of the font type or font size.

Code: Select all

1.0       Header 1 text
1.1.0     Header 2 text 

I have tried all kinds of combinations of position and offset styles without success. What works reasonably well but suffers from variability if the font changes is placing spaces in "mc-auto-number-format: 'GH:{n}.{n+}_______';" but there must be a better way to accomplish this (Note: the "_" underscores represent spaces).

Thank you

[jasonsmith]

The best way I have found is to use offset numbers that are outside the head and add a corresponding margin.
h1
{
font-weight: bold;
font-style: normal;
margin-top: 0;
margin-bottom: 18pt;
font-size: 18pt;
font-family: Arial;
mc-hyphenate: never;
margin-left: 35px;
mc-auto-number-position: outside-head;
mc-auto-number-offset: 35px;
mc-auto-number-format: 'GH:{n+} ';
text-align: left;
}

[sdcinvan]

The best way I have found is to use offset numbers that are outside the head and add a corresponding margin.
h1
{
font-weight: bold;
font-style: normal;
margin-top: 0;
margin-bottom: 18pt;
font-size: 18pt;
font-family: Arial;
mc-hyphenate: never;
margin-left: 35px;
mc-auto-number-position: outside-head;
mc-auto-number-offset: 35px;
mc-auto-number-format: 'GH:{n+} ';
text-align: left;
}

Jason, I can't thank you enough for this. Now, I see what I was missing.