Duplicate styles

[mer]

I was under the impression that I could quickly get rid of all the duplicate styles generated when I created a Flare project by importing a Word document.

I have pored over the Analyzer Quick Guide and Analyzer help, and have found no instructions on how to do this. There is one sentence in the help that states "If you encounter duplicate styles, you may want to modify the settings for one or both styles, or you can remove one of the style classes from the style sheet." But I am afraid to do this: since analyzer also finds all unused styles in the project, I'm assuming that duplicate styles are used. If a style is used and I delete it, the paragraphs using it will no longer have the look I want. Am I missing something here?

Thanks,
MER

[LTinker68]

I believe you have to use the find-and-replace in Flare with "find in source code" enabled to replace all instances of one class with another. For instance, if you have p.note and p.noteGray that have the exact same attributes, use find-and-replace to replace all instances of <p class="noteGray" with <p class="note". Once you've done that, you can go into the stylesheet and delete the noteGray class of the paragraph tag.

[mer]

I tried it out, and it works. But even though I select Find in whole project, it looks as if I have to have a file open to get it started, and that Replace All means replace all in the active open document; am I missing something?

Thanks

[LTinker68]

Yeah, Flare's find-and-replace is a bit odd to me and it's confused others, too.

You select to search in the whole project, but then you have to click the Start button to get started, not "Find Next" or >>. The Start button finds the first instance in the first topic is comes to. To make the change in all files, you click Replace in All Files. If you're going from file to file, you click Replace All to do all the changes in that current topic, then you click the >> button (just above the Start button) to go to the next topic. I think in that case "Find Next" will also take you to the next topic.

NOTE: In a quick test, it seems like you only have to click the Start button once the first time you want to do a global replace; thereafter, the Replace in All Files buttons seems to always be available. If you shut down Flare and restart it, then the next time you want to do a replace across the project, you have to click the Start button in order for the Replace in All Files button to become available. I just now noticed that behavior, so I haven't done extensive testing to see if it stays that way as long as Flare is open or if doing something else will make the Replace in All Files button inactive.

And yes, you have to have a topic open and it has to be active in order for the FAR pane to be available (not grayed out). Don't know why -- that annoys me, too, especially since "CSS Stylesheet" is a valid type to search in, but you still have to have a topic open in order to use the FAR pane. Don't get it.

[mer]

Thank you so much. I feel like an idiot not noticing the Replace in All Files button. That will speed things up.

M

[SteveS]

I was under the impression that I could quickly get rid of all the duplicate styles generated when I created a Flare project by importing a Word document.

I have pored over the Analyzer Quick Guide and Analyzer help, and have found no instructions on how to do this. There is one sentence in the help that states "If you encounter duplicate styles, you may want to modify the settings for one or both styles, or you can remove one of the style classes from the style sheet." But I am afraid to do this: since analyzer also finds all unused styles in the project, I'm assuming that duplicate styles are used. If a style is used and I delete it, the paragraphs using it will no longer have the look I want. Am I missing something here?

Thanks,
MER

The duplicate styles pane in Analyzer lists the duplicated styles found in the stylesheet(s):

Analyzer1.jpg

There is also a 'report' in the unused items called unused styles:

Analyzer2.jpg

If you doubleclick the item (style), Analyzer opens the stylsheet editor, allowing you to remove the style.

By comparing the duplicate styles and unused styles, you can clean up your project.

The trick will be applying just one of the styles throughout your project.

HTH

[mer]

Thank you for the info.

MER

[navoff]

The problem I've noted with the Analyzer (V2.3) is that I have a lot of styles that are the same in the Default medium but only differ in the Print medium and the Analyzer sees all of them as "duplicate".

[mer]

Thank you for the tip.

MER

[LTinker68]

The problem I've noted with the Analyzer (V2.3) is that I have a lot of styles that are the same in the Default medium but only differ in the Print medium and the Analyzer sees all of them as "duplicate".

I could see it mentioning that if the styles defined in the print medium exactly matched the styles defined in the default medium (e.g., if p.note was set to blue in both and all other attributes were the same), but if there was any difference between them at all (p.note is blue in default but black in print), then I wouldn't expect them to be reported as being duplicates.

Are you saying there is at least one attribute different in a style as it's defined in the print medium versus how it's defined in the default medium and Analyzer still claims they're duplicates?

[navoff]

The problem I've noted with the Analyzer (V2.3) is that I have a lot of styles that are the same in the Default medium but only differ in the Print medium and the Analyzer sees all of them as "duplicate".

I could see it mentioning that if the styles defined in the print medium exactly matched the styles defined in the default medium (e.g., if p.note was set to blue in both and all other attributes were the same), but if there was any difference between them at all (p.note is blue in default but black in print), then I wouldn't expect them to be reported as being duplicates.

That's what I would think, too.

Are you saying there is at least one attribute different in a style as it's defined in the print medium versus how it's defined in the default medium and Analyzer still claims they're duplicates?

Yep. Here's an example that Analyzer lists as being "duplicate":

Code: Select all

pre.ascii_dump_6pt
{
	background-color: #ddedfe;
	padding: 6px;
	border-bottom: solid 1px #c0c0c0;
	border-top: solid 1px #c0c0c0;
}

