Covering material - methods and spacing

[josephwright]

In beamer, Till arranges for material to be 'invisible' by moving it well off screen. For \uncover, he provides a methods to have partial visibility based on colour mixing. In both cases, to deal with the oddities of spacing with whatsits, there are various gymnastics for the case where things are not covered/invisible.

An upcoming release of expl3 will integrate l3opacity into the kernel, and this offers real opacity support for all of the supported backends. I think this gives us an opportunity to take a fresh look at this area.

My suggestion is that rather than do any canvas moves, we always use opacity to arrange for material to vanish - it's then just a question of the degree of opacity that's active. I also suggest that we don't worry about spacing: not because it's not an issue, but because I think we should push to have both colour and opacity handled in LuaTeX as attributes out of the box in expl3. That will deal with the spacing with no additional gymnastics, and would give a simple piece of advice in the manual: 'Use LuaTeX'. (We know that for tagging, etc., LuaTeX is strongly preferred anyway - and here we are dealing with documents that have to be updated even if they are not 'new'.)

I think on the timeframe of a 'stable' xbeamer release that is workable, and fits with other ideas I'm trying to explore (e.g. doing colour using l3color rather than color - but I think a move to attributes will apply to color as well).

Thoughts?

[josephwright]

One thing to note here is using opacity, any covered text is still selectable as it's in the 'right' place - I'm thinking overall that's not such a bad thing.

[Qrrbrbirlbel]

Interesting, that was my argument against the aobs style of just setting TikZ's opacity to zero for hiding an element. (That and that the dynamic color mixin for \uncover is not possible then.) The amount of people who are going to select a slide they have up on the wall is probably small but still …

Keeping my TikZ head on:
Can we “mixin”/stack opacity? If (x)beamer requests an opacity of 0 because an element should not be visible but the element itself sets its own opacity it should remain zero. If (x)beamer requestions an opacity of 0.15 and the element itself requests opacity 0.5 we should land on 0.075. It would be great if we have a way to explicitly get the level of opacity beamer would apply given an overlay specification.

I'm interested in this topic because I'm currently playing around with a TikZ library for beamer to allow for more than just setting opacity to zero.

[josephwright]

Interesting, that was my argument against the aobs style of just setting TikZ's opacity to zero for hiding an element.

I guess I'm looking at this very much from a tagging POV, where when we say convert to HTML, visual hiding doesn't 'work'. So the text is still 'there' - unless we go for a LuaTeX solution and remove entirely after the box is set.

Keeping my TikZ head on: Can we “mixin”/stack opacity? If (x)beamer requests an opacity of 0 because an element should not be visible but the element itself sets its own opacity it should remain zero. If (x)beamer requestions an opacity of 0.15 and the element itself requests opacity 0.5 we should land on 0.075. It would be great if we have a way to explicitly get the level of opacity beamer would apply given an overlay specification.

Currently no but adding a relative opacity function is pretty trivial - it's just a question of making sure that everything uses the same mechanism (or at least reads/updates the same data). Unlike colour, I don't think 'expressions' are needed/sensible, so it would mean adding some \opacity_relative:n function.

I am keen if possible to avoid what beamer does to do fake-opacity - there's a lot of code in \uncover that becomes a lot less complicated if you use the backend to do the hard work.

[josephwright]

Worth noting that with the opacity plan, something like

\documentclass{beamer}
\setbeamercovered{transparent = 50}
\begin{document}
\begin{frame}
  \begin{itemize}[<+->]
    \item Text \includegraphics[width = 2em]{example-image-a}
    \item Text \includegraphics[width = 2em]{example-image-b}
  \end{itemize}
\end{frame}
\end{document}

would work 'properly'

\DocumentMetadata{tagging = on}
\documentclass{xbeamer}
\usepackage{graphicx}
\usepackage{l3opacity}
\ExplSyntaxOn
\cs_gset_protected:Npn \__xbeamer_item_parse_spec:n #1
  {
    \__xbeamer_overlay:nF {#1}
      {
        \tl_gset:Nn \g__xbeamer_list_end_tl
          {
            \opacity_select:n { 1.00 }
            \tl_gclear:N \g__xbeamer_list_end_tl
          }
        \opacity_select:n { 0.50 }
      }
  }
\ExplSyntaxOff

\begin{document}
\begin{frame}
  \begin{itemize}[<+->]
    \item Text \includegraphics[width = 2em]{example-image-a}
    \item Text \includegraphics[width = 2em]{example-image-b}
  \end{itemize}
\end{frame}
\end{document}

(Proper interface to be added this week I hope.)

[cfr42]

Currently no but adding a relative opacity function is pretty trivial - it's just a question of making sure that everything uses the same mechanism (or at least reads/updates the same data). Unlike colour, I don't think 'expressions' are needed/sensible, so it would mean adding some \opacity_relative:n function.

Some tikz code uses colour-like syntax to create fadings. This doesn't work properly in all cases, because viewers vary in support, but there are some core-ish uses. Just wondering how/if that would work in combination with this.

The idea of treating transparency/opacity as colours for expression purposes may not be necessary, but it is quite nice. It has obvious analogues in GUI editors such as GIMP, for example, where you can add transparency effects by editing a greyscale layer and adding it as a mask. The fading-from-picture stuff in tikz is similar.

[But I'm not sure I've understood what you have said.]

[josephwright]

On expressions, I mean that for colour something like blue!20!red is useful as there is an open-ended list of colours you can mix, but for opacity you have only either an absolute or relative value. So \transparency(*) can cover it all.

On integration with other packages - we need to look at that anyway to deal properly with moving PDF management to the kernel.

[samcarter]

Will this work for non-text material, e.g. raster images?

[josephwright]

Yup - it applies to everything:

\DocumentMetadata{tagging = on}
\documentclass{article}
\usepackage{graphicx}
\usepackage{l3opacity}
\ExplSyntaxOn
\cs_new_eq:NN \opacity \opacity_select:n
\ExplSyntaxOff
\begin{document}

Hello

\begingroup
  \opacity{1}
  \includegraphics[width =  2em]{example-image-a.png}
\endgroup

Hello

\begingroup
  \opacity{0}
  \includegraphics[width =  2em]{example-image-a.png}
\endgroup

Hello

\end{document}

[samcarter]

Nice!

[josephwright]

See also #36 (reply in thread) :)

[samcarter]

This sounds very convenient to use!

[u-fischer]

I quite agree that opacity should be used. Regarding tagging, invisible stuff can/should probably be tagged as artifact. I'm quite sure how to handle covered text, there are arguments for both ...

[josephwright]

Anyone other than me been testing this? Seems to work fine, but I will need to add a note to the docs for dvips users I think.

[josephwright]

I was reading the PDF ref. last night and was reminded we've not talked about Optional Content Groups (OGCs) for slides. The ref. explicitly points to these for things like a point-by-point reveal for a list.

I can see how OGCs might work for simple cases, but they look tricky for \only and also for the case where material is transparent not entirely invisible. So at present I simply want to log that we may wish to look again at this once we have a working setup for a decent number of users.