'display' property in CSS not working with print media?

[mcondron]

I'm working with a trial version of Flare 3.1, and I'm finding multiple problems with MS-Word output. I'm posting this one first kind of arbitrarily.

Is the 'display' attribute in my CSS file supposed to work? When I add a section like shown below nothing changes. It ought to prevent tags with the specified IDs from showing up in my print output, shouldn't it? It works perfectly as it is supposed to when I open the associated HTML files in Internet Explorer and try to print.

I do have the Stylesheet Medium set to \"Print\" on the \"Advanced\" tab of my MS-Word target.

Code: Select all

@media print
{
	#banner
	{
		display: none;
	}

	#footer
	{
		display: none;
	}
}

[crdunn]

This is a bug in Flare. The \"display: none\" declaration should work as you describe; at the moment it causes Flare to strip out style information and the newline character, but Flare won't remove any of the text. I've found it's easier to remove the display declaration and just use Word's find and replace function to locate and remove the styles you don't want. (You could comment out the declaration, but stylesheet comments have a tendency to migrate upwards in Flare.)

We reported this as a bug back in the version 2 days, but it (obviously) hasn't been fixed yet - it's probably worth reporting again if you're that way inclined.

[mcondron]

Thanks for the info. Unfortunately, I can't do what you've suggested because I'm trying to export to MS-Word something that was previously exclusively screen-based HTML Help. My intent was to shut off areas of the topic pages that look good in the HTML Help viewer but don't make any sense in a document that will be a series of pages. I will try to report the bug, although I don't acutally own a license at this point, just evaluating. (So far I have serious concerns...is there an Emoticon for \"disappointed\"?).

[crdunn]

Yes, this is the same as what we are doing. I may not have explained it well.

Here's our workaround, for anyone who might need it:

* Build and view your MS Word target.
* In Word, open the Find and Replace dialog (Ctrl+H)
* In the Find what field, type ^? (or click on Special and select Any Character)
* With your cursor in the Find what field, click on Format and select Style...
* Select the style you want to strip out, then click on OK.
* Click on Replace all.

Repeat the process for every style you want to exclude from your printed output.

This isn't an ideal solution, partly because it doesn't work if the style was applied to a div or table element, but it does work for paragraph and span/character styles.

[mcondron]

I see what you mean now. This is indeed terribly clumsy but will certainly get the job done. I'll try it out and see if we can live with it. Maybe I can make a macro or something to do it automatically.

[LTinker68]

A better solution would be to create print-only versions of the styles. Or create online-only and print-only styles instead of using the \"default\" style. If you create online-only then it goes into one \"medium\" in the stylesheet, and if you create print-only then it goes into another \"medium\" in the stylesheet. If you put anything in the \"default\" medium, then that style will be used by either medium if there isn't a corresponding style specifically stated in the appropriate medium. So if you add a list but don't specify a style for that list in the print-only medium, then it'll use whatever style was set in the default medium. If no list style was specified in the default medium, then it'll use whatever Word has set for the list style.

Then you set the online target to use the online-only medium and the print target to use the print-only medium. You shouldn't have to do any after-build modifications at that point. However, if you miss specifying a style, then the online output will go with the browser's default setting for that style and the print output (Word) will use its default setting for that style.

[LTinker68]

My intent was to shut off areas of the topic pages that look good in the HTML Help viewer but don't make any sense in a document that will be a series of pages.

For this situation, you probably want to use conditional tags. For instance, I sometimes put graphics in a topic with two different resolutions, one for online output (96dpi) and one for print output (300dpi). I don't do that for all graphics -- just things like diagrams and such where nice clean lines are preferred in the print output.

Anyway, I put both graphics in a topic next to each other, then I select the low rez version and set a online-only condition tag to it and then select the high rez version and set a print-only condition tag on it. My online target is set to include online-only conditions and exclude print-only conditions and vice versa for the print output. (I also put an online-only condition tag on the folder containing the low rez version and a print-only condition on the folder containing the high rez version so the print version isn't included with the online output -- it would unnecessarily increase the output folder's size.)

I also do this with text sometimes and special effects. For instance, I have togglers that say "View the screenshot" that I condition out of print output, because the effect wouldn't work in print output so there's no reason to include the text.

[crdunn]

A better solution would be to create print-only versions of the styles.

