Emails are treated differently in acmart
Closed this issue · 11 comments
On Racket & scribble HEAD, emails are being escaped in the same way as the main body, causing emails like a-b.c@d.edu to be typeset as a{-}b.c@d.edu. This doesn't seem to be the case for Racket 7.0 (I'm not very sure about the version here).
The scribble file:
#lang scribble/acmart @acmsmall
@title{Title}
@author[#:email "a-b.c@d.edu"]{First Last}
What is the better way to get back a-b.c@d.edu here? Would adding a keyword argument to email to allow typesetting emails with 'exact-chars style property be an acceptable solution?
On Racket 6.12 and Racket 7, I'm seeing a-b.c@d.edu typeset as a{-}b.c@d.edu. So maybe this isn't a regression?
Changing email sounds good --- either by adding a keyword or changing the default behavior. (Changing the default would make email more useful, IMO.)
What (if anything?) do the (latex level) docs say for the form that the email address gets dropped into?
That \email{....} is both typeset in the manuscript and used by metadata extraction tools.
https://www.acm.org/binaries/content/assets/publications/consolidated-tex-template/acmart.pdf
Sounds like a +1 for 'exact-chars
The doc I can find for \email points to the the amsart package and the actual TeX implementation, which I have no knowledge of.
Looks like the email RFC (https://tools.ietf.org/html/rfc5322, local part -> dot-atom -> atext) allows pretty much any character except parenthesis and brackets. When typesetting, # and % needs to be escaped as \# and \% but others don't.
Is there a way to control scribble to escape only # and %?
The @email takes arbitrary pre-content?. How can I handle this? Should I call decode-content and do the escaping for each of the decoded content? that is a string?, ignoring other kinds of content??
How about: escape string arguments & do nothing for other arguments.
It seems like a bad idea to traverse a decoded content escaping strings, because those strings might be in an exact-chars element already.
In that case, perhaps a better way is just to add a new function that takes (or/c string? (listof string?)), do proper escaping and wrap the result in an email?. What do you think?
Sure.