I might begin a rant about another Flare bug

[sdcinvan]

Hello all,

I'm having a bad Flare day.

Nothing but troubles trying to duplicate my document's perfect PDF output in HTML5 format.

The bug? This must be a bug... The Preview function simply doesn't work as I would expect it to. It is bad enough that the XML display is wonky for medium: non-print but the only way to see an accurate rendering is by full publishing.

For instance:

Code: Select all

@media non-print
{
	p.bullet_CheckBox
	{
		background-image: url('../Images/CheckBox_Bullet.png');
		background-repeat: no-repeat;
		margin-left: 64px;
		padding: 2px;
		padding-left: -2pt;
		padding-top: 0pt;
		min-height: 11pt;
		mc-multiline-indent: 35px;
		mc-hyphenate: never;
	}

In preview, that checkbox image will not appear but if I publish, the checkbox appears. This is just one of many issues with preview of non-print output. Am I doing something wrong?
Anyhow, I am frantically trying to get my margins and paragraphs corrected for HTML5 output but it isn't a treat if I must publish for ever test of css change.

Wishing everyone a much better day than the one I am experiencing.

[Msquared]

Keep at it. There's just more to learn but it will be OK. I went through exactly the same steps as you, frustration at getting the PDF styles, when it had been "so simple" in Word, then elation when I got it together, and discovered a new baseline for "so simple". Then the WebHelp, which again had worked (sort of) in RoboHelp, and a whole new set of frustrations and "features". But I finally climbed the mountain, with the help and encouragement of some lovely people here, and the view is wonderful.

A tip you may find eases the frustration somewhat. I created special Review targets, one for each of my output types. This uses a special Review TOC. So, if I need a quick and speedy output of a few topics, to check the styles, or to see how they hang together, or to send for review, I just add those topics to the Review TOC and build the appropriate Review target. For a few topics, that's a quick as Preview As, and unlike Preview As, the output isn't in a modal window (a stupid implementation, if ever there was one).

The final neat thing I discovered was that you can copy and paste sections from one TOC to another in Flare. Just select the TOC book or sections you want to copy, right click and select Copy. Then you can paste into your Review TOC.

[Paul Griffiths]

I don't know if it's relevant to your preview problem, but the Flare Help says that mc-multiline-indent is supported only for print outputs.

[RamonS]

While I see a clear benefit in a preview function it really counts what the output shows. Will you be happier if the preview is top notch and the output is borked up? I doubt it. I think Marjorie provided an excellent suggestion and maybe it is worthwhile to even craft a handful of test topics that make use of all styles in the style sheet. That way you can spot much quicker if changing a style impacts something else.

[Nita Beck]

I notice that you're using the non-print medium for your HTML5 target. Others on the forums, particularly LTinker68, have said that one should use the default medium, not the non-print medium (despite its name) for online targets. Sorry that I do not readily recall why, and hopefully Lisa will join the discussion. In my own practice, I use "default" for online, "print" for any little differences I want for Help topics when printed (e.g., setting a max width for images so they don't run off the page), and a custom "PDFprint" or "pubprint" for my PDF/print outputs. You might see what happens when you use "default" for your online targets.

[sdcinvan]

Will you be happier if the preview is top notch and the output is borked up?

Why must it be one or the other? I think it is reasonable to expect (and demand) that non-print preview works just as well as the print preview function. What is the point of the preview function, if it doesn't work properly.

All I can say is that it is fortunate that I began learning Flare for PDF output because I might have formed a different different attitude about this product, if I had first worked on HTML output. Clearly, there are far more challenges with achieving a desired HTML format. In part, that is fine... I understand that some of the issues may be related to missing support in the HTML framework.

Still, the darn preview should be more useful. Grrr.... and happy Friday all!

[LTinker68]

As Nita says, I don't recommend non-print, mainly because you're repeating work with the CSS styles, because the print medium won't inherit from the non-print medium and vice versa, so if you want the same style definition for those two mediums, then you have to enter it twice in the stylesheet. To me, it's simpler to put everything in the "default" medium, and only define in the print medium those attributes that you want changed for the print medium. That's just my recommendation, though. I think Dave Lee uses or has used the non-print medium and has no problems. I also recommend it because that siblings-not-inheriting-from-each-other aspect of CSS tends to throw off a lot of users who are new to CSS, HTML, etc.

