我正在研究要求＆amp;适用于“在现场”工作的某些专业人士使用的新iOS应用程序的规范。这些人整天都会持续数周，使用标准化表格跟踪所有不同类型的信息，给上级带来了相当大的报告负担。传统上，这些表格是PDF格式，只需打印并用墨水填写，然后与数十到数百个其他人一起分享同样的操作。有时他们会使用带有表单字段的PDF，因此可以输入数据，然后将其打印为表单的一部分。无论哪种方式，考虑到他们的工作流程，时间和压力以及其他因素，完成标准化报告表格并不是一种非常有效的方式。
我们所指定的应用程序将提供iOS（和Android，如果可能 - 但此时是次要或甚至是第三级要求）用户界面，用于跟踪他们在字段中输入的数据，以逻辑方式组织它每个用户的方式，只需按一下按钮，即可获取所有数据并使用标准化表格自动创建PDF文件。
当然，这种形式在这个行业中是严格且严格标准化的，格式，结构或表现方式的任何偏差都是不容忍的。
因此，我认为应用程序将维护来自认证组织的原始标准化表单的内部存储库，并将每个可能的数据区域定义为字段，从而接近该项目。该应用程序将：
＃4的标志是PDF文件必须保持可由Windows和Mac上的标准PDF应用程序（Acrobat，预览等）编辑，因此所有字段都需要保留。在Windows或Mac上，PDF应该可以看到相同的内容。
现在，在任何时候，PDF（既不是原始文档也不是导出的最终文档）都需要在iOS应用程序中显示，也不需要能够这样做。
我不知道这是否可行。这是我们的第一个iOS项目，我们一直倾向于使用Moai或Corona或其他框架构建应用程序，以节省开发时间并使跨平台的移植更加容易。也就是说，如果使用Lua和其中一个框架无法完成（我仍然持怀疑态度......他们似乎非常注重游戏），我们并不反对在Objective C中直接进行游戏并在某个时候构建Android版本这条路。
但无论如何，我在评估这是否是一项实际工作时都感到茫然。我们的要求是明确的，坦率地说，如果不能做到这一点，项目将不再进行。但我绝对可以使用你们的帮助来确定我的选择是什么，我是否能在Lua中做到这一点，以及什么SDK在实现这一目标方面最有用。
答案 0 :(得分：1)
根据您的说法，似乎没有理由在移动设备上执行基于PDF的部分工作，因为：
您是否可以通过专注于数据收集和验证来简化您的需求中的移动部分，然后启动服务器来执行文档制作？这将为您提供更多灵活性，您可以使用这些工具将数据合并到PDF文档中。如果是这样，您可以使用类似iText（C＃或Java）的内容来创建PDF或填充代码中的字段。如果您不想构建自己的后端服务器，可以尝试Docmosis Cloud之类的操作 - 但这可能无法让您获得精确的布局。
当然，你提到的问题 - 需要保持PDF文件在其字段中可编辑是一个重要问题。如果您可以说服利益相关者最好从您的系统生成最终文档（生成草稿，审核，更新数据，再次生成等） - 而不是生成可编辑的文档，然后您失去控制和可追踪性，那么您将成为提前几英里。
希望有所帮助。
答案 1 :(得分：1)
您是否考虑使用表单图像作为pdf的背景生成新的pdf，并将用户的数据写入表单图像上的所需区域。会降低尝试解析原始表单PDF的复杂性。
答案 2 :(得分：0)
这是值得讨论的一点，但我们没有一个理想的答案。我倾向于认为这是几乎完美的情况 - 开发起来要容易得多。这种方法有两个关键问题让我们把它作为最后的手段：
此产品的用户将在该领域工作。这个领域几乎可以在任何地方 - 曼哈顿的街道，一个受到严重破坏甚至毁坏的基础设施的受灾地区，或者是受战争最严重的第三世界国家。如果它是曼哈顿的街道，那就没问题了 - 他们的iOS或Android设备几乎可以随时随地访问3G或Wi-Fi。在后两种情况下（在该行业中可能更常见），连接可能非常有限。值得关注的是，如果终端用户没有良好的信号，他们是否能够提高工作效率，或者与同事共享数据和分享数据的能力是否会受到太大限制。尽管如此，即使在今天，他们通常甚至不使用移动设备，迫使他们返回总部类型的位置或使用无线电来共享信息，这有效地否定了我的观点。但是，如果我们不打算显着提高他们在该领域的生产力，它只会让我们停下来思考我们是否有足够的价值主张来要求他们相当显着地改变他们的做事方法。
对于你的后一点，没有人不相信利益相关者这个新系统是更好的方法。即使有，也需要数年时间。这些表格是成千上万组织使用的定义明确，数十年前标准的一部分。