Use the `fira` bundle about mtheme HOT 20 CLOSED

There is a potential issue in that fira is extremely recent, so unless a user has been doing a good job keeping their TeX install up to date, they might not have the package. Similarly, even if they have the package, it's important for them to be on the most recent version.

I wouldn't bother with that too much. We should just load the package and require a minimum version number. You cannot make everybody happy and requiring to keep the TeX install up-to-date is imho the least we can expect from the user.

I'd recommend extensive testing with the fira package before adopting it into the metropolis theme as a required package.

This on the other hand is a really important point. @ChipmunkMath As you already started to look into the package, maybe you can do that?

from mtheme.

There is a potential issue in that fira is extremely recent, so unless a user has been doing a good job keeping their TeX install up to date, they might not have the package. Similarly, even if they have the package, it's important for them to be on the most recent version.

I wouldn't bother with that too much. We should just load the package and require a minimum version number. You cannot make everybody happy and requiring to keep the TeX install up-to-date is imho the least we can expect from the user.

I would disagree very strongly with that approach. Many people, myself included, use Linux distributions that whilst having up-to-date TeX stacks they don't necessarily pick up new TeX packages immediately. Your comment is representative of someone seemingly very familiar with LaTeX. Not all users of this theme are going to be as familiar or invested in their LaTeX installations. I could probably quite easily go and add a package to my local install, but I'm unlikely to do that too much because I've been bitten (not by TeX, but other languages) by locally installing packages that are later picked up by my distribution and provided that way and updated.

Is there a way to check for the fira package and use it, and if not fall back to trying to load the font?

from mtheme.

Just to clarify that we understand each other right: The only thing I expect is, that the user has the latest TeXLive version installed or updates to it and performs a tlmgr update --all if need be. I don't want him to install packages manually.

Is there a way to check for the fira package and use it, and if not fall back to trying to load the font?

That would probably be possible, but that would overcomplicate things in my opinion. And the main reason to use the fira package in the first place is to make things easier – for the user and in the mtheme package source code.

from mtheme.

Just to clarify that we understand each other right: The only thing I expect is, that the user has the latest TeXLive version installed or updates to it and performs a tlmgr update --all if need be. I don't want him to install packages manually.

That's exactly what I try to avoid. I take my packages from my distro and I leave it at that. I added this theme myself bc it wasn't in CTAN and I wanted to try it out & I liked it and ended up using it. My TeXLive on my machine at work is current 2013 (yes, I am about to do a full OS update, but...).

If you want to make things easier on the user, here's one user asking you not to do this.

from mtheme.

@ChipmunkMath , do you have any details on the minor issues you came across with fira?

@rchurchley: The issue I came across was that the fira package lacks a command to manually select Fira Sans Regular. There's lots of commands to select specific fonts -- \firalight, \firabook, \firaheavy, etc. -- but, as far as I can tell, there is no manual selection option to switch to Fira Sans Regular. Normally, for this package, that isn't such a big issue: the expectation is for you to default to Fira Sans Regular (although there are options to change the default), so it's not too impossible to work around this.

However, for our purposes, this is (I think?) an issue. We generally want our font themes to have a lighter default (whether Fira Sans Light for default Metropolis or Fira Sans Book for the theme I made), but we want access to Fira Sans Regular as a possible bold/highlighting font.

I'm guessing this is just an oversight on the part of the package writer. With more testing just now, I also found that the \firabold command is missing. We could potentially reach out to him and see if he'd be willing to fill in the gaps we find during testing. His e-mail address is at the bottom of the fira package README.

The other potential issue is that I'm not sure how well selecting fonts using those above commands (\firaheavy, etc.) works for actually writing a font theme in TeX. This is all pretty new stuff to me, so someone with more experience would need to weigh in if that's bad design or just fine to do. As we talked about in #75, we need to manually define some font choices when writing a font theme. I just don't know if making those font choices via fira commands is a good idea or even possible.

I'd recommend extensive testing with the fira package before adopting it into the metropolis theme as a required package.

This on the other hand is a really important point. @ChipmunkMath As you already started to look into the package, maybe you can do that?

@benjamin-weiss: Sorry, but I'm not going to have the time to work on that for awhile. I'm about to get married and then be on honeymoon for quite awhile (yay), so useful work is going out the window for now. Here's my rundown on things to deal with before integrating fira:

