HagenbergThesis icon indicating copy to clipboard operation
HagenbergThesis copied to clipboard

More flexible cover page

Open imagingbook opened this issue 7 years ago • 41 comments

Add name of school etc.

imagingbook avatar Oct 24 '16 12:10 imagingbook

If we're making the cover page more flexible, should we set the title in the sans serif font as well now that all the other headings use it as well?

hochleitner avatar Feb 12 '17 21:02 hochleitner

Yes, I think so,

imagingbook avatar Feb 12 '17 21:02 imagingbook

Pls. check the modified cover page in branch 'new-cover-page'. This is a first step only with very minor changes.

imagingbook avatar Mar 02 '17 10:03 imagingbook

I'm picking up on this really old issue. I think the cover page is fairly flexible as it is, but the very first point still sticks: We do not include the name of the school. It never mentions the FH OÖ (or any other university for that matter).

Suggestion: Let's reuse the \placeofstudy command so that it doesn't say "eingereicht ... in Hagenberg" but instead "... der FH Oberösterreich - Fakultät etc." So we would just have to change "in" to "der" and the contents should not be a place but the name of a university.

hochleitner avatar Feb 28 '20 02:02 hochleitner

I agree that this should be fixed but we must be careful about reusing commands. Let's define the revised contents / layout of the cover page(s) first and then decide how to pack this into macros, OK?

imagingbook avatar Feb 28 '20 10:02 imagingbook

Sure. Let's do it that way.

hochleitner avatar Feb 28 '20 12:02 hochleitner

@hochleitner I am almost done with this, and it made me opt for a major revision of the title page generation scheme (see branch flexible-cover-page). In this context I am thinking about moving to key/value class options wherever appropriate. For example, the thesis type would be a single key option with multiple possible values (there is also going to be a phd and custom type). Also, I would like to specify the language used in the title pages (which now is 'german', regardless of the main language). I suggest to make both languages the same by default.

Here is an example of what the \documentclass statement could look like:

\documentclass[type=master,english,titlelanguage=german,smartquotes]{hgbthesis}

Of course the old syntax would still work as before. Alternatively we could keep the old scheme, e.g.,

\documentclass[phd,english,smartquotes]{hgbthesis}
\titlelanguage{german} % like several other document settings
...

Which version would you prefer?

PS: All changes are in https://github.com/Digital-Media/HagenbergThesis/tree/flexible-cover-page/documents/HgbThesisDE

imagingbook avatar Nov 05 '23 09:11 imagingbook

@hochleitner I added a new section (now Sec. 5) to the Manual, describing the proposed "theme" mechanism for the title pages and how to do customization. Note that this is still unfinished: https://github.com/Digital-Media/HagenbergThesis/blob/flexible-cover-page/documents/Manual/main.pdf

imagingbook avatar Nov 06 '23 07:11 imagingbook

Here is an example of what the \documentclass statement could look like:

\documentclass[type=master,english,titlelanguage=german,smartquotes]{hgbthesis}

Which version would you prefer?

A key=value syntax is much cleaner because it is more self-explanatory. I suggest extending this to every option. Something like this:

\documentclass[type=master,
               language=english,
               titlelanguage=german,
               smartquotes=true]{hgbthesis} 

I like the new system a lot. The theming possibility is very powerful and should make adaptions much easier than before. What I noticed is that the smartquotes option doesn't honor the titlelanguage setting yet, so you get English quotation marks on German cover pages.

