[alireza5969]

Problem 1

bash build/build.sh fails at the PDF export step on a fresh environment
created from build/environment.yml:

File ".../weasyprint/document.py", line 157, in transform
    super().transform(a, b, c, d, e, f)
AttributeError: 'super' object has no attribute 'transform'
Error producing PDF.

HTML export works, and the CSS warnings printed before the traceback are
harmless (WeasyPrint skips properties it doesn't support).

Cause

The pinned WeasyPrint version calls Stream.transform() from pydyf, but
pydyf 0.11 removed that method. Because pydyf isn't pinned, a fresh
install resolves to a version that is incompatible with WeasyPrint.

Fix

Pin pydyf<0.11 in build/environment.yml:

dependencies:
  - pydyf<0.11

Testing

• Created a fresh environment with Miniforge/mamba from build/environment.yml
• Before the change: PDF export fails with the error above
• After the change (mamba install "pydyf<0.11"): bash build/build.sh
  completes and produces the PDF

Notes

This pin can be removed once the project bumps WeasyPrint to a version
compatible with newer pydyf (WeasyPrint 61+).

Problem 2

The correspondence block in content/00.front-matter.md renders author.email directly:

{{ author.name }} \<{{ author.email }}\>

This has two problems:

1. List values render as a Python repr. email is documented as a string, but users naturally write several addresses as a YAML list. Jinja then prints the list repr, producing output like Name <['a@x.org', 'b@y.org']>.
2. Emails are never links, even for a single string. The \< and \> are escaped, so Pandoc does not autolink the address. The output is plain text such as Name <a@x.org>.

Change

• content/00.front-matter.md: in the #correspondence block, normalize author.email to a list. A string becomes a one-item list, a list is used as is, and null or a missing value becomes an empty list. Each address is then rendered as an explicit [addr](mailto:addr) link.
• Addresses are shown in parentheses after the author's name, and multiple addresses are comma-separated: Name (a@x.org, b@y.org).
• USAGE.md: document that email may be a string or a list.

No change to Manubot itself is needed.

Why in the template and not in Manubot

Manubot normalizes affiliations and funders to lists in manubot/process/util.py. Doing the same for email would break existing manuscripts whose custom templates use {{ author.email }} as a string, because they would start printing list reprs. Handling both types in the template is backward compatible.

Behavior

email in metadata.yaml	Before	After
`a@x.org` (string)	`Name a@x.org` (plain text)	`Name (`a@x.org`)`
`[a@x.org, b@y.org]`	`Name <['a@x.org', 'b@y.org']>`	`Name (`a@x.org`, `b@y.org`)`
`[a@x.org]`	repr garbage	linked, as for a string
`null` / missing	`Name <>` or error	`Name` only

Testing

Rendered the template with Manubot's Jinja2 environment (make_logging_undefined, same delimiters and extensions) and converted the result with Pandoc to HTML. I checked string, list, single-item list, null, missing and non-corresponding authors, plus addresses containing underscores and dots. I also confirmed the correspondence block in a real manuscript build, where each address becomes a working mailto: link.

Note for reviewers

This changes the visible format from Name <email> to Name (email). I think this is better, since the angle brackets were needed only to imitate an email header. If you prefer to keep <...>, it is a two-character change in one line.

[AppVeyorBot]

AppVeyor build 1.0.350 for commit b5684ef is now complete.

Found 51 potential spelling error(s). Preview:

content/02.delete-me.md:44:adipiscing
content/02.delete-me.md:44:aliqua
content/02.delete-me.md:44:amet
content/02.delete-me.md:44:consectetur
content/02.delete-me.md:44:dolore
content/02.delete-me.md:44:eiusmod
content/02.delete-me.md:44:elit
content/02.delete-me.md:44:incididunt
content/02.delete-me.md:44:ipsum
content/02.delete-me.md:44:labore
content/02.delete-me.md:44:Lorem
content/02.delete-me.md:44:magna
content/02...

The rendered manuscript from this build is temporarily available for download at:

• manuscript-1.0.350-b5684ef.html
• manuscript-1.0.350-b5684ef.pdf
• spelling-errors-1.0.350-b5684ef.txt
• spelling-error-locations-1.0.350-b5684ef.txt

[AppVeyorBot]

AppVeyor build 1.0.351

Found 51 potential spelling error(s). Preview:

content/02.delete-me.md:44:adipiscing
content/02.delete-me.md:44:aliqua
content/02.delete-me.md:44:amet
content/02.delete-me.md:44:consectetur
content/02.delete-me.md:44:dolore
content/02.delete-me.md:44:eiusmod
content/02.delete-me.md:44:elit
content/02.delete-me.md:44:incididunt
content/02.delete-me.md:44:ipsum
content/02.delete-me.md:44:labore
content/02.delete-me.md:44:Lorem
content/02.delete-me.md:44:magna
content/02...

for commit 787b602 is now complete. The rendered manuscript from this build is temporarily available for download at:

• manuscript-1.0.351-787b602.html
• manuscript-1.0.351-787b602.pdf
• spelling-errors-1.0.351-787b602.txt
• spelling-error-locations-1.0.351-787b602.txt

[agitter]

If the package version needs to be locked, merging that change makes sense. I haven't tested it yet.

email is documented as a string, but users naturally write several addresses as a YAML list

I don't see this as a real problem we've faced. Our users provide one email address as a string, as documented. I'm not that interested in generalizing to support multiple emails per author.