Style editor not saving changes?

[ksoltys]

I have been trying to build an initial style sheet from a project that I created by importing a FrameMaker book. I've run into enough problems with the process that it's made me question my sanity, or at least my decision to move to Flare.

I'm finding that changes that I make in the style sheet editor (either simple or advanced mode) are not persisted. For example, I want to turn off the AutoNumber in my h1.Heading1 style. I open the style class, select the AutoNumber element, change {chapternum} to {} (which should retain the value but not output it), generate my build, and the heading number is stilll there. When I look at the style sheet, my change has not been recorded. The only way I can get it to take is to edit the style sheet manually in the internal editor. This has happened often enough with other changes, that I've had to give up on using the style sheet editor.

I thought it might have something to do with the fact that I'd linked my project to the source files, but I've since turned that off, as I didn't want to take any chances that Flare would overwrite my style sheet on re-import (which may have been happening).

Has anyone else seen this problem?

And can anyone point me to something that explains how Flare handles style sheets when you are working with a project using imported files and have linking set on?

I'm finding the documentation on importing, which apparently comprehensive on first glance, isn't really telling me enough.

[LTinker68]

First, do you have just one stylesheet or more than one? I don't import FM, but when you import Word, it can create another stylesheet, depending on what you specified in the import settings. If you have more than one stylesheet, make sure you're modifying the correct one.

Also, are you modifying the correct medium? The "default" medium is used for online output and print output, if you don't specify anything specific for print. If you specify something specifically for print output, then it would be in the "print" medium. (Don't even use the "non-print" medium.) For instance, my <h1> tag for online output (using default medium) doesn't have an auto-numbering sequence, but my <h1> tag for print output (using the print medium) has an auto-numbering scheme applied. My <p> tag is defined in the default medium, and since I didn't change it specifically for print, then the print output uses the same style definition from the default medium.

[ksoltys]

I just have one style sheet - the one created for the project when I did the import.

As for mediums, I am using the default medium for the moment. When I start setting up my print formats, I'll either set up a print medium or create a separate style sheet and link it to the PDF target - I'm not sure which is the best approach yet. (I read something in one of the forums about problem with different mediums and table styles, and in an previous attempt to set up a style sheet, trying to use print and online mediums really messed up my formats). So right now, I'm sticking with the default.

[LTinker68]

The only other reason, then, that your styles aren't "sticking" is that there are inline styles defined in the topics that are overriding your stylesheet. Open one of the topics in the Internal Text Editor and see if there are inline styles in some of the tags.

[ksoltys]

The only other reason, then, that your styles aren't "sticking" is that there are inline styles defined in the topics that are overriding your stylesheet. Open one of the topics in the Internal Text Editor and see if there are inline styles in some of the tags.

By inline styles, do you mean direct formatting? There shouldn't be any, as I generally don't use direct formatting in Frame, and I did go through and remove what overrides there were before I created the imoprt.

How would I tell an inline style from a tagged one in the editor?

Keith

[LTinker68]

How would I tell an inline style from a tagged one in the editor?

You wouldn't see it in the normal editing view probably, unless the inline style showed up in a span. If you open the topic in the Internal Text Editor, you'd see "style=" and some style specified in a tag. For instance, say your paragraph is supposed to be black, but there's an inline style that makes it look blue.

Paragraph tag without inline formatting (style pulled from CSS) --> This is the desired setup:

Code: Select all

<p>This is the text in the paragraph.</p>

Paragraph tag with inline formatting (overriding CSS):

Code: Select all

<p style="color: #0000FF;">This is the text in the paragraph.</p>

Paragraph tag with span tag inline formatting (overriding CSS):

Code: Select all

<p><span style="color: #0000FF;">This is the text in the paragraph.</span></p>

The last thing you might want to check is the target -- make sure it's set to use either the "(default)" stylesheet or it's set to use your stylesheet by name. For instance, if your stylesheet is called myStyles.css, then the target should show the master stylesheet is either (default) or myStyles.css.

Oh, and you might want to remove the empty {} in the auto-number format. I just have it blank (or a blank space), but there could be a bug where if there are empty braces then it has a default value it fills in.

Lastly, when you said the change isn't taking affect -- is that in the output or the view in the XML Editor? The XML Editor (v4 and later) has the option to show web view (layout) or print view. Web view will show content using the default medium and print view will show content using the print medium. If you made the change to the default medium but the XML Editor is set to the print medium, then you won't see the change in the style because you're not looking at the correct view in the XML Editor.

[KevinDAmery]

To add to Lisa's points, one thing I have noticed with the Stylesheet editor is that if you make a change, Flare doesn't actually commit it until you click on another parameter in the editor. So what I would do is make your change to the autonumber, then click on a different parameter, then save the stylesheet.

