creating a (possibly) single-sourced document

[fchan]

When you're creating a new project, if you know that a PDF version will need to be generated, but you're not sure what other formats (e.g., online help) are required, do you start off pretending that the project is just for print, and worry about conditionalizing the text later? I'm just wondering how other people approach this. Thanks.

[Nita Beck]

I wouldn't so much worry about conditionalizing content for PrintOnly or ScrrenOnly at this point.

But I would opt to use cross-references instead of hyperlinks. They can serve print output and online output equally well (although differently formatted), whereas the same is not true of hyperlinks.

[i-tietz]

To be honest: I would start to use conditions right from the start.

Example:
We just started a new software with a new help that follows a new concept. I'm happy for everything we find out about the new concept in the generating process. That way we see what works and what doesn't.
AND: By the time the new software has the size of the "old" software our project will contain thousands of topics ... I wouldn't want to go through it then to change something globally ...

[SteveS]

I also use conditions right from the start and act as if I've got an online (webhelp) and print versions. Although in your case the conditions we be somewhat limited because all the content will be used, the conditions are only used when you want something to behave differently.

The main reason I do this is for ease of viewing and editing while I'm creating the document(s). Once I'm happy with the online version I can publish a print version.

If you are sure you won't need an online version for release, just keep using the default stylesheet setting, don't get bogged down defining your styles as print. If you do need to create a different style for print compared to online you can do so and the cascade kicks in, otherwise print will use the default styling.

HTH

[NorthEast]

Adding them while you're writing the topics will be easier than adding them later, as you have to go back and find where they're required.
Of course, adding them at the start could be a waste of time if they're not required.

I would suggest having a good think about what conditions you might need - you may not actually need print/screen conditions.
I don't use any conditions like print/screen to handle different types of target, as the content in my help and PDF targets is largely the same. I only use conditions to handle different products/variants.

I do remove the mini-TOC from the PDF target, but I don't use conditions to do that; I set the mini-TOC style in my 'print' medium to display:none, which hides it in the PDF. You can use this technique to hide any tag/style from a print target (it doesn't work for help as it can be revealed using a search).

Also, Nita's point about cross-references is a good one.

[Nita Beck]

So I'm not misunderstood (for lack of expressing myself clearly!), I am not advocating not bothering with condition tags when first creating a print target and not anticipating an online target. The poster asked about conditionalizing things for print or online early on, and that's what I said I thought wasn't necessary. In my own practice, I use a slew of condition tags right from the get-go when starting a new project. But if I'm developing a manual 'cause that's all the client wants, I focus on developing that manual, period.

But in thinking more about this, there is another thing that I do -- just in case there might someday be an online target: I don't use inline formatting, ever! Inline formatting might work wonderfully for the print target, and it'll cause big problems if there ever needs to be an online target. Then all that lovely but ill-created formatting will be highly likely not to work whatsoever in the online target.