sum of my PGF, SVG, XY patches

[xworld21]

This includes #2502 (better horizontal alignment, mostly for XY), #2488 (better overall alignment of foreignObject, with TikZ matrix improvements), #2477 (PGF baseline), #2401 #2490 (respect PGF bounding boxes), #2397 #2396 (add SVG viewBox in both PGF and XY).

I didn't add \pgfmathparse because, ahem, it fails badly.

Edit: the document I have been using as reference

\documentclass{article}
\usepackage[all,cmtip]{xypic}
\usepackage{tikz}
\usetikzlibrary{cd}
\newcommand\tikzname{Ti\emph{k}Z}
\begin{document}

\xymatrix{A \ar[d]^q \\ B }

\noindent Inline \Xy-matrix: $\xymatrix{
  A \ar[rd] \ar^\phi[r] & B \\
                        & C }$.

\xymatrix{
A \ar@{->>}[rd] \ar@{^{(}->}[r]
&B \ar@{.>}[d]
&C \ar@{_{(}->}[l]\ar@{->>}[ld]\\
&D}

\[
\xymatrix{
T \ar@/_/[ddr]_y \ar@/^/[drr]^x \ar@{.>}[dr]|-{(x,y)}\\
&X \times_Z Y \ar[d]^q \ar[r]_p & X\ar[d]_f \\
&Y \ar[r]^g &Z}
\]

\noindent Inline \tikzname-picture: \begin{tikzpicture}
  \draw (0.5,0.5) node {$2$};
  \draw (1.5,0.5) node {$+$};
  \draw (3,0.5) node {$3$};
  \draw (4.5,0.5) node {$=$};
  \draw (7,0.5) node {$5$};
  \draw (0,0) node [below] {$0$} -- (1,0) node [below] {$1$};
  \draw (1.5,0) node {$+$};
  \draw (2,0) node [below] {$0$} -- (3,0) node [below] {$1$} -- (4,0) node [below] {$2$};
  \draw (4.5,0) node {$=$};
  \draw (5,0) node [below] {$0$} -- (6,0) node [below] {$1$};
  \draw [dashed] (6,0) -- (7,0);
  \draw (7,0) node [below] {$2$} -- (8,0) node [below] {$3$} -- (9,0) node [below] {$4$};
  \foreach \x in {0,1,2,3,4,5,6,7,8,9} {
      \fill (\x,0) circle (0.05);
    }
\end{tikzpicture}

\noindent Inline \tikzname-cd: \begin{tikzcd}
A \arrow[r, "\phi"] \arrow[d, red]
& B \arrow[d, "\psi" red] \\
C \arrow[r, red, "\eta" blue]
& |[blue, rotate=-15]| D
\end{tikzcd}

\noindent Another one: \begin{tikzcd}
  A \arrow[r, "\phi\eta" near start, "\psi"', "\eta" near end] & {\hbox{\large B}}
\end{tikzcd}

\end{document}

[brucemiller]

Wow! Thanks! ! This is really very helpful to collect the (somewhat scary) batch of patches together to try out. I applied it to my collection of tikz & xy tests with interesting results! It's really gratifying that you were able to recover the viewport, without reintroducing the bad text positioning which was what drove me to disable it. In fact, in most cases, the text positioning is much improved! I wonder if this eventually could lead to clearing up the point vs pixel schizo that I introduced for the same (or similar) reason? (seems we should be able to generate XML with a single consistent unit; possibly rem?) FWIW: There're 2 situations where this patch is slightly worse than the current: Math nodes are often positioned very slightly high; and when multiple lines of text are present, the interline spacing is too small (whereas the current code is too large?). In general, it's definitely a net improvement. I'll want to study your patches, though...

[xworld21]

seems we should be able to generate XML with a single consistent unit; possibly rem?

rem would be great, especially if paired with adjusting NOMINAL_SIZE based on 10/11/12pt.

when multiple lines of text are present, the interline spacing is too small

Vertical alignment is still not quite perfect. There are two issues that I can formulate clearly:

• foreignObject should sometimes ignore the depth (e.g. for TikZ nodes, which are anchored at their geometric centre). For now I opted for keeping the baselines in check, because that seems less unpleasant. I don't know if the 'right' way is to make foreignObject react on context (but how?), or whether depth alignment should be done by the context (e.g. patching \hbox in PGF).
• multiline text clashes with line-height:$height badly, and yet that's the only way to position stuff by baseline in CSS. When this is coming from \hbox, I suggest disabling word wrapping (actually \hbox should always disable word wrapping, but I digress). For vertical boxes, I haven't thought about it! Resetting to line-height:normal or line-height:$baselineskip would certainly mitigate the issue.

Then there's still something off with Alignment and depths and XY which I just don't get at the moment, and I am sure tons of other situations I haven't considered...

[brucemiller]

@xworld21 Where do we stand with this? You've marked this as a Draft, suggesting you had more in mind?

I have, I guess, three concerns:

• You use flex for foreignObject which seems a bit exotic, and complex figures have lots of them. It would seem that theoretically a foreign object should be a simple matter of "draw this here", and we should know where "here" is, but of course we don't really.
• In many cases, the math is positioned a bit high; is this related to the above?
• Most noticeable is the lack of interline spacing with lines of text.

Since I've sadly allowed quite a backlog of tikz patches to accumulate, till it's hard to even know where to start, I'm inclined to accept this PR as it is, and then work on fixing the above issues, as well as looking into the other PRs. To my eye, the improvements here outweigh the regressions. (of course, some may be disturbed by that last point above)

OR, would it be better for me to view this PR as motivation, and simply work through the PRs you've listed above and (presumably) merge each?

[xworld21]

OR, would it be better for me to view this PR as motivation, and simply work through the PRs you've listed above and (presumably) merge each?

Yes, that was my intention – this PR is just mashing together the other ones to show the end result.

I think the PRs that do not touch foreignObject are fairly small and should be easy to review and merge as they are. If you can get viewBox in, then the orcidlinks binding should be good to go as well, by the way.

But foreignObject is still not quite fully baked. Replying to your comments:

• flex is not so exotic from the HTML point of view: I want to vertically centre the content of the foreignObject, and that you do via flex, otherwise 'here' is all about the top left corner which responds poorly to the browser sizing things differently
• depths & interline issues are symptoms of the same problem: to align the baselines, I am tinkering with line-height; the 'correct' solution is probably to reset line-height: \baselinestretch within inline-block, but there are silly CSS specificity issues with nested SVGs which I have yet to think through, and #2513 prevents me from producing simple examples for testing
• yeah, I am not sure what's going on with the maths, could that be about that extra 2.5pt depth that pops up sometimes?

I'll look at this during the weekend. I guess if I can adjust line-height in a sensible way, and also disable text wrapping in the right places (i.e. only in 'horizontal' mode, and again reset it in inline-block), that could be a better starting point for fixing up the details later.

Oh, and let's not forget that part of the issue is that foreignObject should somehow know the desired anchor, e.g. whether it's baseline or centre. But that's definitely something that can be improved later since it should be just a handful of pixels.

PS: and there's the new CSS text-trim stuff that will change all of this, again! Something for 2027 though.

[brucemiller]

Cool! Thanks for the feedback. I'll use this PR as a sorta roadmap, and start working through the patches; likely push #2488, and maybe #2477, off till last, in case other alternatives pop up.

[brucemiller]

This PR has served as a wonderful attention focus and motivator, and is greatly appreciated! I believe that all (or most?) of the issues & sub-PRs have been addressed, and hopefully closed as appropriate. If so, can we close this meta-PR as well? Or if there still remain outstanding issues, can we either close and open a new, hopefully smaller, issue/PR, or alternatively rebase this one to reveal what remains to be done? Thanks!!

[xworld21]

If so, can we close this meta-PR as well?

Yes! Massive thanks for all the work you have done to act on all of this. 0.8.9 will be an exciting release.