This would only be a better solution if Flare did not ignore the \"display: none\" declaration.

How is it better to have a print-only version of a style if you are going to remove all occurrences of that style from the target document as soon as it is compiled? It might make the find-and-replace process a bit more interesting, but I can't see any other benefit.

[LTinker68]

Well, technically, Flare does recognize the display: none property -- in online output. Word doesn't use display settings like that. I believe you could set text to be hidden, but that's not a CSS element. It's similar to a CSS element (display: none), but it's not actually a CSS element. I haven't used Word 2007 (and from what I hear, I don't want to), but it's possible that Word 2007 is more in tune with using stylesheets than Word 2003 and earlier. If that's the case, then display: none may work for Word 2007 output.

So yes, MadCap could probably have print output for Word convert display: none to a hidden format or whatever Word has, but it's probably a low priority to them, especially since applying an online-only condition to the same block of text would work to prevent the text from being outputted to Word, which is essentially what you want.

And definitely put in a feature request to have display: none work in Word output. If a lot of people put in that request, then it'll get a higher priority of implementation.

[mcondron]

What seems to make the most sense to me is that Flare should recognize that a medium setting of \"print\" should cause the @media print {} stuff to turn on, and it should not even be sending anything into the output file that I have told it should have a property of display:none. Flare is taking responsibility for the medium very clearly in their \"Stylesheet Medium\" section of the \"Advanced\" tab of the MS-Word target page.

I wonder if other things in @media print {} are handled properly, or is this just limited to display:none???

