@UlrikeFischer any chance ngerman can at least get a warning added that it probably shouldn't be used?

@DavidCarlisle perhaps. You could try the mail.

I thought you may know Bernd from dante meetings:-)

@DavidCarlisle ooh

@PauloCereda Natürlich könnte ich ihnen auf Deutsch schreiben

@DavidCarlisle ooh

@DavidCarlisle I think I meant him once in Passau, but I'm not completly sure.

@samcarter /poke

@PauloCereda <3

Any idea how to get forward search in tex.stackexchange.com/a/631681/250119 to work? The LuaTeX documentation is a little sparse.

Shouldn't a newspaper be able to come up with a better design for their website than subtitles in tiny dark red font on dark blue background?

Please, am I right that \includegraphics in pdflatex doesn't read the Orientation EXIF? @DavidCarlisle

@yo' pdftex gives no access to the exif information as information although exactly what it uses internally to decide what the resolution and orientation are are not over documented and I forget the details:-)

@DavidCarlisle ok, just making sure that wrong orientation of photos from cellphones is a thing (asking for a user)

@DavidCarlisle @JosephWright I get currently warnings on the latex+dvips route as soon as I use an example-image from the mwe package. They disappear if one load the pstricks package as its .pro file contains a definition for .setopacityalpha. Should one add that to the backend too?

**** WARNING: .setopacityalpha is deprecated (as of 9.53.0) and will be removed in a future release
   **** See .setfillconstantalpha/.setalphaisshape for the improved solution


\documentclass{article}
\usepackage{graphicx}
%\usepackage{pstricks}
\begin{document}
\includegraphics{example-image}
\end{document}

@UlrikeFischer The image presumably needs fixing

@UlrikeFischer Warning seems clear to me: it's a use of deprecated functionality

@UlrikeFischer agree with @JosephWright we should get example-image.eps fixed

It says it's made by %DVIPSCommandLine: dvips -q -o example-image.ps example-image.dvi does it still have that if we re-create it, if so the dvips header needs fixing...

@JosephWright yes I know. But one can define the function in terms of the new functions (that is what pstricks does). That seems easier than trying to fix all the eps lying around still using the older function. I mean even if we can fix example-image, there are probably more around aren't there?

@UlrikeFischer Yes, that's all true but then we are essentially encouraging people not to update their image files, and the whole opacity business has security links, so that's not the usual 'we want stability' business

@UlrikeFischer The image still works, no?

@DavidCarlisle it is still there. And the code uses pgf so I don't think it is the dvips header but pgfsys-dvips.def that would need fixing.

@JosephWright but if we overwrite a deprecated function with a wrapper around the newer, safer function than we make it safer don't we?

@UlrikeFischer Possibly, but we don't get the user to update the image, and that's what they really need to do. Perhaps one for the team list, but honestly I really feel we should respect the views of the GhostScript people here

@JosephWright @UlrikeFischer my head hurts fancy debugging some file option handling? :-)

\documentclass[11pt]{book}

\usepackage{indentfirst} % Slightly tweak font spacing for aesthetics

%\tracingall
\usepackage[activate={}]{indentfirst}

\begin{document}

\end{document}

@JosephWright then I would say the first thing to do is to push pgf to adapt its driver. It is the source.

@UlrikeFischer Talk to @HenriMenke

@DavidCarlisle where is it from?

@UlrikeFischer me mostly after somewhat agressively pruning the example from

@DavidCarlisle \in@ not liking the {} and leaving a trailing ,?

~.............\in@ #1#2->\begingroup \def \in@@ ##1#1{}\toks@ \expandafter {\in
@@ #2{}{}#1}\edef \in@@ {\the \toks@ }\expandafter \endgroup \ifx \in@@ \@empty
 \in@false \else \in@true \fi
