问题标签 [help-authoring]

Any free alternative to Robohelp? Prefer open source

Need some sort of online help authoring tool for an open source project.

我正在寻找可以满足此类要求的帮助/文档生成工具：

• 它应该支持 c# 编译器生成的 xmldoc 注释，或者（甚至更好）直接支持 sandcastle
• 它应该支持导入 MS Word 文档。
• 它应该支持创建从概念文档到源代码生成的参考文档的链接。
• 如果它支持 MS Word 中的概念文档创作，那就太好了

更多细节。我的项目是.NET 的框架/库。它有几个 VS 解决方案，总共有 50 多个 C# 项目。首先，我想从我的项目的源代码中生成帮助（未来的 chm & help2 & help3）。我将该文档称为“参考文档”。沙堡（尤其是使用SCFB) 可以很好地做到这一点。但是（我想这是很常见的情况）我有一些关于框架/库的附加文档。该文档位于 MS Word 文件中（5-10 个文件）。我将该文档称为“概念文档”。我想用概念文档和参考文档（如 MSDN）制作一个可靠的帮助系统。我希望帮助的概念部分包含链接（URL），这些链接引用了来自框架/库的每个 .NET 类型名称的帮助的参考部分。（显然任何帮助系统最终都只是 HTML）。

问题是如何创建这些链接。MS Word 文件对 C# xmldoc 一无所知。Sandcastle 不支持 Word 文件。所以我必须采取一些帮助创作工具（HAT）。到目前为止，我找不到任何适合我的工具。如果有任何帮助，我将不胜感激！

所有工具的绊脚石是链接自动创建。我希望在生成期间自动创建链接（可以在构建服务器上进行）。为什么会自动？因为它允许轻松重命名类型。例如。我在概念文档中有一些文本：“用于访问请求处理上下文使用 XOperationContext 类型的静态属性 Current”。这里 XOperationContext 是一个类型名称。我希望它成为结果帮助系统中 XOperationContext 类规范的链接（URL），而无需付出任何重大努力。我想在 Word 中（可能安装了一些 HAT 的插件）或在 HAT 的编辑器中将其标记为“如果可能，请制作此单词链接”。在生成过程中，如果存在具有此类名称的类型名称，则每个此类单词都将成为链接。

我知道这些工具：

• Toolsfactory Doc-o-Matic（现在使用）
• Innovasys DocumentX 和 HelpStudio
• ComponentOne 文档帮助

Doc-o-Matic 支持链接自动创建。真正自动。它尝试为 PascalCase 中的每个单词创建一个链接——非常出色。但它不支持 MS Word。Innovasys 和 ComponentOne 的软件不支持自动创建链接。Innovasys 的软件不支持 MS Word（对此我不确定 100%）。

我试图在 Innovasys 和 ComponentOne 的论坛上提问。到目前为止没有运气。Innovasys 的软支持方案和我的一样：在单独的工具 - HelpStudio 中创建概念文档，并使用另一个工具 - DocumentX 从源代码生成帮助。但是无法自动创建链接和导入 MS Word 文件。

因此，请分享您对该常见任务的过期时间（我相信它应该是常见的）。

ps如果我没有从英语语法的角度正确解释我的想法，请告诉我，我会再试一次。

我需要为 Eclipse 插件编写在线帮助（Eclipse 帮助格式）。我尝试了对来自 Instantiations 的 RCP Developer 的 Help Composer 的评估，它几乎可以满足我的要求。然而，在每个许可证 500 美元的情况下，这对我的需求来说太过分了，而且超出了预算。

当然，必须有一些其他工具来管理帮助项目、组装各种文件、目录以及使用 WYSIWYG 编辑 html 文档。

有人对我应该添加到基本 Eclipse 3.5 安装中的插件有什么建议吗？

提前致谢！

我想根据 Google 帮助系统为我的一个应用程序创建一个 HTML 帮助。有谁知道 Google 帮助系统在 Google corp 之外是否可用？如果是，如何获得。什么是创作工具？它是一个开源工具吗？

如果没有，是否有一些具有相同风格的创作工具？

我想提供的帮助类型是您在 http://docs.google.com/support/上获得的帮助类型

特别是可以选择让用户就帮助主题给出他/她的反馈，即。

这则信息有帮助吗？是 否 容易理解？是 否 有足够的详细信息吗？是 否

请告诉我们为什么您认为这没有帮助。谢谢！

我们怎样才能使它变得更好？谢谢！您的反馈将帮助我们改进我们的帮助中心。

我在 HTML 帮助研讨会中创建了一个项目。当我打开帮助 (/chm) 应用程序时，我可以看到目录。默认情况下，选择文件中的第一个条目。