Regarding the preview problem... Two things. First, I have never found a WYSYWIG editor that has accurately reflected exactly what you see in the output. In part that's because browsers don't behave the same as other browsers and print output (PDF, Word, FrameMaker) is an entirely different animal, so you will probably never find a WYSYWIG editor that will be completely accurate. That said, some things should be able to be previewed, and any problems we've discovered in the past have reported, and some have been fixed and some haven't. So if you see a problem, report it. Bitching to the choir won't get you anything but a bunch of calls of "amen, brother".

Also, don't forget that the preview is based on the target selected as the master target. If your print output is set as the master target, then a preview of the default medium or non-print medium may not appear correctly because the master target is set to look at the print medium (or whatever medium you specified for print output). You might try changing the master target to being the one that uses the non-print medium. I'd be curious if that takes care of the preview problem. It might not, so if not, submit a bug report and include the style definition you posted above in the bug report so support can try to replicate the issue.

[NorthEast]

As Nita says, I don't recommend non-print, mainly because you're repeating work with the CSS styles, because the print medium won't inherit from the non-print medium and vice versa, so if you want the same style definition for those two mediums, then you have to enter it twice in the stylesheet. To me, it's simpler to put everything in the "default" medium, and only define in the print medium those attributes that you want changed for the print medium. That's just my recommendation, though. I think Dave Lee uses or has used the non-print medium and has no problems. I also recommend it because that siblings-not-inheriting-from-each-other aspect of CSS tends to throw off a lot of users who are new to CSS, HTML, etc.

Yes, I use a medium for each target output type; e.g. I have a pdf medium for PDF targets, mobile medium for WebHelp Mobile, non-print for WebHelp (although it'd probably be better to call it WebHelp).

I define all styles in default (no medium), so these are inherited by all mediums. Each medium only contains those style properties which are different to default. I don't actually set any target to use default, they all use a specific medium.

I make sure what I define in default is sensible and is suitable for as many different output types as possible; e.g. I set all font sizes in ems (i.e. relative sizes), so that I only need to adjust the font size in body in any given medium.
Some styles in default will actually be blank if they are specific to a particular medium; just so that the style is still available in the editor no matter what medium I'm using.

I think the problem with using default to mean a particular target/output type, is that you might define a number of styles in default that you don't really want inherited by your other mediums. For example, if you set a style property in default which is specific to your online/web output, but you don't want this in other outputs; then you would then have to add this style to all the mediums used by the other outputs to reverse/compensate for the style in default.
It might work in your case if you're only ever using two output types and one medium, but it might be a headache if you ever need multiple outputs and mediums.

[sdcinvan]

I notice that you're using the non-print medium for your HTML5 target. Others on the forums, particularly LTinker68, have said that one should use the default medium, not the non-print medium (despite its name) for online targets. Sorry that I do not readily recall why, and hopefully Lisa will join the discussion. In my own practice, I use "default" for online, "print" for any little differences I want for Help topics when printed (e.g., setting a max width for images so they don't run off the page), and a custom "PDFprint" or "pubprint" for my PDF/print outputs. You might see what happens when you use "default" for your online targets.

Actually, the example I posted, every element is unique to the non-print medium. But yes, I agree that it is best practice to enter all the styles in the default medium and carry over only what changes into the specific print and non-print mediums.

[sdcinvan]

Also, don't forget that the preview is based on the target selected as the master target. If your print output is set as the master target, then a preview of the default medium or non-print medium may not appear correctly because the master target is set to look at the print medium (or whatever medium you specified for print output). You might try changing the master target to being the one that uses the non-print medium. I'd be curious if that takes care of the preview problem. It might not, so if not, submit a bug report and include the style definition you posted above in the bug report so support can try to replicate the issue.

The problem I posted [above] turned out to be a bug... where HTML preview doesn't select the correct medium, as defined in the target; bug report #52240.

[sdcinvan]

To all,

Thank you so much for your participation in this thread. All comments are always appreciated, all the time.

Starting off this [unseasonably cold] Monday, problem free, and its going to stay that way all week!