With the additional content (the cover pages do get a bit crowded, though. Maybe we should think about reducing the font size a bit since the supervisor should also still fit on the front page, as ÖN 2662 suggests.

hochleitner avatar Nov 06 '23 11:11 hochleitner

A key=value syntax is much cleaner because it is more self-explanatory. I suggest extending this to every option.

I totally agree, but I would support the old scheme for a while at least. There is a minor backward compatiblity issue, since sofar the title language was always german. I see two possible solutions:

  1. Always require the specification of titlelanguage if it is not the same as language. This would force some authors to update existing documents to run identical under the new version.
  2. Automatically revert to the old behavior (use German for title pages) if only the plain english option is used instead of language=english. In this case no changes are needed in older documents.

What I noticed is that the smartquotes option doesn't honor the titlelanguage setting yet, so you get English quotation marks on German cover pages.

Yes, this is intentional -- the main language is used in the actual title line. The idea is that the title is usually in the same langage as the body text, while titlelanguage should control the formal (institutional) texts on the front pages. But this is open to discussion of course, all mixed-language docs are a bit sensitive ...

With the additional content (the cover pages do get a bit crowded, though.

The title page formatting has not been looked at yet, even the contents are preliminary. I was waiting for the new ÖN 2662 guidelines and will try to incorporate them asap ...

imagingbook avatar Nov 06 '23 15:11 imagingbook

I totally agree, but I would support the old scheme for a while at least.

Yes, let's go with deprecation. Introduce the new syntax now with the 2024 release, but leave the old one working and display a warning when it's used. Then remove it in the 2025 release.

There is a minor backward compatibility issue, since so far the title language was always german. I see two possible solutions:

  1. Always require the specification of titlelanguage if it is not the same as language. This would force some authors to update existing documents to run identical under the new version.
  2. Automatically revert to the old behavior (use German for title pages) if only the plain english option is used instead of language=english. In this case no changes are needed in older documents.

I'd go with option 1. If titlelanguage isn't specified, the title page has the language of the document. If a different cover language is desired, the attribute can be set. It is somewhat of a breaking change but I'm okay with it. I will, however, ask around how the university wants cover pages to be handled. Is it something that the student can or should decide? Should it match the language of the document? Should it always be German? I am not sure if there is a regulation for that but there might be.

What I noticed is that the smartquotes option doesn't honor the titlelanguage setting yet, so you get English quotation marks on German cover pages.

Yes, this is intentional -- the main language is used in the actual title line. The idea is that the title is usually in the same langage as the body text, while titlelanguage should control the formal (institutional) texts on the front pages. But this is open to discussion of course, all mixed-language docs are a bit sensitive ...

Yeah, you're right. It makes more sense if the title is set in the language of the document. It's just weird in this case because the title is German while the main language isn't, which was of course just for testing purposes.

The title page formatting has not been looked at yet, even the contents are preliminary. I was waiting for the new ÖN 2662 guidelines and will try to incorporate them asap ...

I've looked around a few cover pages of other universities. But so far, I haven't found any decent ones, to be honest. We might just have to play around.

We should also account for an optional secondary advisor. This seems to become more common for masters theses and is necessary for the PhD cover anyway.

hochleitner avatar Nov 07 '23 00:11 hochleitner

Here are a few inspirations from a quick Google Search. The variations are not too big, although I like the bolder approach of KU Leuven.

Maybe we can try to incorporate elements from the new FH OÖ design. It's a bit block/pixely, you can see glimpses of it in the new study guides or the new info sheets for programs.

I'll try to give your new templating system a spin and try to come up with an approach. We can always stay with the classic, LaTeXy feel but something more modern would be nice.

kuleuven kuleuven2 oxford radboud tu_graz uedinburgh ufr uni_wien utoronto

hochleitner avatar Nov 07 '23 11:11 hochleitner

Yes, the Leuven title page looks good. I am currently not much concerned with page design though, trying to get the technical requirements done first. In the meantime I (a) created a "legacy" setup which captures the current design and structure, and (b) a ÖNORM-compliant title page for the future. Currently fiddling with new parameters, option processing, language handling etc. ...

imagingbook avatar Nov 07 '23 15:11 imagingbook

In HgbThesisDE of the version of branch flexible-cover-page I just pushed you find my proposed multiple-advisor scheme, which should be quite flexible and is backward-compatible:

  • First, the existing \advisor command was enhanced to accept an optional "role", e.g. \advisor[Betreuerin]{Prof.~Marie Curie, PhD}, which is also helpful wrt gendering. The optional argument is taken literally, i.e., must be compatible with the title page language.
  • The scheme allows for multiple advisors (role/name pairs) by simply adding more \advisor[..]{..} statements. On the title page these are listed in the same order as specified, eg:
    \advisor[1. Betreuerin]{Professor Frida K.~Putnik, PhD} % commas are no problem
    \advisor[2. Betreuer]{Franz Grillparzer, TU Wien}
    \advisor[Gutachter]{Dr.~B.\,\textbf{Rutal}, MIT}

Technically this is implemented by collecting the various items in so-called "sequences" (aka lists) using the functional package (which is a wrapper for expl3 LaTeX3 kernel functions). It is tricky to use and may get substituted by something simpler.

  • Note that there is also a new \subtitle{} command for defining a sub-title, which is also inserted on the title page.
  • The title page has been cleared from any "filler texts" to make language switching less difficult.

@hochleitner Let me know what you think ...

Update: The implementation of multiple advisors has been revised to use plain TeX/LaTeX macros only, thereby avoiding the functional package alltogether. The (small) forloop package was added for iterating over all advisors. Another new feature added is the use of a simple language dictionary to hold various language-specific terms (in new package hgbdict.sty). This also opens the path to adding additional languages (beyond German and English) in the future. The manual has been updated to reflect recent changes.

imagingbook avatar Nov 09 '23 17:11 imagingbook

Wow, this works really well, and that's just the flexibility needed here.

I did implement a default value for the advisor role, though so it's possible to use \advisor{Mr. Evil} without an argument in square brackets. The value is stored in the dictionary and is currently "Advisor" or "Betreuer*in". I think that makes sense, because without it, it looked like that ": Professor Frida K. Putnik, PhD".

Another thing - do you see the red missing argument warnings on the title page if you specify something empty like \programtype{}. That doesn't seem to work anymore. It still adds the warning to the PDF metadata but it's not on the front page. I thought, that was supposed to be like that? But maybe we just should trigger some warnings in the console instead?

hochleitner avatar Nov 11 '23 16:11 hochleitner

This was not intended but I forgot to warn you that handling of default/empty parameters had not been taken care of yet. I just wanted to show the basic mechanism and user interface, another review is probably needed. Also I am not ultimately happy with the theme definitions, still thinking ... Did you make progress with the 'new look' title page design you had in mind?

imagingbook avatar Nov 11 '23 16:11 imagingbook

I am not sure any more if 'advisor' or 'supervisor' is the proper english term ...

imagingbook avatar Nov 11 '23 16:11 imagingbook

When looking at the examples above, I'd say supervisor.

I'm currently struggling with handling the optional title in the PDF metadata. My intention was to create \hgb@FullTitle which would be equal to \hgb@title if \hgb@SubTitle is empty or \hgb@Title: \hgb@SubTitle if not but \isempty from the xifthen package obviously sees the initial definition of a command (\newcommand{\hgb@SubTitle}{}) as non-empty and therefore always chooses the else path.

Do you have any idea why that is the case?

hochleitner avatar Nov 11 '23 16:11 hochleitner

I ran into this problem before, with \isempty not working as expected. You may want to try \ifthenelse{\equal{\hgb@SubTitle}{}}... instead.

imagingbook avatar Nov 11 '23 17:11 imagingbook

Yeah, I had that idea as well but this one just does the opposite. It always treats it as empty.

I've committed my approach, even though not full working:

https://github.com/Digital-Media/HagenbergThesis/blob/ad81b92772c9c5b5bffc19244ef3d6cd2246ba03/documents/HgbThesisDE/hgbthesis.cls#L171-L173

Could that be because the actual command \subtitle is called after this is defined and the full title command would actually have to be defined after the preamble stuff is called? I'm having a bit of a hard time figuring out when these values are actually evaluated.

hochleitner avatar Nov 11 '23 17:11 hochleitner

Let me check ...

imagingbook avatar Nov 11 '23 17:11 imagingbook

Try

\AtBeginDocument{%
  \ifthenelse{\isempty{\hgb@SubTitle}}%
    {\renewcommand{\hgb@FullTitle}{\hgb@Title}}%
    {\renewcommand{\hgb@FullTitle}{\hgb@Title: \hgb@SubTitle}}}

Sorry, this isn't going to work either. The definition should hook into \maketitle, which I was planning to implement anyway. I actually had a running setup for the combined title in the PDF metadata already. I could not decide what delimiter to use between title and subtitle, since : could be contained in the title itself. Just a side note ...

imagingbook avatar Nov 11 '23 17:11 imagingbook

I was afraid that this is something that has to be "calculated" during the actual call of \maketitle.

We can use "--" as a delimiter as well. As long as it's just used for the PDF metadata, I don't think it's a big deal but you're right.

Maybe we even need an additional array of "small" configuration parameters like that. For example, it might also be an idea to be able to specify a set of colors (a color scheme) if the title page is a bit "fancier", e.g., has a colored bar like in the KU Leuven example.

The title/subtitle separator might be another small config option one might want to switch at some point without too much hassle.

That would be stuff that - in software applications - is stored in config files or build environments. Not sure, if there's something similar for LaTeX or if this is feasible. It's probably too much of a borderline case. Just thinking aloud here. 😀

hochleitner avatar Nov 11 '23 20:11 hochleitner

I modified the setup to perform the necessary initializations using the standard cmd/maketitle/before hook. Also added a custom hook hgb@InitThemeHook that can be used by theme styles to initialize things if needed, instead of redefining the \hgb@InitTheme command (which has been replaced by \@InitTheme and shoud not be redefined). This way parent and child themes may each add their individual setup code, which is then executed in the order of inheritance. I updated the Manual accordingly.

The full title shows in the PDF metadata now.

Maybe we even need an additional array of "small" configuration parameters

Perhaps this could be part of the "theme" mechanism?

That would be stuff that - in software applications - is stored in config files or build environments.

Almost everything can be done, but then I can't really think of that many items to store there. To keep things simple a .sty file would probably be sufficient (also easy to handle in dev/make).

Question: should we move the theme files to a special sub-directory?

imagingbook avatar Nov 12 '23 12:11 imagingbook

Question: should we move the theme files to a special sub-directory?

I just pushed a commit where all theme files were moved to a new subdirectory ./themes/ to see if/how this could work (it does). IMHO this is much cleaner, since themes (there may be many!) do not mess up the document directory.

Note: All ProvidePackage{} statements had to be modified accordingly, and parent themes must be referenced with the subdirectory specified as well! The themes/ directory is assumed to be local (relative to the main document dir). It should only be present with the sources of documents that actually use themes (to be considered in the make process) and will NOT be part of the CTAN style file distribution! But that's OK I think.

Btw, BEAMER uses a similar setup ...

@hochleitner What do you think, should we go forward with this?

imagingbook avatar Nov 12 '23 18:11 imagingbook

Update: I realized that putting theme styles in a local subdir is not such a good idea, thus reverted the above step. It is certainly desirable to distribute standard themes via the CTAN distribution. As a consequence, all theme .sty files must have unique package names stored in a flat directory. In addition I setup a dev/themes/ directory to store the original theme styles, which make will then selectively copy to individual document directories. There is also a new command \hgb@UseTheme[options]{themename} to be used for loading (parent) themes. Options (currently unused) are automatically passed to the associated package.

imagingbook avatar Nov 14 '23 18:11 imagingbook

It seems that the new 'theme' mechanism has a lot of potential that may be useful for other aspects in the future. It should therefore be designed wisely without making it overly complex.
With this in mind, I am currently thinking about de-coupling the document's type (bachelor, master etc.) from the theme, whose main purpose is to define the structure and look of the title pages. This would not require to have a separate theme for each thesis type and thus reduce the number of theme files significantly. E.g., one could then write

\documentclass[type=master,theme=fhooe, ...]{hgbthesis}

with only a single theme file hgbtheme-fhooe.sty. Btw, I would also like to remove the internship report from the main thesis classes, because it is quite different to all others. Perhaps use hgbreport instead?

@hochleitner Any opinions on that?

imagingbook avatar Nov 15 '23 18:11 imagingbook

First off, I support the idea of decoupling the theme from the type. I think the type should only control the information passed on to the title page, in this case, that it's a Master's Thesis or Bachelor's Thesis. The theme should do the actual layout. We could do an FH OÖ theme and a classic, simple theme. If it's possible to select the theme files by matching them with the filename, then it's perfect.

Removing the internship report is perfectly fine. The report class will totally suffice. It is a report after all.

I added a commit with a rough draft of how the title page could look like. It uses a full-page A4 background image that has elements of the FH's new corporate design. The rest of the date is aligned left to fit it better. Page margins can be discussed, I stuck to the 14mm that the CD proposed. I think that this might be a viable solution for theming. Creating an A4 image in the background could help placing items such as logos or ornaments, the rest can be done in the theme file with (mostly) vertical placement. Maybe we provide some commands that make placements a little more predictable but it will also work that way. If course, instead of a big background image, single images could also be inserted but since it's hard to tell how many (from 1 logo to multiple images like in my example), I big image might be more straightforward.

The theme file is still a mess and needs to be cleaned up, I also noticed that the two parboxes create a slight indent, which I can't get rid of. Also in terms of CD, the font should be Arial, but I'm hesitant to switch that.

It's just a proposal; we don't have to stick to that. It might be too "colorful" for a thesis anyway.

hochleitner avatar Nov 20 '23 14:11 hochleitner

Just had a look at this and I think it's quite agreeable for the start. Using a single full-page background PDF is probably the most convenient way to go (this one even has no fonts included, which is great). And yes -- no Arial please (it's not a marketing poster but a thesis after all)! I fixed some horizontal/vertical spacing problems, not sure if the "slight indent" of the parboxes is still there. Also I moved the cover background PDF from images/ to the main document directory, assuming that it should be distributed eventually (CTAN) together with the associated theme style file(s). Will attempt the remaining fixes/changes asap ...

imagingbook avatar Nov 21 '23 20:11 imagingbook

Most items are fixed in the most recent commit (https://github.com/Digital-Media/HagenbergThesis/commit/45ff71b3fe29073f2cb5e280707dfa977e71a4ac). I think this looks very good already, of course a few details need to be looked at and some cleanup is still needed. There is basically just one style file now for theme default (renamed) and another one for theme legacy, so everything is a lot simpler. I also added some checks on the key/value options (wonder why there is no out-of-the-box solution for this). See the comments for details. Still thinking how to better connect the background graphics with the associated theme file ... The Manual needs to be updated too ...

imagingbook avatar Nov 23 '23 21:11 imagingbook