但是我看不到相应的页面数据，而是看到“此程序无法显示网页”（IE7 中的默认错误消息）。仅当我单击左侧的任何内容时才会显示该页面。

有没有办法在不点击条目的情况下默认显示页面？

有哪些优秀的创作工具可以为最终用户创建跨平台帮助文件？（我们的应用程序使用的是 Qt 框架，如果这有什么不同的话。）

注意：我对内部 API 文档不感兴趣——我们为此使用了doxygen。

理想情况下，解决方案将：

• 允许我们在一个位置管理所有帮助内容（文本、目录、图像等）。
• 输出为本机帮助格式。（Windows 的 CHM ——或者至少我们可以直接输入 HTML 帮助 API 的东西；不确定其他平台的“标准”帮助格式是什么。）
• 体面的所见即所得支持：轻松处理常见的文本输入、图像、交叉引用等，但我们可以在需要时编辑 HTML。
• 帮助项目（XML 等）的基于文本的文件格式，以便它可以在 Subversion 中进行版本控制。
• 任何有助于使其与实际代码库保持同步的钩子都会很棒。（也许帮助主题以某种方式与代码文件相关联，并且可以检查 Subversion 以查看是否进行了任何更改并将主题标记为“可能已过时”......我在做梦吗？）
• 帮助内容可以本地化。
• 不反对商业产品，但免费的选择会很好。

我会继续把它变成一个wiki，并从几个例子开始。如果您对他们有经验，请对他们投赞成票或反对票，并留下一些评论。还要添加其他工具。

当我打开帮助 (.chm) 应用程序时，我可以看到目录。默认情况下，文件中的第一个条目被选中，但是我看不到相应的页面数据。相反，我看到“此程序无法显示网页”（IE7 中的默认错误消息）。只有当我单击左侧的任何内容时，才会显示该页面。

有没有办法在不点击条目的情况下默认显示页面？

以下代码是 .hhp 文件。

我们需要编译为QtHelp（.qch 和 .qhc）。我想知道什么工具/工具链最容易做到这一点？我们想要一个 WYSIWYG 帮助创作工具作为我们的起点，然后通过我们必须得到的 QtHelp 运行该工具的输出。

我们过去曾使用过帮助和手册，这就是我们在帮助创作工具中寻找的那种所见即所得的界面。但是我们需要工具链来生成可以与qhelpgeneratoror一起使用的简单 html 页面（每个帮助主题一个），qcollectiongenerator以及创建 .qhp（至少是目录和关键字部分）和 .qhcp 以生成 .qch和.qhc。我没有看到帮助和手册如何适应这一点。

我们已经简要介绍了Sphynx，但它似乎对文本格式的选择极为有限。例如，看起来没有任何方法可以更改一段文本的字体、字体大小、字体颜色等。似乎不可能同时拥有粗体和斜体的文本。看起来很适合开发人员文档，但似乎缺少创作用户帮助文件的基本内容。如果我以某种方式错过了基本的文本格式功能，请纠正我！

那么，您推荐什么 WYSIWYG 帮助创作工具，以及从该工具到 .qch 和 .qhc 的路径是什么？

有谁知道是否有帮助创作工具可以为看起来像 wiki 的软件产品生成帮助文档？我们目前正在使用Confluence wiki 引擎，它非常棒，我们想知道是否有类似的东西，但不需要 Apache 服务器。可以为我们的用户提供他们需要的帮助文档的独立工具。我们使用了帮助创作工具，与 wiki 相比，它们看起来都非常笨重。

我正在使用 RoboHelp 9 创建一个 WebHelp 帮助系统。这将是上下文相关的在线帮助。编写系统的软件产品具有三个用户“上下文”，它们大多相似，但略有不同。我的目标是只显示与用户相关的帮助内容。

为了说明我的问题：在应用程序中，当用户 A 添加 Foo 时，他看到字段 1、2 和 3；但是，当用户 B 添加 Foo 时，他会看到字段 1、2 和4。当用户 A 单击“添加”屏幕上的“帮助”链接时，他应该会看到准确描述他所看到内容的帮助主题。当用户 B 单击“帮助”链接时，他应该会看到根据他所看到的内容量身定制的内容。

为了实现这一目标，我正在为软件的不同上下文在文本级别（主题内）添加条件指示符。

我的问题是，当输出帮助系统时，我是否需要使用条件构建标签生成三个完整的帮助系统，每个上下文一个？那么当开发人员插入上下文映射ID时，他们是否需要为a_pszHelpFile参数传递不同的位置才能访问正确的帮助系统？

以上是我能想到的唯一方法，以确保 TOC 和主题文本对于可能单击任何给定页面上的帮助链接的每种类型的用户都是正确的，但是为每个条件构建生成一个完整的帮助系统似乎很笨重标签。