More flexible cover page

[imagingbook]

Add name of school etc.

[hochleitner]

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?

[imagingbook]

Yes, I think so,

[imagingbook]

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

[hochleitner]

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.

[imagingbook]

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?

[hochleitner]

Sure. Let's do it that way.

[imagingbook]

@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]

@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

[hochleitner]

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.

[imagingbook]

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 ...

[hochleitner]

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]

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.

[imagingbook]

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]

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.

[hochleitner]

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?

[imagingbook]

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]

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

[hochleitner]

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?

[imagingbook]

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

[hochleitner]

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:

HagenbergThesis/documents/HgbThesisDE/hgbthesis.cls

Lines 171 to 173 in ad81b92

	% Full title (title + subtitle) where a combination of both is required:
	\newcommand{\hgb@FullTitle}{}
	\ifthenelse{\isempty{\hgb@SubTitle}}{\renewcommand{\hgb@FullTitle}{\hgb@Title}}{\renewcommand{\hgb@FullTitle}{\hgb@Title: \hgb@SubTitle}}

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.

[imagingbook]

Let me check ...

[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 ...

[hochleitner]

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. 😀

[imagingbook]

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]

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]

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]

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?

[hochleitner]

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.

[imagingbook]

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]

Most items are fixed in the most recent commit (45ff71b). 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]

@hochleitner (comments requested)
I just added the following proposal for naming theme-related resources (in /dev/themes/readme.txt):
A theme specifies the contents and layout of the thesis front pages and is associated with a LaTeX style file named in the form

	hgbtheme-<themeID>.sty

where <themeID> is a unique identifier, for example,

	hgbtheme-fhooe2023.sty 

Additional files required by a theme (such as graphics files) must be named with the
complete theme name as a prefix, for example,

	hgbtheme-fhooe2023-coverbackground.pdf

The rationale behind this strict naming convention is that themes will be part of the CTAN distribution, thus all theme-related files will eventually end up in a single, flat directory.

To use a specific theme its <themeID> must be passed to the \documentclass command, for example,

	\documentclass[theme=fhooe2023,...]{hgbthesis}

All theme sources are stored in /dev/themes (perhaps with individual subdirectories?).

[hochleitner]

That's awesome. I'll give it a spin this weekend.

One thing that still gives me headaches is positioning the text elements on the title page.
All these (La)TeX spacing macros are not very straightforward to use in my opinion.

How do you feel about using the textpos package for that? It would allow for absolute placement of text boxes and the syntax seems pretty clean.
If you don't mind, I'd try it out.

See
https://nxg.me.uk/dist/textpos/textpos.pdf for examples.

Also, I suggest including an fhooe style as well as a plain style that resembles the previous one.

[imagingbook]

Yes, the textpos package looks OK, I think you should try it out.

In today's commits (7cce893 being the latest) I made a couple of changes/improvements:

Themes:

• Renamed themes (once again): default now refers to the original layout, fhooe24 is the new experimental version.

• The logo mechanism has been completely removed from hgbthesis.cls, this must be handled by theme files now. The \logofile command has been deprecated but still works as expected, in particular \logofile{} will hide the logo. Custom logos may be placed in /images/ (as before) or in the document root directory.

• The original (FH) logo in /images/logo.pdf was moved to hgbtheme-default-logo.pdf (following the new naming rules). A readme.txt file was added in /images/ (now empty) to avoid removal by GIT.

• The new background graphic was renamed to hgbtheme-fhooe24-coverbackground.pdf.

License/Declaration

• Converted all declaration/license texts to dictionary entries, thereby greatly simplifying title page setup.
• \license{cclicense} or \license{strictlicense} is now the preferred input, but \license{cc}, \license{strict}, \cclicense and \strictlicense still work.
• Theme writers may add other licenses by (a) adding a dictionary entry, e.g., \hgbDictionarySet{FooLicense}{english}{...} and (b) using \license{FooLicense} in the main document preamble.

Revised the Manual

[imagingbook]

More changes ... (3fedcf3)
The internship type has been re-implemented in the default theme (with some support in hgbthesis.cls), which also supports sub-titles now. There is no more internship theme.
Language switching has been much revised, with new commands and environments. german and ngerman are treated as synonymous (only german should be used for language switching and dictionary entries).

[imagingbook]

Build process revised (3bd9257):

• For TEXMF root conformity, the directory structure for cls/sty/bib files has been changed (once more) to /dev/texmf/tex/latex and /dev/texmf/bibtex/bib, respectively. This now makes /dev/texmf a "clean" TEXMF root directory which can be added by initexmf --register-root=... without throwing an error (this was no problem when performed with the MikTeX console).
• The build scripts have been adapted to the new layout. The cls/sty/bib files are still copied to the individual document directory during each build, but (and this is new!) deleted after the build is done. Thereby we avoid a large number of duplicate files (they are still contained in the associated ZIP files). The ZIP step was moved back to makefile because it is not immediately LaTeX-related. Several variable names have changed, things cleaned up a bit.
• Two more make goals were added in makefile: (a) showsetup to list the initial variables, (b) inittex to add dev/texmf as a TEXMF root directory. None of these are used in the main build process but may be helpful for debugging.
• The references.bib file is now included in the CTAN distibution and also gets a version date that is automatically updated.
• Did a full rebuild, everything's up to date now.

[imagingbook]

