File > Send To gives me that Word document with all the tags and not formatting. Also, I have to pick an XML data view??? I am sure there's something I'm missing.
I tried setting up a Word target, but I think that's overkill for one topic.
I copied and pasted out of the HTML output, but it's got to be easier than that.
For these types of situations, I create a "test" target and "test" TOC. I then add the topic to be printed to the test TOC and run the test target. If I need to output a different topic, then I delete the old topic from the test TOC and add the new one and re-run the test target.
Lisa Eagles may soar, but weasels aren't sucked into jet engines. Warning! Loose nut behind the keyboard.
LTinker68 wrote:For these types of situations, I create a "test" target and "test" TOC. I then add the topic to be printed to the test TOC and run the test target. If I need to output a different topic, then I delete the old topic from the test TOC and add the new one and re-run the test target.
Thank you! This works; however, the images are in a ...\Resources\Images folder and the snippets are gone completely. I've gone through all the Target settings and I cannot intuit what the setting would be to include the snippets as text and embed the images in the output.
How do I get the snippets and the images to embed in the Word document?
I'm guessing they do it like that because of Frame, which automatically has the graphics in an external folder. ??? They need to add an option for Word output. However, this is a pretty fast workaround .... once you know about it.
BTW, the snippets do work. I just published the wrong file to Word the first time; i.e., one without any snippets.
I have a super simple minded question. I can't seem to export a flare project to MS Word without every single line being on a new page. I did set up a separate target for MS Word. I have MS Word 2003. I have made this happen before a looong time ago, say, versions of Flare ago. I have Flare 5.0.1
Double-check your styles for the <p> tag in the print medium of the stylesheet. Make sure you don't have a humongous line height declared, don't have page-break-before or -after set to always, don't have a humongous margin- or padding-bottom value set, and so on. Check the body tag in the print medium, too.
Lisa Eagles may soar, but weasels aren't sucked into jet engines. Warning! Loose nut behind the keyboard.
All that has been done. The first thing I checked was styles in word and paragraph tags to see if they could tell me anything right off, and then my css.
I have no line height specified, so I will try specifying a line height for all mediums.
Okay so I did that. I specified a line height of 13 and I do get things appearing in a more unified fashion (but still a bit whacked). That explains why I used to see Word output, we made line heights defaults because specifying line heights was causing the formatting for Notes, Warnings, Tips etc. to be misaligned with the heading item, er, autonumberclass item.
Now, my first thought is to create a css just for word targets and specify things as best for word.
My questions are:
1. should I have a styel sheet just for word?
2. do I need to specify line heights for my other output (web help, pdf)?
3. If so, what do I do about the misalignment of autonumber items, such as Note etc?
4. Do I need to specify a line height for them? (maybe I just answered my own question).
You can use your existing stylesheet for both online and print output using the media option.
I normally set my default stylesheet values to those used by my online outputs. Anything that is different I change using the print media in the stylesheet. DO NOT use the non-print media for your online styles, when stylesheets were first developed the idea was to use non-print for multimedia, not online like some peolpe have tried (unsuccessfully, I might add).
I Don't set line heights. If you do and you change the font size you can get in trouble. If you have to, try setting the default font size on the body tag and use proportional font sizes throughout. It is, however, a tin of worms if you get it wrong.
HTH
Steve
Life's too short for bad coffee, bad chocolate, and bad red wine.
But before I specified line heights, the word out put was a page
for every
single
line.
I had 47 thousand pages in my out put. The line height cured that problem. What was the real problem? Can anyone tell me?
The problem you are encountering is only fixed by line heights if there was a line height set in the stylesheet.
Here is what I would do: create a new style sheet and associate it with the Word target and build it. That will have very basic styles, but it should give you a bunch of default options. That will show you what it would look like with no styles set.
Then I'd add the existing <p> style to the new style sheet and build the output and see what happens. As you continue to add styles to your new style sheet you will see when the problem creeps up, so you will know what style is causing the problem.
You could also post your style sheet to the forums and we could take a look at it to see if there is anything obvious. Specifically in the <p> style, since you are saying each line is a new page.
Well, unless it's something hidden in the <p>, there wasn't a line height. We are exporting to PDF beeyooteefully, with no problems.
When Lisa suggested that the line height might have been the problem (I had checked everything else), I put one in and presto, that fixed it, although the layouts aren't working quite right, the bottom of each layout is displayed at the top of each page.
Exporting to word was just a solution to be able to export for editors, none of whom have Flare. It's not a deliverable in anyway, so I will have to put it on a back burner and play with the stylesheets another time.
livetoski wrote:Well, unless it's something hidden in the <p>, there wasn't a line height.
Remember that in CSS styles can inherit attributes from other styles. So if there was a line height set in <body> or <html> it would apply to every tag in the topics unless over-ridden by something closer (i.e. your setting in <p> over-rides anything in <body>). Similarly, if you have any Divs in the document, the styles in the Div will be inherited by the tags contained within it - however, Word output always ignored Divs in previous versions of Flare, so odds are that isn't the cause in this case.
Until next time....
Kevin Amery
Certified MAD for Flare
I have been lurking around this post with great interest, as I am having exactly the same problem and have not yet found a solution. Following the above suggestions and working in a copy of my project, I removed all line-height properties everywhere in my CSS and then attempted to output to Word. No dice. Every page consists of a single line, and I've got 3500+ pages in the resulting document.
Although I haven't explored this idea yet, I have a hunch that the problem lies in how I've defined the size of the footer block (or whatever it's called) on the pages (first, left, etc.) in my page layouts. I can't remember exactly what, but when I looked at the doc in Word, there was something fishy about the footers. When I opened the Page Setup window, Word would give me some error about some measurement somewhere, and it wouldn't even let me switch to the Page Setup window's Layouts tab. Word would crash. So my hunch is that there's a bad parameter having to do with the size of the footer area...
Just an idea. Hope this doesn't send anyone on a wild goose chase.
Nita
RETIRED, but still fond of all the Flare friends I've made. See you around now and then!
I don't use Page Layouts with my Word generated content, so that may be why I have never seen this.
If you are generating for Word for some internal review, you may want to create a special page layout just for the Word output that doesn't have any headers or footers. In fact, you can just have a single page in the page layout with just a body frame. That may help you solve the problem you are encountering for Word output. But it doesn't make Word output that is deliverable to customers. So if you are just doing it for internal reviews, then that may help.
If you are doing internal reviews at the topic level, you may also want to send them out for review and have people in your organization download MadCap X-Edit. There is a review version of X-Edit that is free that lets people send you comments on your topics, and you integrate them directly into the Flare project. We have used it successfully at my place of business.
Well Paul, I certainly like your idea of starting from scratch with a CSS, which we've never done as we've just imported from FrameMaker and cleaned up as we went.
You were right, it was the body tag with the line height defined. This is a result of my totaly ignorance of styles sheets, I only learn when I am faced with a dire issue.
For my generation to webhelp and pdf I have recently removed all the line heights, by going through a text editor, and I reapplied line-heights only to body, and H1. I used numbers, which can't be done within Flare. This, according to a bunch of online stuff I read is the way to go, so that line heights are relative and all browsers can use the numbers for line-height.
I am curious about Steve's suggestion not to define line heights, because otherwise my generated output looked incredibly squishy.
I am hoping that Nita will solve the exporting to word. The layout is likely key, as my layout slops over to the next page.
What are you generating in Word that you aren't using a layout for? How are you formatting your doc?
I didn't realize there was a free xedit that allowed editing, I thought it was just a viewer at the free level. I will look into that. much better, if that is the case.
Thanks. It's all been helpful. This is NOT my forte. Linda
The default line height, which is used is no line height is specified anywhere, will be the default in Word, as if you are typing normally (and is dependent on the font size). So if you remove all line heights from your style sheet, then you should just get a default height based on the font that is being used.
My suggestion to output to Word was based on the idea that if you are sending it to reviewers, you don't need a fancy layout. They are just looking at content to approve it. I provide my final product in PDF form, generated directly from Flare using standard page layouts. But if Word were causing me the trouble you are describing, and Word is only for reviewers, then I would just send the raw text/images to Word and not worry about formatting because they aren't reviewing formatting. They're reviewing content.
The option to edit content in X-Edit can be set in Flare when you send the document out for Review. The person who receives it can either edit it (if you set the flag), or they can insert comments (if the flag is set or not.) This is NOT akin to Word's track changes, feature, however, because you won't know what they changed, if they made changes. For this reason, you may prefer to not set the flag, and only allow reviewers to insert comments. That will allow you to see all proposed changes and make them yourself.
Good luck. Let us know what else we can do to help.
I can confirm that my page layouts, specifically the footer blocks within, were causing the one-line-per-page in my Word output. My footer blocks were actually "bleeding off" the page layouts a little. For some curious reason, their doing so does not give my PDF output any kind of problem, but they certainly do not play well with Word. Once I "shortened" the footer blocks so that they did not "bleed off" the edge, then outputting to Word worked. I got a fairly decent looking doc, though I'd need to do some tweaking were I going to deliver Word as the final deliverable, which I'm not. So, for the sake of sending out a review draft in Word, I think what I'm now getting will suffice. I've trained my reviewers to ignore bad page breaks, etc.
I literally just delivered my first completed Flare-to-PDF user guide within the last hour, after a many-months-long development cycle. The review process had its difficulties, as the review drafts, not just the final deliverable, were PDFs. (My client is a large publishing company, and they are used to marking up PDFs.) The PDFs were fine in the abstract, but everyone felt that the review process just took longer. In future, I'll now be able to go the Word route for review drafts.
Nita
RETIRED, but still fond of all the Flare friends I've made. See you around now and then!
Thanks for posting that Nita! I will create a very minor layout for word and apply that.
We've been exporting to pdf and webhelp for a few years now and I keep working here for a few reasons, even though now I've moved and its a bit of a commute, and one of the reasons I am still here is to keep working with Flare, as opposed to going someplace where they are using,say, Word and RoboHelp (my flesh creeps).
Nita, did you sort this out? I removed headers and footers and things look fine, for one offs of a couple of pages for editors. I will experiment with headers and footers at a later date. Linda
There was nothing more for me to sort out. My production deliverables were PDFs, while my review deliverables were Word. For the review drafts, I didn't need anything fancy, just a Word doc that my reviewers could edit with Track Changes on.
Sorry I have nothing else to add to this forum post.
Nita
RETIRED, but still fond of all the Flare friends I've made. See you around now and then!
