Order of elements in copyright statement do not match the spec
zackbatist opened this issue · comments
According to the formatting guidelines it should be:
Copyright by Jesse Knight 2023
But this template makes it:
Copyright 2023 by Jesse Knight
I haven't had SGS raise this issue before. Did they reject your thesis for it or complain?
In general, I think copyright notices are supposed to have year before owner, and I will keep it this way for now. We are in the process of reviewing some of these formatting guidelines now actually, so I will add this to the list.
If you want to match SGS template exactly you can use:
\makeatletter
\copyrighttext{{\copyright} Copyright by {\@author} {\@gradyear}}
\makeatother
(or avoid \makeat... and just replace \@author and \@gradyear with the values directly).
Yes, they rejected and requested revisions. I manually updated the cls file to conform to the spec locally and resubmitted.
The wikipedia norm is irrelevant in this case, since the University of Toronto guidelines clearly specify their own format (https://www.sgs.utoronto.ca/current-students/program-completion/formatting/). I agree that it is stupid and arbitrary, but after 7 years of research, and then waiting an additional 2 whole weeks for the pdf formatting review to turn up this minor administrative discrepancy embedded in the official template, it kind of stings. Hopefully it won't take another fortnight for them to review this extremely minor change.
100% agreed. The amount of wasted time & added stress for this junk is wild. Was this the only formatting issue for you? I myself just submitted my thesis and they did not flag the copyright 🙄 but had some equally silly reasons for rejecting. My favourite is including the TOC within the TOC itself... So, clearly the checks are also inconsistent. Maybe I will make an open issue to collect user-submitted reasons for rejection.
They also flagged the name of the degree. Apparently the name of the degree stated on the acceptance letter when I joined the program is not actually accurate :/
That's a great idea to open an issue thread for user-submitted reasons for rejection. You would think that listening to user feedback by those most effected would be a standard aspect of a review process.