New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ICML writer improperly wraps template variables? #3551
Comments
The metadata fields are interpreted as Markdown. You can see how they're represented internally by doing
So now you can see why you get this extra material. This is part of how the ICML writer renders a For your purposes, couldn't you just use a template like
so the Note: although the pandoc document model allows pure strings to be included in metadata ( |
This is an interesting problem... I can see that sometimes you'd need one behaviour (with the wrapping), other times not. Would it make sense to support both? So something like |
+++ richarddb [Apr 04 17 13:17 ]:
Would it make sense to support both? So something like $var$ will
output the variable as if it were text in the format; but $var.raw()$
wouldn't? The reason I'm suggesting the latter format, is that you
could extend it to other functions... I don't know if it's out of
bounds for pandoc, but I'm thinking there's some lightweight templating
functionality that would push it to the next level. So you could have
$var.strip()$, $var.format(#.##)# etc.
This has to be addressed before the template phase. If we
have already parsed the content into a list of Inline
elements, there's no reliable way to turn this back into
the original string.
Hence #2139 addresses the issue at the level of the metadata
block.
|
Thanks. Interesting discussion. I personally lean towards the "YAML should always be raw" interpretation:
The big downside seems to be an apparent loss of universality. But in my scheme, you would need template processing directives to "wrap" header values appropriately for different target types, which pandoc knows at runtime. Problem with my scheme: My guess is that defaulting to raw would break a lot of existing usages, if nothing else because that's the way it works now. So I would be tempted to vote for the "mark as raw in the header solution" for that reason; though it then gets more complicated if you want to use the variable as a boolean. Would we introduce typing? But either way, it seems legitimate that there's valid use cases for both. It does seem to me that either way this discussion starts moving pandoc in the direction of some generic templating features. I'm not entirely sure what that means, or if its "correct" per your vision? Pro: Some users expect that functionality; and we refer to "templates". [I'm going to close this issue here, since it's already conceptually raised elsewhere.] |
I've been working to modify the ICML output template to be suitable for use as a letter template. So in the pandoc markdown file, I prepend a YAML section with variables that would be used as front/end-matter on the letter. For example:
I then cloned the default.icml to add the front/end-matter content into the template. For example, I would add the specification for the use of the sender name against a defined paragraph style in the ICML:
The problem is my use of the variable
sender
. When I try substitute the variable, extra content gets added around the variable. So if$sender$ := "Sender Name"
I would get this:...instead of just this:
In other words, the
<Content><CharacterStyleRange AppliedCharacterStyle="$ID/NormalCharacterStyle">
and</CharacterStyleRange></Content>
are getting pre/post-pended to the content I expect. As a workaround, I could remove the character definition from my template; but then I'd be lacking the required line break<Br />
before the closing</CharacterStyleRange>
.I had a look in the ICML writer. It seems to me that the function on line 520 is what's adding the additional tags. (But then this is the first time I'm reading Haskell code.)
The text was updated successfully, but these errors were encountered: