LaTeX 文档、PDF 输出、SVN 源 - 需要可定制的组件或软件进行同行评审

发布于 2024-08-23 19:34:40 字数 949 浏览 5 评论 0原文

我们有一个大型 LaTeX 文档的 SVN 存储库。每个文档最终都会呈现为 PDF。

需要审查文件。审核有两个主要目标:保证文字本身的质量和保证排版的合格。

现在审阅者可以分为两大类:

  1. 那些使用 SVN 结账的人 来源并构建 PDF 自己,并提交结果 SVN 提交时进行审核

  2. 从 ftp 服务器获取预构建的 PDF 并将结果作为 通过电子邮件提供自由格式的评论列表。

文档作者通过处理 LaTeX 代码中的 \todo{} 块、回滚 SVN 中不需要的更改或将电子邮件中的自由格式注释合并到 LaTeX 源中来处理审阅结果。

问题是,随着文档数量的增加,很难跟踪第二组的审稿人,并及时、彻底地采纳他们的建议。

因此,需要一些简单的提交后审查解决方案。

要求:

  1. 提交后审核

  2. 默认情况下,所有存储库都应被视为审核目标,无需指定要审核的文件/行范围。

  3. 支持匿名评论/评论结果

  4. 评论/评论应该有状态以便于处理

  5. Web -基于

  6. 与SVN集成,以便新的提交可以自动纳入审查

  7. 打开开源/可定制

ReviewBoard、CodeStiker、trac、Rietveld、JCR 插件 - 它们都无法满足其中一些要求。此外,其中大多数都过于复杂,无法满足当前的需要。

坩埚不错啊它很复杂,但可以通过定制变得简单。不过价格有点重。

我错过了什么?

UPD:我们最终没有任何自动化。高级用户可以直接访问存储库,并以分支/补丁或源内评论的形式进行审查。其他人要么以纯文本形式存储评论,要么对生成的 PDF 进行注释。

一段时间后,我们不再寻找替代方案。

We have a large SVN repo of LaTeX documents. Each document ultimately is rendered into PDF.

Documents need to be reviewed. Review has two major goals: ensure the quality of text itself and ensure the qualify of typesetting.

Right now reviewer could be separated into two major groups:

  1. Those who use SVN to checkout
    sources and build PDFs for
    themselves, and submit results of
    review as SVN commits

  2. Those who get pre-built PDFs from ftp server and submit results as a
    free-form list of comments via email.

Document authors process the review results by processing \todo{} blocks in LaTeX code, by rolling back unneeded changes in SVN or incorporating free-form comments from e-mail into LaTeX sources.

Problem is, as the number of documents grow, it is very hard to keep track of the reviewers from the second group, and incorporate their suggestions in the timely and thorough manner.

Therefore, some nonsophisticated post-commit review solution is needed.

Requirements:

  1. Post-commit review

  2. All repository should be by default considered a review target without a need to specify files/line ranges for review.

  3. Support for anonymous comments/review results

  4. Reviews/comments should have status to facilitate processing

  5. Web-based

  6. Integration with SVN, so that new commits could automatically be incorporated in the review

  7. Open source/cusomizable

ReviewBoard, CodeStiker, plugins for trac, Rietveld, JCR - they all fail to satisfy some of those requirements. Besides, most of them are too complex for the need at hand.

Crucible is nice. It is complex, but could be made easy via customization. However price tag is a bit heavy.

What did I miss?

UPD: we ended up without any automation after all. Power-users either have direct access to the repository and make reviews as branches/patches or as comments inside sources. Other people either store comments in plain-text, or annotate resulting PDFs.

After a while, we stopped looking for alternatives.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

流年里的时光 2024-08-30 19:34:40

如果您已经查看了所有这些开源项目,并且它们都不满足您的要求,那么您的要求可能比您想象的要复杂一些。

如果可以的话,我同意使用 DVCS。我使用 git 来管理我所有的 Latex 代码,这非常棒。

您是否考虑过仅使用纯文本文件来存储您的评论?您可以在 emacs 中使用类似 org-mode 的东西,设置文档的相对链接,为评论添加时间戳,使用 TODO 状态循环来跟踪已评论的内容和未评论的内容,并将评论保留在 Latex 代码旁边,类似:document.tex 和 document_review.org、.txt 或其他内容。 org-mode 将发布为 Latex、html 和其他一些格式。

不管怎样,只是一个建议——KISS 原则在工作中!

It seems like your requirements might be a little more complicated than you think if you've already looked at all those open source projects, and they all don't meet your requirements.

I agree with using a DVCS if you can. I use git to manage all my latex code, and it's awesome.

have you thought of using just a plain text file to store your reviews? You could use something like org-mode in emacs, set up relative links to your documents, time stamp your reviews, use the TODO status cycling to keep track of what's reviewed and whats not, and keep the reviews right along side the latex code, something like: document.tex and document_review.org,.txt or whatever. org-mode will publish to latex, html, and a few other formats.

Anyway, just a suggestion-- KISS principle at work!

弱骨蛰伏 2024-08-30 19:34:40

这听起来是一个有趣的工作流程。您正在考虑多少文档?它们如何进入系统?听起来像是政府客户...

作为第一个推荐,EasyChair。我在管理从作者提交、评审到程序委员会选择接受论文的整个过程方面拥有良好的经验。它是用 Perl 编写的,我听说使用源代码相当容易,尽管我还没有接触过。尤其是匿名处理做得很好。 — 不是开源的。我认识一位开发人员,也许可以在某种基础上共享代码,但我想这排除了这种情况。

EasyChair 也许能够与您的版本控制系统集成。老实说,我不明白为什么这个会出现在你的清单上。您希望审稿人使用文本的一个特定版本。在文案编辑那里,文档将经历多个版本,您可以预期那里的联系不那么正式。

您真的热衷于 Subversion 吗?如果作者和编辑者之间存在大量的来回往来(而不是作者和审稿人之间的正式关系),那么拥有真正的分布式版本控制和高质量的三向差异将使作者和编辑者更容易在进行过程中对文本进行更改。我知道一些出版商出于这个原因使用 Git Hub 来处理 Latex 提交。

This sounds like an interesting workflow. Just how many documents are you considering, and how do they get into the system? It sounds like a government client...

As a first recommendation, EasyChair. I've had good experiences with it, in managing the process from author submission, through review, to the selecting accepted papers by the program committee. It's written in Perl, and I have heard it is reasonable easy to work with the sources, although I haven't contact with that. The handling of anonymising, in particular, is well done. — Not open source. I know one of the developers, and maybe the code can be shared on some basis, but I guess that rules this out.

EasyChair might be able to be integrated with your version control system. To be honest, I don't see why this is on your list. You want referees to work with one particular version of the text. It is with the copy-editor where the document will pass through several versions, and you can expect the contact to be less formal there.

Are you really wedded to Subversion? If there is substantial back-and-forth between authors and copy-editors (as opposed to the formalised relationship between authors and referees), having true distributed version control with good quality three-way diffs makes it much easier to have both authors and editors make changes to the text as they go along. I know of some publishers who use Git Hub to handle Latex submissions for this reason.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文