Today's commit (d168c16) adds a stable build process (with full rebuild).
Checked document processing in Overleaf (everything's just fine).

[hochleitner]

Thanks, @imagingbook, for all the updates, and sorry for my late responses. I had the time to check everything out; it feels like a robust solution. I like that the .sty and .cls files are now removed from the directories, which is cleaner. Adding a TEXMF root is easy; finally, we have this one place to work and test.

There's one issue I'm afraid of: when people start using the current version from GitHub by cloning the repository and working locally (not on Overleaf), they need to have functioning versions because all the style files are not there. If the version on CTAN is current, then it's no issue. But if we proceed to add changes to the main branch, it's not usable anymore unless people add the TEXMF root, which is too much for regular users. I don't know how to deal with this.

Anyway, I went ahead and used the textpos package on the fhooe24 theme. You can check it out. The HgbThesisDE document has the theme enabled. If you want to see the grid that's in the background, you can comment in this line in main.tex:

HagenbergThesis/documents/HgbThesisDE/main.tex

Line 31 in bf47a33

%\TPShowGrid*{13}{19}

Also, if you want to see the boxes that are produced for the various parts of the title page, you can add the showboxes option for the package (there's a commented-out version for that as well in the .sty file:

HagenbergThesis/dev/texmf/tex/latex/hagenberg-thesis/hgbtheme-fhooe24.sty

Lines 11 to 12 in bf47a33

	\RequirePackage[absolute]{textpos}
	%\RequirePackage[absolute,showboxes]{textpos}

The grid consists of 15 horizontal 14x14 mm boxes. That's how the FH OÖ CD defines the layout. It also defines that all the content must start in the second box (14x14 mm from each side), so I set the offset for one box. So, if you place a textbox at (0,0), it starts 14x14mm inwards. This could be changed so that (0,0) is really at the top left corner of the paper.

So commands work like this:

HagenbergThesis/dev/texmf/tex/latex/hagenberg-thesis/hgbtheme-fhooe24.sty

Lines 67 to 69 in bf47a33

	\begin{textblock}{10}[0,1](0,7)
	{\Large\hgb@Author\par}%
	\end{textblock}

(0,7) means that it's the first box horizontally and the 8th vertically (floating point values such as 6.5 are also possible. This puts it in the center of a grid cell instead of its beginning).
The resulting textbox is 10 boxes long (in this case, 140 mm). Vertically, it takes as much space as needed.
The optional argument (in this case [0,1] allows us to set the origin point of the box. [0,0] is top left, [0,1] is lower left, etc.

I find positioning content like this quite intuitive. It might be a good way for themes. The package is currently set to absolute positioning, which starts everything from the top left (relative would also be an option, but that would mean setting positions based on the previous boxes, which is quite similar to not using the package at all). Using absolute positioning has the drawback that LaTeX thinks there is no content on the page at all, which is why a \null\newpage command is needed at the end to create a page break. It is somewhat not very beautiful but acceptable.

Please have a look and tell me what you think.

[imagingbook]

@hochleitner , this looks very good to me - thanks!

There's one issue I'm afraid of: when people start using the current version from GitHub by cloning ...

I had thought about this too, but the ZIP files in documents\ (with download links provided) DO contain all current .sty and .cls files! So typical users should start by downloading one of these and not by cloning the repo. I think a remark in our README file should make this clear.

a \null\newpage command is needed ...

This is no big deal, since the theme files are typically not to be edited by users. Btw, I removed the \newpage command, I think it is redundant.

[hochleitner]

hgbtheme-default has been switched to a textpos layout. I created a 1cm grid, which is good to handle.

The title and subtitle are in the same text block with a bottom alignment, so it extends above if they start taking up additional lines. Spacing to the author's name and logo should stay consistent if the subtitle is absent; that also gets checked.

I've added the place of study to the front page. I wasn't sure if we should keep "eingereicht am/submitted to" or just show the program, university, and location without further text.

Concerning the date, I just printed the year and left out the month (as in the ÖNORM).

Advisors are now at the bottom. One or two look good; it works up to four, which I don't think we'll realistically need.

I also updated the internship report. This still keeps the separate company page. Therefore, advisors are not printed on the front page but on the company page. I was wondering if multiple advisors make sense for an internship report or if there's, by definition, always just one internship supervisor (I asked our internship coordinator how he'd like to handle that). I thought this through, and unless it's a requirement that there's a single contact, it makes sense to allow for more. Maybe you had an official supervisor (which is, say, the department lead), but you've worked more with a unit or team lead. Then you might want to add both. Therefore, I'm currently printing the advisor's table. If multiple advisors do not make sense, we need to reduce that to the first advisor.

I had to make small changes in hgbdict.sty and hgbthesis.cls, but nothing significant.

Please look at it, tell me your thoughts, and make changes if I missed something. After that I'll update the fhooe theme as well. It still needs to respect the internship report, and I'll have to put the title and subtitle in the same text block because it looks weird in certain situations otherwise (when titles are too long, the subtitle is missing, etc.).

[imagingbook]

Looks good!
I was wondering how to replace \TPShowGrid{21}{30} by a more generic statement that works for any grid size. Then again it is only for debugging and should probably be removed from the main docs anyway ...

[hochleitner]

I talked to the person responsible for internships. He says the internship contact is not fully relevant. He suggested making it optional and only allowing for one contact person to be listed. So I'll only print the first advisor; if the command is left out, there's no error message.

Concerning \TPShowGrid{21}{30}. The variables \TPHorizModule and \TPVertModule contain the horizontal and vertical grid widths, so by dividing \paperwidth by \TPHorizModule, you should get the number of cells horizontally. I haven't tried it yet though.