应用程序（非标记语言）用于制作用户手册 [英] Application (Not a Markup Language) for Producing a User Manual
问题描述
任何人都可以推荐一个程序来创建用户手册？不是标记语言（如LaTeX或DocBook），但更多的是像Scribus这样的交互式的东西。由于我不是唯一一个会更新手册的软件，因为新手可以轻松上手，但仍然具有一些高级功能（例如从外部源/表的文本链接，处理主页/主题等）
问候，
奥斯卡
技术出版软件 - 关于 FrameMaker 及其替代方案的观点
我已经与LaTeX和Framemaker完成了规范文件，并设计了一个Framemaker工作流程，以支持一个由5名分析师组成的团队，为保险承保系统制定规范文件。该文件预计将达到2,000页左右。许多年前（约1992 - 1993年），我也作为一个排版工作工作。
Framemaker专为技术文档而设计，确实非常好。 strong>它还具有旨在支持多个作者的非常大的文档的功能 - 人们使用该系统来执行超过100,000页的文档。对于熟悉文字处理软件的用户来说，它也比LaTeX更易于访问。
Framemaker的主要功能：
-
由多个
文件组成的文档：您可以将
'Book'与多个子部分
不同的文件。
也可以保存在源代码控制中。 -
导入/导出的文本MIF格式：进口商是
有点精彩（我发现生产
工作LaTeX更容易），但你可以
生成数据，如数据
字典，并将它们导入
文件。该文件具有文本
的锚点（见下文），因此您可以
创建交叉引用链接，
将跨导入稳定。 I
发现这是
规范的关键功能，因为它允许交叉引用
直接链接到生成的项目。 -
强大的标记，索引和交叉引用系统：一切
基于Framemaker和
中的标签，很容易应用标签。
这意味着交叉引用，
索引，条件文本和
应用样式大都很容易，
只是工作。您可以基于标签生成索引和TOC，因此
具有多个专用索引
（例如，屏幕或数据字典中的数据字段名称
的列表）
很容易做。上述文件I
有4个独立的
索引。 -
稳定： Framemaker专为
的专业人士，所以它不是第二个
猜测你的方式这个词。
在大的
文件上也更稳定。任何试图
的人在Word上写一个超过50-100
页面的文档应该有一个漂亮的
公平的想法，这意味着什么。 -
可编写脚本： FM有一个C API，
是各种脚本插件
（ FrameScript 和
可能是最广泛使用的）
，可用于在FM中自动完成工作
。 Framemaker 10 为基于Javascript的脚本工具添加了
称为 Extendscript ，大概是
脚本设施
in InDesign。 -
单一来源：从单个FM
文档中可以生成PDF，
Windows帮助（CHM），HTML和打印
文件相当容易。
交叉引用也解决了
超链接。 -
全局样式控件：您可以
轻松设置文档
的样式，并将其应用于整个
文档。它还方便
运行的页眉和页脚，
具有
的灵活性，它们跟踪部分，版本，
章等。
Framemaker的替代方案
- p> LaTeX / Lout：您已经指出
您不想要一个标记
lanaguage，但 TeX 和
Lout 系统用于大型
结构化文档，并执行
。 -
Ventura发行商： 可能
只是真正的替代如果您想要这种用户界面
，而不为
特权支付身体部位，则Framemaker
。
它对结构化的
文档和基于XML的文档
交换格式有很强的支持。 Corel现在拥有
，他似乎也在积极地推广它。
市面上还有其他几种技术出版工具： Quicksilver （以前称为 Interleaf ）和 ArborText 。这两个是强大的工具 - Interleaf过去曾经是这一领域的市场领导者，但却相当昂贵。
-
Adobe Indesign ： 虽然Adobe
声称您可以使用InDesign执行大型文档
，但是交叉引用
和其他大型文档功能
往往被视为缺少
Framemaker afficionados。然而，有
，一个文本输入系统
称为 InCopy 显然
确实有这样的
功能和相当的
a大体的第三方
插件，其中一些
支持标记和其他此类设施。
InDesign还具有脚本API，
是用于执行
脚本的JavaScript解释器。
我没有使用Indesign，
/ li>
，所以我无法真正评论如何
它在实践中的作用。
-
DocBook： 此对于结构化的
文件，实际上只是
a标准格式，但是有一个大的生态系统
的工具，用于编写
和呈现文档。如果你
不想使用LaTeX你将
可能不想使用DocBook
类似的原因。作为 Vinko Vrsalovic
指出（+1），这个链接从实际使用
DocBook的人那里得到一个StackOverflow
的帖子。
我从来没有真正使用过DocBook，而且
对这篇文章做了如此多的修改，现在处于维基模式，所以
熟悉DocBook的人可能会b $ b想要详细说明 -
文字处理软件 Word
/ li>
有严重的缺点作为
技术出版工具，不推荐
。 OpenOffice 的
比
文字更好的结构化
文档功能，可能作为一个更好的选择，如果
政治或要求使用.doc
作为文档交换格式
排除一个更好的选择。
Wordperfect
相当于
文档，大于word
，而且还在几个垂直市场（如合法办事处）中存在
。
-
Madcap Software的 Blaze 和 Flare ：这些
是新的孩子，在
与
Framemaker大致相同的空间。该公司由前
eHelp（RoboHelp的创始人）员工成立，每年
积极开发，多次发布。他们的
产品在过去两年中大幅度扩大，损失了个人产品的质量。
似乎重点是出售新产品和
，结果是每个
中有很多适合和完成的问题。作者选择以许多方式重塑轮廓，
导致混淆和经常破碎的实现。经常保存
，您将遇到未处理的异常。源代码控制集成
是片状的。例如，移动或删除一组文件将导致
每个文件删除的一个源代码控制提交。 Big PITA当
你有源代码控制电子邮件通知。你好500电子邮件
Flare可以导入Word和Framemaker文件，但导入
远远无法连接。期望保留您所有的内容
，但计划从头开始完全重新设计样式。
Flare分享许多Word的倾向，在
的背景下做太多的事情，并假设用户会选择什么。当HTML导出HTML时，HTML看起来像
一样，输出HTML - 许多自定义标签
和属性，深度嵌套的内联样式等。文本
编辑器很疯狂，例如其游标模型是不同于任何其他您曾经使用的软件
。
Framemaker vs. LaTeX
这两个是我用来生成大型可呈现的系统文档的主要系统，我已经取得了很好的成绩。
-
易学习：TeX可以给你绝对的控制，但实际上
在复杂的LaTeX
文件中实现这一点，而不会破坏其他
项目并不是微不足道的，特别是
，其中涉及大量的宏
包。基本的LaTeX
不难学习，但是
修改版本的.sty文件
仍然工作需要一点修补
如果你不是一个真正深刻的TeX
黑客。可以完成，但是
准备花费相当多的
时间fiddling。
Framemaker可以给你一个很好的控制权该文件的外观并不是很难学习。
-
容易输入文字：
/ strong>您可以使用 Lyx 等工具来提供一个 -
模板文档结构：Framemaker允许一个文档
结构以
标签或XML模式（如果使用
Structured Framemaker）定义。 LaTeX有一个
的罐头结构元素
，它们足够灵活，可以用于
。添加额外的
结构元素（例如数据
字典项目）可以作为
宏完成，但是使其自动编号
有点更具挑战性，您将
需要在
场景后面戳。两者都可以这样做，但是在LaTeX中以
的方式，在
中更为技术性更高。
此外，LaTeX没有
的设施，以
结构化框架器的方式模板
文档结构。
但是，如果需要，您可以使用DocBook实现此类型
的效果，然后
生成LaTeX。 -
<强>易于整合：我发现，制作一个非常简单的
复杂的MIF文件的生成器是相当的
fiddly。 MIF解析器在FM中是相当的
pernickety，并不真的
给出良好的诊断。 LaTeX
产生更好的错误消息
，并且相当少一点。
字处理程序的前端
LaTeX，如果
想要写大文本文本，这些工作很好。
Framemaker的类似DTP的用户界面
以人们熟悉的方式熟悉
，他们习惯用于单词处理
软件。从这个角度来说，
有一些实用的
差异。
<强>技术出版软件与布局软件
页面布局软件以 Pagemaker ，在这个领域的其他主要玩家是其竞争对手夸克Xpess 和现在的InDesign，Adobe基本上试图废弃和替换它和Framemaker。您之前提到的 Scribus 与这些产品保持在同一空间。
如果您生产的手册少于（说）50-100页，其中一个包可能会做得足够的工作。它们的设计真正用于广告和布局繁重的杂志，如杂志，因此他们对Framemaker中发现的大型文档功能的支持是非常有限的。这些产品的关键问题是可扩展性 - 它们对大型文档的工作不正常。
仅供参考，我实际上使用Pagemaker排版了一本200页的书（某人的自传）。虽然细粒度的字距调整和领先的控件有助于进行文字拼写，但它仍然是一个高度手动的过程来布局书本大小的文档。在这种情况下，这本书只是直文本，没有明显的交叉引用或结构，而不是章节。使用Pagemaker做一个复杂的技术规格文件或手册这个大小将是非常非常巧妙的，可能不可能得到正确的没有任何错误。
技术出版vs文字处理软件
这是MS-Word关于大规模文档的关键缺点的更多描述。但是，它将说明一些文档所需的主要功能：
-
索引和交叉引用：这是Word中的一个真正的烦恼，
非常不稳定。 Framemaker的
标记功能和LaTeX的标签
意味着您可以分配一个标签或
已知标签（如果需要，可以是可预测的格式
）。标签锚点的文本格式
在
的用户界面中公开，并用于
的链接。在Word中，锚
更加不透明，而不是
以这种方式很容易控制。
结合笨拙的用户
接口和
产品的不稳定性，这使得维护
这些fiddly，并且通常不稳定 -
你经常手动修复他们
up。 -
模板布局：单词中的样式支持相当基本，
编号往往有点
不稳定。 FrameMaker全部是
从标签开始，并根据标签应用
样式。全局
样式更改只能在
中使用Framemaker，它们在Word中不为
。 -
大型多文件文件：我从来没有能够在Word中完成这项工作
，但它是Framemaker和LaTeX中的一个关键的
功能。
再次，Word的不稳定性意味着
您倾向于花费大量的时间
来完成整理。当
文档变大时，
在这个
工作上所花费的时间比例会以二次方式增长 -
破坏倾向比例为
to n （文件的大小）*时间到
固定与大小成正比（时间
修复） -
为什么Word如此不稳定： Word在幕后花费
支持新手用户并在布局中介入
。它也不是真的
基于框架（文本流概念上
与文档布局分开），但
开发人员尝试在UI中实现
各种类似行为的行为。当
A.I.第二个猜测你在一个
复杂的文件，它经常做
错误的事情。 Framemaker'将
用户视为成人，并且没有
这样，所以这些东西留在你把
的位置。
其他字处理程序如
打开Office和WordPerfect不要
的行为与
的方式相同，这是一个Word的理由
只是任何 单词
除了Word之外的处理器将会更好地获得
的技术文档。 -
预飞行：在文档中说，这是
检查您的
组合文件的过程对于文件
（图像文件等）在
提交打印之前是正确的。
专业系统将抱怨
有关错误的事情，给
你有机会纠正。 Word
只会放在一张幸福的脸上，
尝试解决幕后的事情。
一个很好的例子是一个带有链接图形的单词
文件。如果
将文件和图形复制到
另一个目录，并更新其中一个
图形原位，字可能很好
仍然从旧的
路径读取文件（我已经看到它这样做），而不是
刚刚更新的新的。
但是，这种行为不一致，
代表了该产品中
不稳定启发式的猖獗滥用。 -
strong>前期支持：发布系统扩展到工作流程的前期
阶段。这意味着
它包括准备打印。
文字处理软件往往不是
具有这个功能或
它的非常有限的形式。
没有太多的这个，一个关键的区别是，发布软件往往会像一个同意的成年人一样对待你，而不是妨碍你扩大或自动化事情的方式。一个可以使用文字处理软件进行大规模的文档编制，但是它有许多设计决策适合休闲用户编写简短的文档，而不考虑质量。这些调整在大规模文件准备工作中牺牲了适合任务的代价。我用Word for spec文件找到的主要问题是索引和交叉引用以及总体不稳定性问题，我总是不得不回头去解决问题。然而，在大多数环境中，政治上的考虑（我是一个承包商）意味着一个人经常被困在一起。
对技术文档软件状态的一般性评论
如果Adobe没有继续发出他们试图弃用的信号并将其用户群移动到InDesign，Framemaker将是明显的选择。然而，FM广泛应用于航空航天，软件和工程界，Adobe的管理层将面临 lynch mob 如果他们实际上没有没有可信的迁移路径的产品。 Adobe从网络上看到，Adobe收购的FM是由约翰·沃诺克（John Warnock）推动的，但他被推翻，FM成为办公室政治的受害者。最终的结果是被移动到维护模式，并且停滞不前。
文图拉出版商在某种程度上也被归入了一个利基市场，但至少Corel Adobe没有两个竞争产品线。它可能是FM的通行替代品，并且可能在PHB类型中更具政治上的接受性，因为它被作为商业出版系统销售。
Quicksilver和Arbortext都似乎是可行的产品，但是非常昂贵。我还没有使用过，所以我不能对他们的优点做出任何真实的判断。
标记语言系统在许多方面是免费的，非常强大的。 Lout可能会更容易使用，因为它不具有LaTeX所做的传统行李的级别。 DocBook也被广泛使用，确实有相当多的工具支持。这些技术大大挤压了Framemaker市场份额的极客，并根据其优点来实现这一点 - 他们多年来一直在Adobe的利润空间中占据一席之地。我不会不了解这些技术，但在实践中他们会更难学习。
您可以尝试评估InDesign和一组选定的插件（集中在那些用于标记和交叉引用/索引管理）。最后，一些文字处理软件（Wordperfect和OpenOffice）为您提供了一个合理的结构化文档工具包，并且比MS-Word更好地工作。
PostScript
是的，这是一个双关语。我没有涉及任何这些产品的Pre-Press功能。印刷和印前版是自己的技术领域，昂贵的错误的范围意味着你应该把它留给专家。
Framemaker，InDesign，Ventura，QuickSilver，Arbortext和（可能）MadCap产品都配有进行印前准备的设施。一般来说，文字处理软件不会。
使用LaTeX进行预先压缩往往涉及使用像 psutils 或呈现给PDF，并从那里采取印前工作流程。一般来说，大多数印前房屋可以从PDF工作，所以一个很好的PDF写作工具，如Distiller是从不是为印前工作设计的工具准备的最好的工作接口。请注意， Distiller 的输出质量往往优于 Ghostscript ，如 PDFCreator 。
请注意，监视器的RGB颜色空间没有直接映射到CYMK颜色空间使用的颜色空间一台印刷机实际上，如果你没有合适的套件，颜色 - 特别是彩色照片 - 正确地出现在新闻界。对于印刷生产，请查看专家，除非您有理由相信您知道您在做什么。对于一个临时用户，我仍然会在我参与该行业15年后推荐，因为一旦他们承诺打印，错误就会非常昂贵。 p>
如果你真的想在内部进行彩色打印工作，你可能需要校准您的显示器。为了获得最佳效果，您应该获得一个高保真监视器，如这个。为了校准显示器，您还可能需要像以下此评论如果显示器没有一个。大多数专业显卡，如 Nvidia ， AMD 或 Matrox 具有支持伽马校正的功能;许多消费者也同样如此。您还需要获得要用于打印的印刷机的校准数据，尽管新闻前的房屋可能会这样做。
As以前说过，打印媒体本身就是技术性很强的，一旦打印出来就很容易出错，修复费用很高。如果您不是100％确定您的校准正确，请获得如 Chromalin 。这是从实际的胶片分离（因此是相当昂贵的），所以它给出了最终印刷品的实际颜色的准确描述。对于几个样本页面进行此操作，将为您提供有关校准设置是否正确的准确反馈。
致谢：感谢 Aidan Ryan ，以扩展Madcap产品部分。
Can anyone recommend a program to create user manuals with? Not a markup language (like LaTeX or DocBook) but more something interactive like Scribus. As I'm not the only one that will update the manual the software should be something that's easy for a novice to pick up but still has some advanced features (like linking in text from external sources/tables, handling masterpages/themes etc.).
Regards, Oscar
Technical Publishing Software - Views on FrameMaker and Its Alternatives
I've done spec documents with LaTeX and Framemaker, and designed a Framemaker workflow to support a team of 5 analysts producing a spec document for an insurance underwriting system. The document was expected to get to 2,000 pages or so. Many years ago (around 1992-1993) I also worked briefly as a typesetter.
Framemaker is designed for technical documentation and does it very well indeed. It also has features designed to support very large documents with multiple authors - people use this system to do documents with more than 100,000 pages. It is also more accessible than LaTeX to users familiar with word processing software.
Key features of Framemaker:
Documents consisting of multiple files: You can pull together a 'Book' with multiple subsections in different files. The document can also be kept in source control.
Textual MIF format for import/export: The importer is somewhat finicky (I found generating working LaTeX to be easier) but you can generate items such as data dictionaries and import them into the document. The file has textual anchors (see below) so you can create cross-reference links that will be stable across imports. I find this to be a key feature for specs as it allows cross-references to link directly to generated items.
Powerful tagging, indexing and cross-referencing System: Everything is based on tags in Framemaker and it is easy to apply tags quickly. This means that cross-referencing, indexing, conditional text and applying styles en-masse is easy and just works. You can generate indexes and TOCs based on tags, so having multiple specialised indexes (such as a list of data field names from screens or a data dictionary) is easy to do. The document I described above had 4 separate indexes.
Stable: Framemaker is designed for professionals so it doesn't second guess you in the way that word does. It is also much more stable on large documents. Anyone who's tried to write a document of more than 50-100 pages on Word should have a pretty fair idea of what this implies.
Scriptable: FM has a C API and there are various scripting plugins (FrameScript and FMPython being probably the most widely used) which can be used to automate jobs in FM. Framemaker 10 adds support for a Javascript based scripting tool called Extendscript, presumably ported across from the scripting facility in InDesign.
Single-sourcing: From a single FM document you can produce PDF, Windows Help (CHM), HTML and print documents fairly easily. The cross-references also resolve to hyperlinks.
Global style controls: You can easily set up styles for a document and apply it across the whole document. It also facilitates running headers and footers with a great deal of flexibility in having them track sections, versions, chapters etc.
Alternatives to Framemaker
LaTeX/Lout: You've already indicated that you don't want a markup lanaguage, but the TeX and Lout systems are used for large structured documents and do this well.
Ventura Publisher: Probably the only real alternative to Framemaker if you want that sort of user interface without paying bodily parts for the privilege. It has strong support for structured documents and an XML-based document interchange format. It's now owned by Corel, who still appear to be actively promoting it.
There are a couple of other technical publishing tools on the market: Quicksilver (which used to be known as Interleaf) and ArborText. These two are powerful tools - Interleaf used to be the market leader in this field at one point - but quite expensive.
Adobe Indesign: Although Adobe claim you can do large documents with InDesign, the cross-referencing and other large document features tend to be viewed as lacking by Framemaker afficionados. There is, however, a text entry system for it called InCopy that apparently does have this sort of functionality and quite a large body of Third-party plugins, some of which do support tagging and other such facilities. InDesign also has a scripting API and a JavaScript interpreter for executing scripts.
I haven't used Indesign, so I can't really comment on how well it works in practice.
DocBook: This is really just a standard format for structured documents but has a large ecosystem of tools surrounding it for writing and rendering documents. If you don't want to use LaTeX you will probably not want to use DocBook for similar reasons. As Vinko Vrsalovic points out (+1), This link goes to a StackOverflow post from someone describing using DocBook in practice. I've never really used DocBook and I've made so many edits to this post that it's now in Wiki mode, so someone familiar with DocBook might want to elaborate on this.
Word processing software: Word has serious shortcomings as a technical publishing tool and is not recommended. OpenOffice has somewhat better structured documentation functionality than word and may be a better choice if politics or requirement to use .doc as a document interchange format preclude a better alternative. Wordperfect is also considerably better for documentation-in-the-large than word and still has a presence in several vertical markets such as legal offices.
Madcap Software's Blaze and Flare: These are new kids on the block and live in roughly the same space as Framemaker. The company was founded by former eHelp (creators of RoboHelp) employees and is actively developing, with multiple releases yearly. Their offerings have greatly expanded in the past two years, to the detriment of the quality of the individual products. It seems focus has been on turning out new products and by consequence there are a lot of "fit and finish" issues in each. The authors have chosen to reinvent the wheel in many ways, resulting in confusing and often broken implementations. Save often, you will encounter unhandled exceptions. Source control integration is flaky. For example, moving or deleting a group of files will result in one source control commit for each file deletion. Big PITA when you have source control email notifications. Hello 500 emails. Flare can import Word and Framemaker files, but the import is far from seamless. Expect to retain all of your content but plan on completely re-styling from scratch. Flare shares many of Word's tendancies to do too much behind the scenes and assume what the user would choose. The HTML looks like what Word outputs when you export HTML - lots of custom tags and attributes, deeply nested inline styles, etc. The text editor is maddening, for example, its cursor model is different than any other software you've ever used.
Framemaker vs. LaTeX
These two are main systems I have used to produce large, presentable system documents and I've had good results with both.
Ease of Learning: TeX can give you absolute control but actually achieving this on a complex LaTeX document without breaking other items isn't trivial, particularly where a large number of macro packages are involved. Basic LaTeX isn't hard to learn, but making modified versions of .sty files that still work takes a bit of tinkering if you're not a really deep TeX hacker. It can be done but be prepared to spend quite a lot of time fiddling.
Framemaker can give you a good degree of control on the look of the document and isn't that hard to learn. Getting a house style and tweaking the layout (which you probably will have to do) will be easier with Framemaker.
Ease of Text Entry: You can use tools such as Lyx to provide a wordprocessor-like front end to LaTeX, and these work well if you want to write large bodies of text. Framemaker's DTP-like user interface works in a way familiar to people who are used to wordproessing software. From this perspective there is little practical difference.
Templating Document Structure: Framemaker allows a document structure to be defined in terms of tags or an XML schema (if using Structured Framemaker). LaTeX has a set of canned structural elements that are flexible enough to be useful. Adding additional structural elements (e.g. a data dictionary item) can be done as a macro, but making them auto-number is a bit more challenging and you will need to poke around behind the scenes. Both can do it, but it's considerably more technical to do it in LaTeX in anything but trivial cases.
Also, LaTeX does not have the facility to template the document structure in the way that Structured Framemaker does. However, you can achieve this type of effect with DocBook and then generate to LaTeX if desired.
Ease of Integration: I found making a generator for non-trivially complex MIF files to be quite fiddly. The MIF parser is quite pernickety in FM and doesn't really give good diagnostics. LaTeX produces far better error messages and is quite a bit less fussy.
Technical Publishing Software vs. Layout Software
Page layout software started with Pagemaker and the other main players in this space were its competitor Quark Xpess and now InDesign, with which Adobe is essentially trying to deprecate and replace it and Framemaker. Scribus, which you mentioned before, lives in the same space as these products.
If you are producing a manual with less than (say) 50-100 pages, one of the packages would probably do an adequate job. They are really designed for advertising and layout-heavy publication tasks such as magazines, so their support for large-document features of the sort found in Framemaker is fairly limited. The key issue with these products is scalability - they do not work well on large documents.
Just for reference I have actually typeset a 200-page book (someone's autobiography) using Pagemaker. While the fine-grained kerning and leading control helps a bit for copyfitting, it is still a highly manual process to lay out a book sized document. In this case the book was just straight text with no significant cross-referencing or structure other than chapters. Doing a complex technical spec document or manual this size with Pagemaker would have been very fiddly and probably next to impossible to get right without any mistakes.
Technical Publishing vs. Word Processing Software
This is more of a description of key shortcomings of MS-Word for large spec documents. However, it will illustrate some of the main features required for documentation-in-the-large:
Indexing and Cross-Referencing: This is a real chore in Word, and quite unstable. Framemaker's tagging features and LaTeX's labels mean that you can assign a tag or known label (in a predictable format if necessary). The textual format for the tag anchors is exposed in the user interface, and is used for the linkage. In Word, the anchors are much more opaque and not easily controllable in this way. Combined with the clumsy user interface and instability of the product, this makes maintaining these fiddly, and often unstable - you often have to manually fix them up.
Templated Layouts: Style support in word are quite basic and numbering tends to be somewhat unstable. FrameMaker is all about driving from the tags and applying styles based on the tags. Global style changes just work in Framemaker in a way that they do not in Word.
Large multi-file Documents: I've never been able to make this work well in Word, but it is a key feature in Framemaker and LaTeX. Again, Word's instability means that you tend to spend a lot of time tidying up after it. As the document grows larger, the proportion of time spent on this work grows quadratically - propensity for breakage proportional to n (size of document) * time to fix proportional to size n (time to fix)
Why is Word so Unstable: Word does a lot behind the scenes to support novice users and intervene in layouts. It is also not really frame-based (text flow conceptually separate from document layout), but the developers try to implement various frame-like behaviours in the UI. When the A.I. second-guesses you on a complex document it often does the wrong thing. Framemaker 'treats the user as an adult' and does none of this so things stay where you put them.
Other word processors such as Open Office and WordPerfect do not misbehave in quite the same way as Word, which is one of the reasons that just about any word processor other than Word will do a better job of technical documents.
Pre-Flighting: In documentation-speak, this is the process of checking that your assemblage of files for the document (image files etc.) is correct before committing to print. The professional systems will complain about things that are wrong, giving you a chance to correct it. Word will just put on a happy face and try to fix things behind the scenes.
A good example of this is a word file with linked graphics. If you copy the file and graphics to another directory and update one of the graphics in situ, word may well still read the file from the old path (I've seen it do this) and not the new one you've just updated. However, this behaviour is not consistent and typifies the rampant abuse of unstable heuristics in that product.
Pre-Press Support: A publishing system extends into the pre-press phase of the workflow. This means it covers preparation for print. Word processing software tends not to have this functionality or have it in a very limited form.
Without getting too far into this, a key difference is that publishing software tends to treat you like a consenting adult and not get in the way when you want to scale or automate things. One can use word processing software for large scale documentation but it has many design decisions adapted to casual users writing short documents with little regard for quality. These adaptations come at the expense of fitness-for-task on large scale document preparation work. The main issues I find with Word for spec documents are the poor indexing and cross-referencing and general instability issues where I am always having to go back and fix things. However, political considerations in most environments (I'm a contractor) mean one is often stuck with it.
Some general comments on the state of technical documentation software
Framemaker would be the obvious choice if Adobe didn't keep giving off signals that they are trying to deprecate it and move its user base to InDesign. However, FM is widely used in aerospace, software and engineering circles and Adobe's management would face a lynch mob if they actually EOL'd the product without a credible migration path. From what one reads on the web, Adobe's acquisition of FM was driven by John Warnock, but he was ousted and FM became a victim of office politics. The net result is that it's been moved to maintenance mode and is quite stagnant.
Ventura Publisher has also been relegated to a niche market to some extent, but at least Corel do not have two competing product lines in the way that Adobe do. It is probably a passable substitute for FM and may be more politically acceptable to PHB types as it is marketed as a 'business publishing' system.
Quicksilver and Arbortext both seem to be viable products, but are very expensive. I've not used either, so I can't really make any real judgement on their merits.
The markup language systems are free and very powerful in many ways. Lout might be a bit easier to work with as it doesn't have quite the level of legacy baggage that LaTeX does. DocBook is also quite widely used and does have quite a bit of tool support. These technologies put a significant squeeze on the 'geek' end of Framemaker's market share and do so on their merits - they have probably taken quite a chunk out of Adobe's profit margins over the years. I would not dismiss these technologies out of hand, but they will be harder to learn in practice.
You might try evaluating InDesign and a selected set of plugins (concentrate on those for tagging and cross-ref/index management). Finally, some of the word processing software (Wordperfect and OpenOffice) give you a reasonable toolkit for structured documentation and work considerably better for this than MS-Word.
PostScript
Yes, that is a pun. I haven't touched on Pre-Press functionality of any of these products. Printing and Pre-Press are technical fields in their own right and the scope for expensive mistakes means you should probably leave this up to specialists. Framemaker, InDesign, Ventura, QuickSilver, Arbortext and (presumably) the MadCap products all come with facilities to do pre-press preparation. By and large, word processing software does not.
Doing pre-press with LaTeX tends to involve post-processing the PS output with software like psutils or rendering to PDF and taking the pre-press workflow from there. Generally, most pre-press houses can work from PDF, so a good PDF writing tool like Distiller is the best interface for work prepared from tools that are not designed for prepress work. Note that the quality of the output from Distiller tends to be better than the Ghostscript based ones like PDFCreator.
Note that the RGB colour space of a monitor does not have a direct map to a CYMK colour space used by a printing press. Actually getting colours - especially colour photos - to come out correctly on a press is somewhat fraught if you do not have the right kit. For print production, see a specialist unless you have reason to believe you know what you're doing. For a casual user I would still recommend this 15 years after I was involved in the industry, as mistakes are very expensive to fix once they're committed to print.
If you really do want to do colour print work in-house, you will probably need to calibrate your monitor. For best results, you should get a high-fidelity monitor like this one from HP. In order to calibrate the monitor you may also need a sensor like one of the ones described in this review if the monitor does not come with one. Most professional graphics cards like these from Nvidia, AMD or Matrox have facilities to support gamma correction; many consumer ones do as well. You will also need to get calibration data for the press you are going to be using to print, although the pre-press house will probably be able to do this.
As stated before, print media is quite technical in its own right, easy to get wrong and expensive to fix once it's gone to print. If you're not 100% certain you've got your calibration right, get a colour proof like a Chromalin. This is done from the actual film separations (and is thus quite expensive), so it gives an accurate rendition of the actual colour of the final printed article. Doing this for a few sample pages will give you accurate feedback about whether your calibration is set up right.
Acknowledgements: Thanks to Aidan Ryan for expanding the section on Madcap products.
这篇关于应用程序（非标记语言）用于制作用户手册的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
