Restructure pgfplot theme

matze commented 8 years ago

As a follow-up to #171, we should restructure the pgfplots styles and decouple color from structural properties.

rchurchley commented 8 years ago

As a bit of a radical suggestion: should we remove the pgfplots theme from the ᴍᴇᴛʀᴏᴘᴏʟɪs project and release it as its own separate package? The Tol color theme is a great way to make readable charts with pgfplots, but at this point it's almost entirely independent from the ᴍᴇᴛʀᴏᴘᴏʟɪs beamer theme. I wonder if it would be better served by having its own repository.

Proposal

Add a warning to pgfplotsthemetol for the v1.1 release of ᴍᴇᴛʀᴏᴘᴏʟɪs, indicating that it would be removed in a future version and need to be installed separately.
Update beamerthememetropolis.sty to load pgfplotsthemetol only if it is installed on the user's system.
Freeze development of the version of pgfplotstheme.sty included in the ᴍᴇᴛʀᴏᴘᴏʟɪs bundle.
Create the new GitHub repository matze/pgfplotstheme-tol.
Continue development on pgfplotsthemetol in the new repository.
Have @matze release pgfplotsthemetol as its own separate package on CTAN when the new version is ready.
At the same time, release a v2.0 version of ᴍᴇᴛʀᴏᴘᴏʟɪs on CTAN which removes pgfplotsthemetol.sty from the bundle.

Advantages

The PGFPlots theme does not depend at all on Beamer and can be used to style charts in articles, books, etc. Releasing pgfplotsthemetol as its own package helps communicate this fact, and makes it more visible to users who want a package for this use case.
A separate manual for pgfplotsthemetol would be more useful for all users, especially those who want to use pgfplotsthemetol in non-Beamer documents.
Creating a new repository gives pgfplotsthemetol support requests its own issue tracker, which helps ᴍᴇᴛʀᴏᴘᴏʟɪs development stay organized.
It makes sense philosophically to spin off the PGFPlots theme into its own project. Its code is entirely independent from the other parts of the bundle, and we seem to be developing it separately anyways.

Possible disadvantages

If we're not careful, spinning off the PGFPlots theme is likely to cause versioning problems for people who install the theme without upgrading their version of ᴍᴇᴛʀᴏᴘᴏʟɪs, causing them to have two different versions of the package installed in their TeX path. This could be mitigated by adding a warning about the issue in the new pgfplotsthemetol manual and repository README.

matze commented 8 years ago

As a bit of a radical suggestion: should we remove the pgfplots theme from the ᴍᴇᴛʀᴏᴘᴏʟɪs project and release it as its own separate package?

I like this idea and in fact that was a thought I had some time already, exactly because of all the advantages outlined. The proposal for a course of action looks very reasonable to me, although I am not entirely sure if we should stick with Paul Tol's last name as the package/repository name. Not for personal reasons but because there are other alternative color schemes with equally good properties. Ideally, renaming should also mitigate the versioning problem since we never made the pgfplots styles and color theme part of our public "API".

benjamin-weiss commented 8 years ago

I am not entirely sure if we should stick with Paul Tol's last name as the package/repository name. Not for personal reasons but because there are other alternative color schemes with equally good properties.

Fyi, viridis is – as of version 1.13 – part of pgfplots itself.

Concerning the Paul Tol's color theme: I already started some time ago to put it into an independent package. Have a look at it here. And there were also plans to integrate it into pgfplots itself. Stefan Pinnow contacted me via email prior to the 1.13 release for that reason. Unfortunately I didn't really had time to work on it and totally forgot at some point to answer to is his last emails (shame on me). So it didn't make it into the 1.13 release. But I still think it would be a good idea to make Paul Tol's colors a part of pgfplots itself.

matze commented 8 years ago

Fyi, viridis is – as of version 1.13 – part of pgfplots itself.

The curse of my outdated TeXlive …

Anyway, let's suppose Paul Tol's colors become part of pgfplots, all left would be a .sty with nicer looking pre-defined styles for different plotting purposes?

benjamin-weiss commented 8 years ago

Right, if we suppose Paul Tol's colors become part of pgfplots, a separate package wouldn't make much sense in my opinion.

rodrigoalcarazdelaosa commented 8 years ago

Regarding the current implementation of Paul Tol's colors, the mlineplot style is intended for line charts with up to 4 series, although it still uses the 12-color palette. It would be better if the style could choose appropriate colors depending on the number of series (according to Figure 3 in Paul Tol's technical note). Is this even posible? I also agree that the best place for Paul Tol's colors is pgfplots itself.

benjamin-weiss commented 8 years ago

I think a fully automated implementation is not really possible, as the total number of plots within an axis is not known. pgfplots simply takes the next color in a cycle when a new plot is added. But it is possible to define multiple cycle list for the different series like I did in my independent package and add the series number to its name.

So for series 2 you use palette1cycle2:

\begin{tikzpicture}
  \begin{axis}[
    cycle list name=palette1cycle2,
  \addplot {1x};
  \addplot {2x};
  \end{axis}
\end{tikzpicture}

and for series 4 you use palette1cycle4:

\begin{tikzpicture}
  \begin{axis}[
    cycle list name=palette1cycle4,
  \addplot {1x};
  \addplot {2x};
  \addplot {3x};
  \addplot {4x};
  \end{axis}
\end{tikzpicture}

matze / mtheme