Any, just FYI -- I just bought and installed Office 2007 today for myself at my home job (I've had it forced on me at my real job). It behaves in this matter exactly as Word 2003 did.

[wclass]

I think we've had this \"philosophy\" discussion before.

We generate mostly online help, but need a few things sent to Word occasionally. We have \"navigation bars\" with hyperlinks at the top of topics in our online help that look fine online - and make no sense printed out.

Yes, we could put condition tags - lets count - 20+ projects, average 500 topics - that's a lot of changes. Wouldn't it be nice if we could just make a single change in one spot, namely set the display property to none for the paragraph we don't want, and bingo, our output looks fine.

Flare uses CSS, and Word doesn't, so therefore it has to map everything, why pick on just the display property? We use the media setting to change the font family and size for print output

I'll report this as a bug again - by the way, if the same person puts in a request does it get a higher priority?

[crdunn]

I wonder if other things in @media print {} are handled properly, or is this just limited to display:none???

I've only had problems with \"! important\", which causes problems in every medium.

[crdunn]

especially since applying an online-only condition to the same block of text would work to prevent the text from being outputted to Word, which is essentially what you want.

Actually, having done five minutes' research into WordprocessingML, what I want is for Flare to map \"display: none\" to \"<w:vanish/>\"

I agree that it probably is a low priority for Flare's developers, and I'll raise another request.

[doc_guy]

Am I not following this discussion properly because doesn't Flare provide an OnlineOnly condition that will do what you want? I mean, its not in the CSS, but that is what conditions are for.

[doc_guy]

We generate mostly online help, but need a few things sent to Word occasionally. We have "navigation bars" with hyperlinks at the top of topics in our online help that look fine online - and make no sense printed out.

Yes, we could put condition tags - lets count - 20+ projects, average 500 topics - that's a lot of changes. Wouldn't it be nice if we could just make a single change in one spot, namely set the display property to none for the paragraph we don't want, and bingo, our output looks fine.

Why aren't you doing this in the master page? I have several printed master pages (one for frontmatter, one for chapters, and one for appendices) and I have a WebHelp master page. Navigation stuff and headers and footers are all taken care of at the master page level in the WebHelp master page. If you do this in every topic, you run the very high risk of messing up somewhere in the process.

This is, after all, the purpose of single sourcing your content: you do it once in one location, then import it into other locations. When you need to make a change, you change it at the source, and all referenced instances just work.

[mcondron]

The master page idea will only work for blocks of items, like headers, footers, navigation areas, etc. You can't use it to change fonts, colors (like eliminating hyperlink coloring for printed output) or a bunch of other things. @media print {} really needs to be fully supported. It is a very powerful way to realize the single-source philosophy -- your content stays the same, but your CSS specifies how it should be formatted depending on the medium. That is the whole purpose of the @media thing in CSS. Flare seems to be implying that it supports this because it clearly has a place to select the medium. It is just not impelmenting it correctly.

[doc_guy]

But the @media print { } stuff does work for all those things.

My suggestion to use the master page was to cover the \"navigation bars\" at the top of each of your topics.

My @media print { } settings totally change the fonts, their styles, etc. in my printed output. In my online output, I have links in blue underlined font. In my printed output, my links are in black font, no underline (so you don't see that they were links in the online version). For styling, this works great. For excluding content, I use conditions; PrintOnly for content that only appears in Print. OnlineOnly for content that only appears in my WebHelp output.

The @media print { } works great for several of the things you have suggested. The only one I've heard mention in this thread is the the display:none setting. However, Flare already provides a separate method to have content displayed in one medium and not another.

Where else isn't the @media print { } functionality supported in Flare? What do you want it to do that it doesn't?

[mcondron]

You are correct, master pages can be used control whether certain blocks of text appear in various types of documents. The @media CSS thing works for other stuff.

The display:none alternative is simply another way to remove blocks of text. For some purposes, it is much more convenient than creating master pages. Consider that I currently have about 300 HTML files that I want to turn into printed documentation (or at least a Word or PDF file). They all have blocks of <div> I should be able to shut off with a single line of CSS code and no modifications to the actual HTML itself. Is there any way to use my existing HTML files, keeping the content in some of the <div> blocks and removing what's in other <div> blocks?

[doc_guy]

We're talking about a couple of different things here.

Masterpages for printed output are useful for defining headers and footers in your Word output. They also allow you to set page margins, page type (recto/verso), page size, orientation, page start number, etc. They don't allow you to set the default font for that page, or any other attributes of the running text that may appear on that page.

Masterpages for online output are useful for adding breadcrumbs to the tops of your topics, and adding a copyright footer to the bottom of your topics. These elements will be applied to your XHTML files during the build process, so the content in the master page is passed to every page in your project (that is linked to that master page in the TOC.) These masterpages do not allow you to modify anything in the HTML's <head> element, so you can't use MasterPages to modify the styles for these pages.

All style issues are done in the style sheet (with apparently the one exception of hiding text that you don't want displayed in printed output).

As I said in another thread, if you don't like the way Flare does something, enter a bug report/feature request. In the mean time, you have to work around the current functionality, so you have to figure out another way to do it.

With your 300 topics, I'd probably do a global find/replace, where I found all the divs that have have the display:none attribute, and modified it somehow to add another attribute for MadCap:conditions, setting it to the PrintOnly condition.

It's not as elegant as a one-line CSS solution, but unless MadCap acts on your bug report, it's what you got.

[wclass]

Sometimes we get bogged down in workarounds. I know we need them to get by, but surely only till a bug gets fixed.

As crdunn pointed out earlier (yes, we work at the same place), when you have \"display : none\" to transpose a style into printed output, Flare strips the carriage return/new line from the end of the paragraph and runs it into the next paragraph, still exposing the text. That is just wrong. It is a bug. It was reported at least a year ago. I know Word is tricky to handle as it is not always standards compliant but this time Flare is sending broken text. If Flare ignored the display instruction because it wasn't supported, OK, I'd look for a workaround, but it does do something, and it is broken.

Suggestions to use condition tags and master pages are not appropriate here - they are terrific features and I use them both in many places (hey, I LIKE Flare). We have a work-around - use Word's Find/Replace. It is much quicker to overcome the specific bug mentioned.

And yes, I have re-reported the bug.

[crdunn]

when you have \"display : none\" to transpose a style into printed output, Flare strips the carriage return/new line from the end of the paragraph and runs it into the next paragraph, still exposing the text.

At the risk of making myself look even more obnoxious than I have already, I'm going to be pedantic and say that Flare doesn't strip the newline character - it changes the CSS paragraph style into a WordprocessingML character style, which has the side effect of removing the newline character. This is special processing applied only to \"display: none\" only when building an MSWord target.

It's still a bug, as this particular style was defined at the paragraph level (<p class=\"hidden\">, not <span class=\"hidden\">) so it should remain a paragraph style regardless of whether it's hidden, and I've reported it accordingly.

[wclass]

Well I'm happy - this bug has been fixed in Flare v4!