• Make sure font calls to all Fira fonts are working: \firaregular, etc. This will likely require contacting the package maintainer. Looking through FiraSans.sty, it seems like the fixes shouldn't be tough.
• Decide on a good/reasonable way to use the fira package to make custom choices for frametitle, bibliography elements, etc.
• Double-check that \textbf{}, \emph{}, etc. are all playing nicely and outputting what we think is reasonable. Also make sure that they play nice in regards to the custom choices made in the font theme (i.e., if you call a \textbf inside of frametitle does anything weird happen?).

I think that's all the basic issues that need to be done. Chances are that you'll find new, fun things to deal with while working on integrating it. But if you want this investigated and dealt with in the next month or two, I'm just not going to be able to help. Sorry.

And the main reason to use the fira package in the first place is to make things easier – for the user and in the mtheme package source code.

@gavinsimpson: I'm with @benjamin-weiss on this one. I think that @benjamin-weiss may be underestimating the hassle of updating TeX for a user, but I don't think that's particularly worse than manually installing the Fira fonts and needing to use XeLaTeX for compiling. You say that you wanted to try out mtheme, but would it have been particularly more difficult to run TeX Live and just grab the fira package on its own? I mean, that's basically what I did a few days ago to test it out.

In my opinion, asking a user to install fonts and run a less-standard TeX compiler is at least as onerous as asking them to install a new package. And the latter option has the advantage that, in a year's time or so, a modern TeX distribution will already have the fira package ready to use (and hopefully mtheme too!). Is there another downside I'm missing?

from mtheme.

Sorry, but I'm not going to have the time to work on that for awhile. I'm about to get married and then be on honeymoon for quite awhile (yay), so useful work is going out the window for now.

Congratulations and have a good time on your honeymoon!

And don't worry! Your last comment already gives a lot of insights and is a good information base to get started with the testing. So, thank you for that.

from mtheme.

You say that you wanted to try out mtheme, but would it have been particularly more difficult to run TeX Live and just grab the fira package on its own? I mean, that's basically what I did a few days ago to test it out.

@ChipmunkMath Seeing as I did this in April, the only option was to install fira fonts. That was (is) easier than potentially for messing up my TeXLive. I'm not that familiar with TeX so I leave that up to my linux distro. I try not to mess with those packages.

In my case, the fira package (for Fedora, not LaTeX/TeXLive) was available but didn't include all the fonts for the version at work. But it was trivial to add them. Messing with the entire TeXLive shipped by my distro is an entirely different matter.

I can install XeLaTeX with a simple yum install foo command, and I can compile with it using the existing tools I use to write the LaTeX: Emacs plus some R (stats) specific software. I can do this because someone packaged these things nicely for my distro - as do most Linux distros I know.