pre.ascii_dump_7pt
{
	background-color: #ddedfe;
	padding: 6px;
	border-bottom: solid 1px #c0c0c0;
	border-top: solid 1px #c0c0c0;
}

@media print
{

	pre.ascii_dump_6pt
	{
		background-color: #dcdcdc;
		font-size: 6pt;
	}

	pre.ascii_dump_7pt
	{
		background-color: #dcdcdc;
		font-size: 7pt;
	}
}

The only difference between the two is the font size in the print medium.

[LTinker68]

Code: Select all

pre.ascii_dump_6pt
{
	background-color: #ddedfe;
	padding: 6px;
	border-bottom: solid 1px #c0c0c0;
	border-top: solid 1px #c0c0c0;
}

pre.ascii_dump_7pt
{
	background-color: #ddedfe;
	padding: 6px;
	border-bottom: solid 1px #c0c0c0;
	border-top: solid 1px #c0c0c0;
}

The only difference between the two is the font size in the print medium.

No, actually, the styles shown above are what it's saying are duplicates because they are identical. pre.ascii_dump_7pt in print is different from pre.asci_dump_7pt in the default medium, but pre.ascii_dump_7pt in the default medium is identical to pre.scii_dump_6pt in the default medium.

[navoff]

That's what I was trying to say initially. I only need the styles different in the print medium so, while they look identical in the default medium, they are different in the print medium. That difference alone is not enough for Analyzer to say that pre.ascii_dump_6pt is different than pre.ascii_dump_7pt. It breaks it down by default/print/non-print mediums when it does the compare. Which, frankly, is completely useless to me. It has flagged 126 "duplicate" items, which aren't duplicate at all from my perspective because I look at the entirety of the style, both the default and print mediums.

In the case of the <pre> styles, it doesn't matter what the font size is for the default medium since that's the screen setting and the user can always scroll the window to see the entire text. Because they can't do that in print, I have to change the font size in the print medium. If all <pre> styles were to have the same background, padding, border, etc. I could just style the one main <pre> style that way and then only have to worry about defining the class in the print medium. If nothing is defined in the default medium for that class, it would be ignored when formatting for the default medium. However, I don't want every set of <pre></pre> tags to have that background, boarder, padding, etc. so I have to create a separate class for each font size and create a default medium style that's identical for all <pre> styles of that type. If there was some way to set a variable for the class name in the default medium, I would.

I also don't want all the <pre> styles to be the same tiny print if I can help it. I'd rather make it as close to the default font size as I can for readability. I only reduce it by as much as I need for that section. So far, this is the only means I've found to give me the flexibility of only changing the print medium version of the style.

[LTinker68]

Analyzer scans the project as a whole; it doesn't evaluate styles based on which target you're about to build, or even which target is your default target. So it doesn't know that you have two identical styles in the default medium because there's a slightly difference to them in the print medium. In this case, what might have been better would be to put the common attributes in the base <pre> tag, and create classes just for declaring the different font sizes. All other attributes would be inherited from the base tag. (Assuming, of course, that your <pre> tag wasn't already set up with totally different attributes.)

You could also try combining the styles in the default medium into one code block. Analyzer might not consider them to be duplicates, although technically they are. I haven't really tested that to see how Analyzer treats it. Unfortunately, you have to manually modify the stylesheet to put them into one code block, as shown below.

Code: Select all

pre.ascii_dump_6pt,
pre.ascii_dump_7pt
{
   background-color: #ddedfe;
   padding: 6px;
   border-bottom: solid 1px #c0c0c0;
   border-top: solid 1px #c0c0c0;
}

@media print
{

   pre.ascii_dump_6pt
   {
      background-color: #dcdcdc;
      font-size: 6pt;
   }

   pre.ascii_dump_7pt
   {
      background-color: #dcdcdc;
      font-size: 7pt;
   }
}

[navoff]

Analyzer scans the project as a whole; it doesn't evaluate styles based on which target you're about to build, or even which target is your default target. So it doesn't know that you have two identical styles in the default medium because there's a slightly difference to them in the print medium. In this case, what might have been better would be to put the common attributes in the base <pre> tag, and create classes just for declaring the different font sizes. All other attributes would be inherited from the base tag. (Assuming, of course, that your <pre> tag wasn't already set up with totally different attributes.)]

The problem with that is that not all <pre> tags will need the common attributes. It's just this type of <pre> tags. Otherwise, that's what I would have done. That's one of the problems of changing the base tag is that you have to consider how it will affect the use of that tag in other places. I just haven't found an elegant way to ensure that I get everything to style the way I need/want. For now, I just ignore the Analyzer's "duplicate" styles.

[LTinker68]

Yeah, in this case I think that's your only option. Or switch to inserting screenshots of the code or whatever info you display in the <pre> tags, but there are several reasons why I could think you wouldn't want to do that.

[kwshaw1]

Hey, that's a good tip about the Start button, which is tucked away at the bottom right of the Find and Replace dialog instead of being at the top.

Suggestion to Flare designers to make the Start button more noticeable in future versions.

[Andrew]

Capture discussion split from this thread and continued here:
http://forums.madcapsoftware.com/viewto ... 18&t=12092