Max Nikulin writes:
> On 17/10/2022 22:01, Juan Manuel Macías wrote:
>> \documentclass{article}
>> \usepackage{tabularray}
>
> LaTeX I have installed is too old for this package. It is marked as
> "Experimental LaTeX3", so I am unsure, maybe you have found a bug in
> this package.
> https://ctan.org/pkg/tabularray
As I said, I don't use this package. Once I wanted to start using it,
because it has many interesting features, but I gave up on it because
this package does not (at the moment) have support for the CMYK color
space (necessary for print publication) with the xcolors package.
Maybe it's a bug, but the situation is that compiling the copied
examples as they are in the package manual, the result is correct (as it
is also shown in the manual); but adding an unexpected element (an
\empty on the last line) produces a bad result. Since you can't test the
package, I've taken this screenshot:
https://i.imgur.com/jkSHUMP.png
I think there is a tabularray user on the list, Vikas Rawal. In fact, I
also remember that I provided a patch so that he could use this package
in Org
(https://list.orgmode.org/CALtzAB1yM+uG_xHghCxTLRX5mgbzNvT5+PO=duabb28ncsv...@mail.gmail.com/).
I've cc'd him in case he wants to join the discussion.
> You believe that an issue with brackets is extremely rare. It may be
> true for humanitarian texts. For some users it may be a constant
> source of pain e.g. in the case of interval notation as [a,b]. I have
> already mentioned tables generated by code blocks, not typed directly.
> I can not say that I often need to export my notes, but I was afraid
> that I will be bitten by this bug because I may try to put dates close
> to left margin:
>
> - Something\\
> [2022-10-17 Mon]
>
> By default dates wrapped into \textit, but it may be customized to
> just "%s".
>
> Selectively adding some workaround require complete reimplementation
> of exporters. I have some curiosity concerning pandoc approach, but I
> am unsure if I will reserve some time to read its code.
I see. If the selective solution is going to involve rewriting the
exporters, I find that it is unaffordable in the present circumstances.
It's a shame, because pandoc's solution seems ideal to me. What I
couldn't say is how pandoc does it and if it does it whenever expected,
because I use very little pandoc.
> I found \empty when I was looking for an approach with minimal
> overhead. I expect that e.g. \\[0pt] may have higher performance
> penalty since it is expanded to several commands. When the idea with
> "\\\relax" failed I was choosing between "\\{}" and "\\\empty". I
> decided that the latter minimizes risk to add spurious space.
Assuming that there is currently no alternative to the non-selective
solution, and that, as you say, the presence of brackets may be more
common than I initially expected, if I had to choose between \empty and
[0pt], I would say that [0pt] is the safest, as it is an expected
argument to \\ and equals the default space. I can't think of any
unexpected results from this, but of course, it also depends on there
being no package redefining \\ with another argument structure on its
own. I think it would be a bad idea for a package developer, but LaTeX
(and the LaTeX packages) is horribly unpredictable.
Best regards,
Juan Manuel
