On Fri, Oct 7, 2022 at 8:39 AM Scott Kostyshak <skost...@lyx.org> wrote:
> On Thu, Oct 06, 2022 at 06:20:36AM -0600, Joel Kulesza wrote: > > > Please contact me with any comments, questions, or concerns. > > Very cool. Congrats! > > I do have questions, but no worries if you prefer to skip some of them :) > > 1. I forget whether you have 2.4.0dev set up, but if you do can you > compile your .lyx file (which I assume is in 2.3.x format) with > 2.4.0dev and see if there are any differences (you can check with the > program 'diffpdf' for example, and set comparison to "appearance"). > This is a combined test of lyx2lyx and of master's LaTeX output. > > 2. I see there are many authors. How many people actually edited the > .lyx file? What was your workflow to handle people working > simultaneously on such a large document? Did you use Git? Dropbox? > Did you use child documents? > > 3. How often did you need ERT? For example, > > $ grep "begin_inset ERT" UserGuide.lyx | wc -l > 56 > Scott, You ask some very interesting questions... Thanks! The manual you see is from TeXLive 2018 (locked into a particular version so the team uses a consistent version). However, I just received a new computer with TeXLive 2022. When I compare 2.4.0a3 versus 2.3.2 (the version used to prepare that document, again, locked at an older version across the team), I see notable differences. The LuaLaTeX-produced 2.3.2 document has 1084 pages and the LuaLaTeX-produced 2.4.0a3 document has 1073 pages. The difference appears to be the exclusion of content in 2.4.0a3 where TeX code embedded in the child document program listing field is being processed differently between the two versions. Also, there are a couple ERT processing issues of complicated index entries that lead to makeindex errors in 2.4.0a3 that are ignored in 2.3.2. It's distressing that this differs but the fixes are straightforward and it's good to know about the issues. Comparing 2.3.2 and 2.4.0a3 with TexLive 2018, I see the same, so it definitely comes down to how LyX is producing TeX. However, one TeX-based difference we run into with such a complicated document is that including siunitx as we have before is no longer viable without memory tweaks. I need to dive into this further. Regarding authors versus those touching the LyX file, there were about 16 folks who modified the LyX file(s). We use a git-centric, PR-review-based approach (with the Atlassian BitBucket tool). This workflow is the reason that I tend to periodically raise the idea of significant end-of-line whitespace (with respect to comparing diffs, whitespace, and the frequent need to look at under-the-hood .lyx file code). That said, I use a review process that involves looking at the code and resulting PDF. I'm unsure of how this compares to my colleagues and how they use the code, PDF, or some combination. Of course, I'm excited by Yuriy's recent interest and work on this. Regarding ERT, the answer surprises me. We use parent-child documents and I see the "grep|wc" result of 1013. I knew we used it, but that frequency is beyond what I expected (though perhaps sensible regarding how many cross-pointing index entries we have). Note that we also have a ~700 line preamble. Nevertheless, I'm unsure what we could meaningfully trim and, speaking for myself, it isn't unmanageable. One remark, and something I need to construct an MWE from to then post to the tracker: there are periodically dialogs that accept TeX code (e.g., "~" or "\texttt") and some that misbehave (generally through literal interpretation) when supplied. This appears to differ between 2.3.2 and 2.4.0a3. Consistent and TeX-compliant behavior (in some manner) would be ideal for our use case. Thank you again for these good questions. Sorry for the delayed response, but I wanted to provide a thorough analysis and description. - Joel
-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