Also, are you using source control? If you are, you should check the stylesheet out, make your change, save, and check it back in to make sure that the copy in source control is up to date.

[KevinDAmery]

Oh, one other thing - have Windows do a search in your Flare project folders for the stylesheet file and make sure there is only one copy. I ran into a situation a few years ago where a Flare user had imported a project from RoboHelp, and somehow in the process ended up with a copy of the stylesheet in the main project folder AND in the Stylesheets folder. The topics were pointing at the one in the projects folder, but when we were editing the stylesheet we edited the one in the stylesheets folder, so naturally the changes weren't showing up when we did a build. Once we pointed the topics at the correct stylesheet and removed the duplicate, everything worked as expected.

[ksoltys]

Well, I thought I had it fixed. I went into the Target settings editor and made sure that I had linking back to the source files turned off. But that's not it.

What I am seeing now is that I have settings in my style sheet that are displaying properly if I choose View Compiled Topic, but are not displaying when I build the WebHelp target. So I'm lost.

I am going to try (yet again) building a project from scratch but using the import file and style sheet from the current project and see what happens.

[LTinker68]

When I build WebHelp, I always delete the output folder before building. Sometimes browsers (IE in particular) don't pick up the new styles and load everything from the cache. Deleting the output folder before building tricks the browser into thinking it's going to a new site and will load everything from the site instead of from the cache. This is more evident with changes to the skin than the stylesheet file, but I do it anyway.

[ksoltys]

When I build WebHelp, I always delete the output folder before building. Sometimes browsers (IE in particular) don't pick up the new styles and load everything from the cache. Deleting the output folder before building tricks the browser into thinking it's going to a new site and will load everything from the site instead of from the cache. This is more evident with changes to the skin than the stylesheet file, but I do it anyway.

Nope, that's not it. I am at a point now where I can seem to change paragraph styles and some table styles OK, but some changes I make in the table editor are not being picked up - particularly the shading for repeated rows. The odd thing is that the tables display properly when I view a single compiled topic, but not when I build the project. Deleting the output folder before rebuilding makes no difference, nor does switching to IE from Firefox.

I'm going on holidays for a week, but before I do I'm raising a support ticket on this and a couple of other issues I've found.

Keith

[ksoltys]

Well, a couple of problems are solved.

I now have my style sheets updating properly, after setting up my project not to use linking. Changes I make are reflected when I rebuild.

The other issue, with table shading not displaying turns out to be a hardware problem. I have a dual monitor setup and I use a HP monitor in portrait mode as my main monitor and a Dell monitor in landscape mode as my secondary monitor. This is the one on which I was viewing the output.

I took a screen capture of the screen and SnagIt placed it on my main monitor and lo and behold the shading was there. So I moved my browser window over to the HP monitor and it showed up. So the Dell monitor is either flakey or doesn't display subtle shading properly in landscape mode. I may have to bug the help desk for a new monitor.

I'll sleep better now ....

Keith

[KevinDAmery]

The other issue, with table shading not displaying turns out to be a hardware problem. I have a dual monitor setup and I use a HP monitor in portrait mode as my main monitor and a Dell monitor in landscape mode as my secondary monitor. This is the one on which I was viewing the output.

I took a screen capture of the screen and SnagIt placed it on my main monitor and lo and behold the shading was there. So I moved my browser window over to the HP monitor and it showed up. So the Dell monitor is either flakey or doesn't display subtle shading properly in landscape mode. I may have to bug the help desk for a new monitor.

Before you do, check the colour depth of the output to the second monitor in the Windows display settings. If it's 16 bits (64 thousand colours or thereabouts) the difference between the shades may not be noticable. You want it to be 24 bits (16.7 million colours) or 32 bits (I don't remember how many colours... lots )

[ksoltys]

Before you do, check the colour depth of the output to the second monitor in the Windows display settings. If it's 16 bits (64 thousand colours or thereabouts) the difference between the shades may not be noticable. You want it to be 24 bits (16.7 million colours) or 32 bits (I don't remember how many colours... lots )

Good point. I'll check it when I get back to work - I'm on holidays this week. I'm pretty sure the display settings are the same for both monitors (it's a dual-headed Nvidia card), but who knows. Thanks for pointing that out - it's something that never occurred to me.

Keith

[NorthEast]

I had a similar issue with a template I was working on, a light shade I was using was practically invisible on some displays (nothing to do with colour settings, just some displays are better than others). I changed it to a slightly darker shade, as I reckoned if it was problem here, then it'd also be a problem for some of our users.

[ksoltys]

I've fiddled with the monitor setttings and I now have the alternate shading showing up on the 2nd monitor. I need to tweak it a bit more to get the two monitors as close as I can, but fiddling with the gamma settings in the Nvidia control panel seems to do the trick.

Both monitors are set to the same colour depth, so that wasn't the issue.

Keith