Redefinition of skill and language bars to circles or squares within polycvsidebar
Opened this issue · 4 comments
Using the \renewcommand\cvlanguage[2]{\cvline{\levelbarsquares[0.7\linewidth]{#2}}{#1}} in the preamble is ignored by the progressbars within the polycvsidebar environment.
What did work was using this command within the sidebar, however this also badly affects the list's format in 2 ways:
- language on the right side and squares on the left
- general spacing (text and squares are not bound to the left and right side
I also did some experimenting by manually redefining \cvlanguage and \cvskill and got a similarly bad format (I currently can't find these modifications anymore)
Is there a way to redefine the language and skill commands for polycvsidebar as well while not keeping the original format?
Analysis
I have to admit this was nothing I anticipated. The circles and squares are late additions, and didn't make it to the final release of the sidebar. As such, the mechanism is (still) internal and needs to be overwritten explicitly. The culprit is in the following code:
polycv/source/latex/polycv.dtx
Lines 1989 to 1998 in 0d17e7d
To be honest, I don't exactly know how I came up with this form of template and why I used exactly these lengths. I guess it felt right at the time.
This is how the skill is defined and later used in the sidebar:
polycv/source/latex/polycv.dtx
Lines 2017 to 2022 in 0d17e7d
So you could indeed redefine these commands within the sidebar, since the original definition will be restored at the end:
polycv/source/latex/polycv.dtx
Lines 2035 to 2036 in 0d17e7d
Current Workarounds
This is not as straightforward as for the main body, because there is (currently) no accessible template for a single (skill) line. However, you can define it yourself to whatever you want with quite low-level commands. A very simple reimplementation would be:
\begin{polycvsidebar}%
% [...]
\renewcommand{\cvskill}[2]{%
\parbox{1.0\linewidth}{#1\hfill\levelbarsquares[0.4\linewidth]{#2}}%
}
% [...]
\end{polycvsidebar}
For long descriptions this might look odd and brake. More complicated and possibly a little bit more robust:
\begin{polycvsidebar}%
% [...]
\renewcommand{\cvskill}[2]{%
\parbox{0.6\linewidth}{#1}\hfill%
\parbox{0.3\linewidth}{%
\levelbarsquares[\linewidth]{#2}%
}%
}
% [...]
\end{polycvsidebar}
This would allow for different implementations of skill and language.
Alternatively, you can change the internal definition of the command that will be loaded automatically. This will simultaneously effect cvskill and cvlanguage. So keeping it close to the original definition, putting the following code into the preamble will change the progress indicator to circles:
\makeatletter
\renewcommand\polycv@sidebar@skill[3][\polycvhintcolsep]{%
\parbox{1.0\linewidth}{%
\hspace{#1}%
\parbox[b]{2\linewidth/3-4#1}{#2}%
\hspace{#1}\hfill%
\parbox[b]{\linewidth/3}{%
\levelbarcircles[\linewidth]{#3}%
}%
\vspace{0.2\baselineskip}}%
}
\makeatother
Further considerations and development
I guess the easiest to make this more customisable is to mirror what is happening in the main environment.
That probably means to define alternative templates for a skill line, which can be redefined and would be loaded automatically. Something like \cvsbskill and \cvsblanguage and a more generic version of a line. I have not yet made up my mind and ideas will be welcome.
Since these are not really breaking changes, but additions and internal redefinitions, I assume they can go into a v1.1.
The change is now live in the development version. This should be as easy as for the main body:
(The workaround line is carelessly left in from the previous attempt.)
polycv/examples/skill-redefinition-side/main.tex
Lines 29 to 32 in 59999d3
Please test this and let me know what you think.
This workaround is working fine. It does what it's supposed to do.
In the same style I also added \newcommand{\sidebarline}[1]{\sbline{#1}{}} neglecting the rating bars for lines in which they are not necessary or wanted (e.g. certificates, hobbies or whatever floats your boat).
This is already the new implementation, no longer a workaround (which was to redefine the internal commands).
I'm not sure, beyond what I have already tested, there is anything left to do. I guess I could escalate this to a release candidate status soon then.