I think you are underestimating the reticence people have to fiddling with big stacks of software that are provided by their Linux distribution. Even when I install Fedora 22 at work (next week, now that I've finished teaching), I'm still not going to be running the latest TexLive (2015; Fedora 22 was prepared/released before the 2015 TeXLive was out), so if you force this change I just won't be able upgrade to your new version for at least a year so I don't risk fighting TeXlive installations & my distro when I should be writing lectures.

People don't want to be managing software all the time.

from mtheme.

I have to take side with @gavinsimpson on this particular issue. Telling people to apt-get install this or zypper in that is less demanding for most users than asking them to fiddle with a TeX installed from packages. So, I'd really like to see the fira bundle as a dependency of the theme but as of now it should not be a hard dependency. This is especially important since we cannot ensure full compatibility as shown by @ChipmunkMath.

from mtheme.

As much as @ChipmunkMath is probably right, that I underestimate the hassle installing a new version of TeXLive is for a user, you probably overestimate how much trouble it actually is. Another thing to keep in mind: In my opinion right now the mtheme is to be considered a package in the beta stadium. So if a user wants to try it, he has to expect a little bit of trouble. By the time we consider it stable and release it on CTAN, TeXLive 2015 (including the Fira package) will be out for some time and would run (even with the Fira package dependency, out of the box. So I think we should probably not so much look at the situation right now, but try to imagine the situation when we release on CTAN.

This is especially important since we cannot ensure full compatibility as shown by @ChipmunkMath.

That is not yet 100% confirmed. Maybe we can still work around the problems @ChipmunkMath mentioned without too much trouble.

from mtheme.

Many people, myself included, use Linux distributions that whilst having up-to-date TeX stacks they don't necessarily pick up new TeX packages immediately.

@gavinsimpson's point is valid. Moving to the fira package does involve a real tradeoff: it creates a hassle for people with machines which (a) have the Fira fonts installed under the correct names and (b) do not have an up-to-date version of the fira bundle. This is a very real cost, and I did not realize that some Linux distributions use a competing update system for their TeX distributions --- I can definitely see how that could get hairy enough to not want to mess with.

That said, I sort of feel the same thing about installing fonts on an unfamiliar system, regardless of how easy it actually is. (Perhaps that's a personal failing of mine; I still haven't brought myself to install Fira on my work computer.) I agree with @matze that @gavinsimpson's concerns are enough to not require fira as a hard dependency now; but I also agree with @benjamin-weiss that we should develop with an eye to requiring it in the long term. We should consider a roadmap that provides the fira bundle option alongside the xelatex alternative until (say) the release of TeX Live 2016.

I'm about to get married and then be on honeymoon for quite awhile (yay!)

Congratulations @ChipmunkMath and have a wonderful honeymoon! Thank you for your extremely helpful comments, which will help direct our development efforts in your absence.

from mtheme.

Ok, so we introduce a new option noFiraPackage which loads the old beamerfontthememetropolis.m file and mark the option as deprecated right from the beginning. Then we focus on developing a new font theme structure using the Fira package. Is that a satisfying solution for everybody?

from mtheme.

@benjamin-weiss Actually, I was about to open a new issue suggesting we break beamerthemem.sty into an "inner theme" and "outer theme" similar to the structure of beamerthemedefault. The main theme file would then include the various sub-packages and forward options appropriately. This would allow users to apply the structural parts of the theme independently from the colour and font themes. This addresses the outstanding issue with #8, but would also apply here.

In this solution, we would maintain (for the time being) the old XeLaTeX-using font theme (probably renamed something like beamerfontthemexefira) and a new font theme using the bundle (beamerfontthemefira). We would then include the new font theme from the main theme. Users who want the old way could get it by calling

\useinnertheme{metropolis}
\useoutertheme{metropolis}
\usecolortheme{metropolis}
\usefonttheme{xefira}

individually instead of \usetheme. As a side benefit, users who want to use different fonts entirely could substitute their own font themes without worrying about conflicts from earlier font declarations.

from mtheme.

To further break down the theme makes definitely sense. Although I never really understood the decision they made in the beamer project to use "inner" and "outer themes". IMHO it would have definitely been enough to have one combined "structure theme". But to keep it compatible with the beamer theme structure we should definitely do it the same.

Nevertheless why not also implement a option:

\useinnertheme{metropolis}
\useoutertheme{metropolis}
\usecolortheme{metropolis}
\ifnofirapackage
  \usefonttheme{xefira}
  \PackageWarning{beamerthemem}{This option is deprecated and will be removed in the future.}
\else
  \usefonttheme{fira}
\fi

But either way, go for it. It is a good idea.

from mtheme.

\begin{irony}

There is finally the package we all have waited for. And we definitely have to support it in a additional font theme:
comicneue

\end{irony}

Why? Just Why? 😟

from mtheme.

I'm using OSX 10.9.5, MacTeX. When I use XeLaTeX to compile, errors occurring indicating that Fira fonts not found. But I check TeX Live Utility, fira is definitely installed there. Am I missing some steps here?
I know this problem is probably not related to mtheme, but my installation of the fira font. I check around and could not find a solution, so I try to raise this naive question here. Any input would be much appreciated!

from mtheme.

Because of several issues we decided not to use the fira package. See #143 for the discussion. So you have to install the font on your system to use it with the theme.

from mtheme.

I see. Thanks!

from mtheme.

I still have the same problem, even though the fonts are all installed (via font book and tex live utility and macports, etc.)

from mtheme.

Now that the Fira bundle has been updated, is it worth another look?

from mtheme.

Now that the Fira bundle has been updated, is it worth another look?

+1, and looking at changes in announcements it seems worth reconsidering, and seems active enough that any problems encountered will hopefully be addressed/discussed quickly.

I've moved to xelatex for now but this would still be a nice improvement and simplify things (as was original motivation for this issue AFAICT :)).

from mtheme.