Thank you, dramajorbob.
Another issue is that things like !fig(KEYWORD) don’t get replaced in compilation, for text pulled in with <$include>. Any workaround for that?
Do you have a minimal reproducing case for this? Replacements have always worked fine for me (I use both of these features extensively). Here is a positive test case, which iterates through both linked and static text styles of including, and tests both project and compile format replacement lists.
included_replacements.zip (83.1 KB)
See attached example.
If I include everything in the compilation, replacement works fine. But I only want to include Chapter 1 (green) in my compilation. The aqua sections are my raw fragments. Then I have things like Figure <$n#chapter:Section2>.4 in the output.
I realize this is a different issue (related to $n) than what I initially thought. The Figure numbers are not working as intended either way. Help is still appreciated.
my_included_replacements.md.zip (827 Bytes)
my_included_replacements.scriv.zip (119.3 KB)
Thanks, that helps! The problem, as you might have guessed, is that compound placeholders are not fully evaluating. Replacements aren’t even a part of the equation. If you paste the actual placeholder that the original string gets replaced with, into the document itself, so no replacement is running, it still won’t work.
So all we need to reproduce this is <$n:chapter:<$level1_title_no_spaces>> in a file called “binderName” in the Research folder that is included into a file in the draft. We’ll get <$n:chapter:binderName> in the output instead of 1.
No way I can think of to get around that. You’ll just have to live with unresolved references and potentially out-of-order numbering in partial compile jobs. In the grand scheme of things, not many tools would work if you tried that anyway!
I’ll write it up to see if we can improve it though at some point in the future. It may be difficult though—the relationship between placeholders, replacements, and such is extremely convoluted. There could be an intentional stop in here on purpose that is avoiding other potential infinite loop problems.
In the good old days of #include <stdio.h>, we pass our code (text) through a preprocessor before the compiler. Why not doing it that way here?
Even if I include everything in the compilation, I cannot make sense of the sequence numbers produced:
# 3. Chapter 1
## 3.1 Title A
The following should be Section 1 Title A
This is Section 1 Title A
Figure 1.1 Sec1A Created
(Expecting Figure 3.1 above)
The following should be Section 1 Title B
This is Section 1 Title B
Figure 1.2 Sec1B Created
(Expecting Figure 3.2 above)
The following should be Section 2 Title A
<$Include:2.1 Title A>
This is Section 2 Title A
Figure 2.1 Sec2A Created
(Expecting Figure 3.3 above)
The following should be Section 2 Title B
<$Include:2.2 Title B>
This is Section 2 Title B
Figure 2.2 Sec2B Created
(Expecting Figure 3.4 above)
## 3.2 Title B
This is Section 3 Title B
This should be Figure Sec 1 B
Figure 3.2 Sec1B Referenced
This should be Figure Sec 2 A
Figure 3.1 Sec2A Referenced
(Don’t understand why 3.2 and 3.1 above)
I don’t think this has much of anything to do with the original report, you can see that if you remove the included section entirely, right?
Briefly though, I would consider how your replacement only stipulates a named anchor for one part of your placeholder, not the other. If you want to reference figure 1.2 from chapter 3, you need to make unique, and refer uniquely, to both the chapter and the image.
Speaking personally, outside of helping other people use this system, I wouldn’t be trying to reinvent things like this with Scrivener’s placeholder syntax. I don’t know what you’re using for post-processing, but with LaTeX I just say \autoref{figure-label} and let it figure out the numbering scheme for you, and in Scrivener you just say [](#figure-label).