Zettlr: Not able to set Title or Author via YAML Frontmatter

[xge]

Description

I am not able to set title or author via the YAML Frontmatter block. These get overwritten by the defaults set in the Project Settings dialog.
I verified that frontmatter is working by setting the reference-section-title variable.
I also tried setting author and title to an empty string, but the dialog won't let me save that.

Reproducing

Add title or author variables in YAML Frontmatter and export the project via Export Project.
Exported PDF has Author and Title from Project Settings dialog, not from YAML Frontmatter.

Expected behaviour

I want to be able to generate a title page with the author (+affiliations) and title defined in the YAML Frontmatter.

Platform

• OS and version: Windows 10
• Zettlr Version: 1.7.5 and 1.8.0-beta.1

[boring-cyborg[bot]]

Thanks so much for opening up your first issue here on the repository! 🎉 We would like to warmly welcome you to the community behind the app! ☺️ We'll check in soon and have a look at your issue. In the meantime, you can check your issue and make sure it aligns with our contribution guidelines! Here's the comprehensive list:

Enhancements

An enhancement takes a feature and improves or alters its behaviour. Please make sure to argue how your proposition will aid non-technical text workers, and why it can't be emulated easily with other features or apps!

Feature requests

Feature requests introduce whole new features into the app. This requires a lot of work, so these might be turned down if the implementation costs supersede the benefits we expect to see from implementing it. Please do not be disappointed if that happens. It likely has nothing to do with your great request but simply with us and our missing resources!
You can of course always ask someone to implement this feature, because a PR with a working new feature has much higher chances of being merged! :)

Bug reports

Please note that one of the main reasons for why bug reports cannot be addressed is that there's not enough information for us to find and fix the bug you describe, so make sure you try to pinpoint the bug as close as possible.
The ideal bug report for us has two qualities:

1. The bug is always reproducible, at least within a certain context. 2. We know exactly what specifically goes wrong, and there is consensus on
   what should happen instead.

Please note that if you encounter behaviour that does not align with your expectations of what would happen, this might as well be simply intended behaviour and we need to simply _clarify_ why the behaviour is the way it is. This is not to be considered a bug and such issues may be closed! Suggest an enhancement instead!
But now, have a great day and thank you again!

[nathanlesage]

Ah, it might very well be that the project settings override frontmatter vars, but that is actually desired behaviour, I suppose, as the primary aim for a project is to combine multiple files, hence certain frontmatter variables such as titles should be set globally, not locally. Do you happen to use projects for simply using different templates?

[xge]

I use projects to split long documents into multiple files.

I see your point, that declaring these vars globally makes more sense, than on per-file basis.
The Settings dialog however does not give me the freedom to add multiple others with their affiliations, correct? This is only possible via frontmatter iirc.

[nathanlesage]

Yes, you are right… but I don't know how to implement this cleverly from the top of my head

[the-solipsist]

I don't know how exactly projects are implemented in Zettlr, but one potential way could be for projects settings to be stored in a Pandoc "defaults" file.

As far as I can see, the project settings cover:

• Project title
• PDF author
• PDF keywords
• TeX template
• TOC
• TOC depth level
• Generate title page (?)
• CSL
• Export format
• Margins
• Pagesize
• Page numbering
• Fonts
• Line spacing.

As far as I can know, except for "Generate title page", all the rest can be set as metadata or variables in a Pandoc "defaults" file. So, a simple way to do this would be for Zettlr to create a YAML file ("projectname-defaults.yaml") based on all of these settings in the project directory. A user who needs greater control (such as multiple authors, etc.) can directly edit the YAML file and add more fields and values. Most users won't need to. Zettlr can call this using -d projectname-defaults.yaml.

The other alternative (more in line with @xge's needs) is to create a "projectname-metadata.yaml" file, and call that as a --metadata-file projectname-metadata.yaml. This option would allow users who wish to override the project settings to do so with in-file YAML.

I don't know if this is possible, but if it is, then this would be one way of addressing the needs of normal users and power users at the same time without adding greater complexity and clutter to the UI.

[Kangie]

To jump in here, Zettlr should respect YAML frontmatter when setting default fields. I'd even argue that the content should override whatever has been set at the project level - if it's in the document it should take priority.

This is consistent with the way that pandoc handles things (from memory), as variables in content are parsed after those passed in the pandoc command.

The 'create title page' could be an if statement, if nothing is passed the variable will be empty and not acted on - I have a few templates that I use in this way with pandoc. Gotta run, but honestly the best solution (that I can see) is moving the titlepage content into the template and letting Zettlr pass variables to pandoc during the command, and having pandoc read the frontmatter.

Some testing will be required to see how this works. I'll see what I can do about validating which has precedence - command line or frontmatter.

[nathanlesage]

Gotta run, but honestly the best solution (that I can see) is moving the titlepage content into the template and letting Zettlr pass variables to pandoc during the command, and having pandoc read the frontmatter.

This is on my bucket list either way, but this will come with a bigger amount of features, among them a built-in binary of Pandoc shipped with the Zettlr binary. This will close a whole bunch of issues but requires me not to monkey-patch but rather create a whole new module that is able to deal with the CLI flags to the Pandoc binary. I've been meaning to do this either way for some time, and it's very far up on the priority list.

Please do, in the meantime, attempt to collect as much info as possible so I can take all of those precedence-settings of Pandoc into account and build something lasting!

[the-solipsist]

What do you mean by "precedence-settings"? If by that you mean the order of precedence of various variables and metadata options as set in different places, then there is no real documentation on this so far, so it can only be determined by either reading Pandoc's code or through trial and error, as I've tried. I welcome others to contribute to that discussion.

[nathanlesage]

@tarleb Do you have an answer to @the-solipsist's question? That would be awesome <3

[tarleb]

In reverse order of precedence, i.e. later metadata setting override earlier ones:

• defaults files;
• in-document YAML block(s); later blocks take precedence over earlier blocks;
• command line settings (specifying the same key twice creates a list that contains both values).

Variables always have precedence over metadata fields when rendering.

This is from the top of my head, so it might be incomplete or partially wrong. I agree that this needs better documentation.

[Kangie]

My recent experience indicates that (at least for toc) YAML overrides the pandoc command.

I actually need to document this behaviour for work, so stay tuned!

[nathanlesage]

I actually need to document this behaviour for work, so stay tuned!

Sounds great! This would be incredibly helpful for our own Pandoc integration (+ if it makes it into the Pandoc docs for everyone else) :)

[tarleb]

I had a look at the sources, so let me try again. Again, in decreasing order of precedence

• metadata from defaults file (via --defaults)
• metadata from dedicated metadata file (via --metadata-file)
• metadata from command line (via --metadata or -M; repeating the same key creates an array)
• metadata from the document (e.g., YAML blocks; keys in later blocks take precedence)

@Kangie It would be great if you could get permission to feed this back into the pandoc docs.

[Kangie]

I'll see what I can do. Can't see it being commercially sensitive! Worst case I'll have to recreate my results on the taking some extra time.

What you've just outlined broadly corresponds with my experience, particularly where in-document YAML blocks take precedence over the command line.