#1<-,activate={},
#2<-,,
{\begingroup}
{entering semi simple group (level 1) at line 7}
{\def}
{changing \in@@=undefined}
{into \in@@=macro:#1,activate=->}
{the character ,}
\everypar->\g__para_standard_everypar_tl

@JosephWright yes I hate \in@ but I thought we'd arranged to make it safe enough at least so it avoids error and packages can use the raw lists for kv handling, if it dies before the package called that doesn't help

@DavidCarlisle \@if@pti@ns

@JosephWright im off work this week as I can't concentrate beyond two-@ macros

@DavidCarlisle :)

@DavidCarlisle @@h

@PauloCereda d@nn@r

@DavidCarlisle oh no

@DavidCarlisle It's the option-clash code: I guess we could make it a straight string comparison?

@JosephWright yes I was thinking we need to get braver and detokenize somewhere, but really didn't feel up to tracing

@DavidCarlisle Just don't worry, tell people to use \DeclareKeyOption and leave it at that?

@DavidCarlisle The only way we can test with braces, other than doing keyval, but I'm serious: really just use \ProcessKeyOptions, pass the work to the new handler, job done

@DavidCarlisle This must have come up before?

@JosephWright there are a lot of existing packages, although on the other hand I haven't seen this come up much before so presumably not many people are using clashing options with {} in such a package so perhaps you are right and we can ignore

@DavidCarlisle I guess what I mean is that the any fix isn't risk-free, and that given the lack of reports of the issue, we are better pointing to the new mechanism as that doesn't risk breaking existing working docs

@DavidCarlisle We should though log the problem: there may be a solution, but at the moment I can only imagine a \detokenize one which could have it's own issues

@JosephWright yes, agreed I think. Especially here as it's just the option clash stuff anyway, I could add an issue later

@DavidCarlisle Yes, docs are already failing under these circumstances

@JosephWright although it also fails in the non-clash case:

\documentclass[11pt]{book}

\usepackage[activate={}]{microtype}
\usepackage[activate={}]{microtype}

\begin{document}

\end{document}

@DavidCarlisle Yes but isn't this all in the end the fundamental issue that the original options mechanism simply doesn't expect keyvals?

@JosephWright yes we could document it as a feature but it's not really documentable as an end user won't typically know what option handler a package is using, so random internal failures if you repeat a call rather than it being silently ignored is historically defendable but not exactly great

@DavidCarlisle Looking at the code, I suspect we could use a string test - that should be safe here as we'd only detokenize in the test itself

@JosephWright yes that would be the idea

@JosephWright tex.stackexchange.com/questions/631781/…

\makeatletter
\ExplSyntaxOn
\cs_set_eq:NN \str@if@eq@eeT \str_if_eq:eeT
\ExplSyntaxOff
\long\def\@if@pti@ns#1#2{%
  \let \reserved@a \@firstoftwo
  \edef\reserved@b{\zap@space#2 \@empty}%
  \ifx\reserved@b\@empty\else
    \str@if@eq@eeT{\detokenize{,#1,}}{,\detokenize\expandafter{\reserved@b},}{\let \reserved@a \@secondoftwo}%
  \fi
  \reserved@a
}
\makeatother

@DavidCarlisle ^^^

@DavidCarlisle I went for minimal changes

@JosephWright thanks looks about right I'll see if I can break it later....:-)

@DavidCarlisle What I've not checked is whether we need to allow for different clist orderings: I presume this comes up somewhere?

@DavidCarlisle I suspect we still need the \@for loop, but detokenizing the individual entries

@JosephWright ah I was just writing that ordering shouldn't matter as each option checked individually, (or at least it should be) but see skype

\ExplSyntaxOn
\cs_set_eq:NN \str@if@eq@eeT \str_if_eq:eeT
\ExplSyntaxOff
\long\def\@if@pti@ns#1#2{%
  \let \reserved@a \@firstoftwo
  \edef\reserved@b{\zap@space#2 \@empty}%
  \@for \reserved@b :=\reserved@b \do {%
    \ifx \reserved@b \@empty
    \else
      \str@if@eq@eeT{\detokenize{,#1,}}{\detokenize\expandafter{\expandafter,\reserved@b,}}%
        {\let \reserved@a \@secondoftwo}%
    \fi
  }%
  \reserved@a
}
\makeatother

@DavidCarlisle Id' forgotten to check each option: I've backed up to a smaller change

@DavidCarlisle I think I still need a bit more work, as I'm testing all of #1: work to do, might revisit later

Friday woo

@JosephWright Do you want to keep github.com/josephwright/beamer/issues/275 open? I can't reproduce the issue anymore.

@ JosephWright thx!

Mac users: do you know if Homebrew requires Xcode command line tools to be installed first? I need to help a friend get pandoc running and that seems like the simplest option but I want to have the facts straight. @PauloCereda @egreg @JosephWright

@AlanMunn hmmm sadly I don't remember if it's required even for packages distributed in binary form (it would make sense for packages distributed in source)...

Someone on the internet said, You won’t need Xcode to use Homebrew, but some of the software and components you’ll want to install will rely on Xcode’s Command Line Tools package. So I gathered, it depends if pandoc + dependencies are binary-only or if something is built on the fly during the installation.

If the machine runs a fairly new MacOS, I'd say there will be binaries. Otherwise, welcome to +4h of homebrew update due to building everything from source. :)

@PauloCereda Yes, that seems to be my understanding from the docs, although it's not entirely clear. And I've had Xcode my machines forever as a matter of course, so don't know what's being used an what's not. So to be safe it's probably best to install the tools first. But Xcode is a monster install, I think.

@AlanMunn It's been a while, but I think the command line tools used to be a separated DMG, around 100MB... Installing Xcode is indeed huge, it's +6GB unpacked IIRC.

@AlanMunn let me check the developer portal, just a sec

@AlanMunn Command Line Tools for Xcode 13.2.dmg || 564.48 MB

At least it's not the insane monster install...

But it's a lot...

developer.apple.com/download/more (you need to log in)

@PauloCereda Thanks! I'll get it that way and then just share the DMG with my friend.

@PauloCereda It's kind of crazy that it's not available in the App store separately

@PauloCereda There are so many versions. I guess I should just have them use the last release version?

@PauloCereda I realize that's basically what you already recommended. :)

@JosephWright I tried to follow the thread and understand the issue but couldn't figure it out. Is this about the deprecated transparency options in Ghostscript? If yes, that should be fixed since github.com/pgf-tikz/pgf/pull/907

@PauloCereda 6GB? I wish!

(and that's not including several more GB of simulation files for operating systems like ios, watchos and appletv, which I will never ever program for)

@HenriMenke I think this is unrelated. The current issue is about the use of .setopacityalpha in the dvips driver. ghostscript has deprecated that and at least on windows I start to get warnings about it.

@HenriMenke but I will check if I can make an example. Perhaps it is really fixed.

@UlrikeFischer You're right, that is unrelated. But the fix for setopacityalpha also has been committed into PGF for quite some time: github.com/pgf-tikz/pgf/pull/890

@UlrikeFischer Since 3.1.6 to be precise.

@HenriMenke I was obviously a bit too fast in the afternoon, I only checked if the operator is still there and not what it actually does. So you are doing the same as pstricks: you offer it as fallback with another definition. So if the example images are recompiled they will probably work. @JosephWright @DavidCarlisle

In other words: Is the functionality of \mathcolor a superset of the functionality of \textcolor?

@UlrichDiez yes it doesn't work well in text and we will probably make it error just as \mathrm`gives an error if used outside math

@UlrichDiez @UlrichDiez try a \mathcolor{b} c in text compared to the same with \textcolor

@UlrichDiez you lose the space after it as it is looking ahaed for subscripts, you could detect math mode and not do that but having separate commands for text and math is more the tex style

@UlrichDiez sorry I meant a \mathcolor{red}{b} c

@DavidCarlisle I am the one who has to say sorry because I am the one who overlooked the space after {b}. :-) Many thanks for clarification.