| 6 Oct 2021 |
 josephwright | hmenke: Seems I got it from https://tex.stackexchange.com/questions/420645/tikzpicture-has-different-outputs-depending-on-the-tex-engine | 07:26:31 |
 hmenke | josephwright: Oh no. | 08:56:03 |
| hmenke | Don't remind me of the xetex driver. | 08:56:12 |
| josephwright | In reply to @hmenke:matrix.org
Don't remind me of the xetex driver. The l3draw one works ;) | 08:56:29 |
| hmenke | The xdvipdfmx driver in PGF is completely fucked. | 08:56:39 |
| josephwright | In reply to @hmenke:matrix.org
The xdvipdfmx driver in PGF is completely fucked. Yes, I know there are major issues: I worked basically from scratch to get the l3draw stuff to go | 08:57:02 |
| hmenke | You also correctly implemented box_use: https://github.com/latex3/latex3/blob/335222608bea9fad19bb89b32d11d1014e40ab7e/l3backend/l3backend-draw.dtx#L349-L386 | 08:59:31 |
| hmenke | The implementation in the xdvipdfmx and dvips drivers of PGF are wrong which is essentially what breaks most uses of nested tikzpictures. | 09:00:06 |
| hmenke | But without a comprehensive test suite I don't feel comfortable touching these drivers. | 09:01:53 |
| josephwright | In reply to @hmenke:matrix.org
You also correctly implemented box_use: https://github.com/latex3/latex3/blob/335222608bea9fad19bb89b32d11d1014e40ab7e/l3backend/l3backend-draw.dtx#L349-L386 That was quite a lot of effort testing all of the interactions! | 09:02:05 |
| josephwright | In reply to @hmenke:matrix.org
The implementation in the xdvipdfmx and dvips drivers of PGF are wrong which is essentially what breaks most uses of nested tikzpictures. Tom Rokici gets the credit for the dvips approach: I asked him for help | 09:02:42 |
| josephwright | In reply to @hmenke:matrix.org
But without a comprehensive test suite I don't feel comfortable touching these drivers. I completely understand | 09:02:51 |
| josephwright | In reply to @hmenke:matrix.org
But without a comprehensive test suite I don't feel comfortable touching these drivers. So we need to get that sorted? This rooms seems an ideal place to organise: a case of taking the l3draw tests as a base perhaps? The API is pretty similar | 10:13:00 |
| hmenke | Yes, this needs to get sorted and any help is much appreciated. | 10:15:23 |
| hmenke | I'm not familiar with l3build at all. | 10:15:36 |
| hmenke | I tried to adapt Ulrike's pdfresources scripts because they cover a wide variety of engine but I always hit a wall because at some point l3build expects the LaTeX dtx+ins workflow which PGF doesn't have. | 10:17:18 |
| hmenke | Then again, this was a year ago, so things likely have changed. | 10:17:51 |
| josephwright | In reply to @hmenke:matrix.org
I tried to adapt Ulrike's pdfresources scripts because they cover a wide variety of engine but I always hit a wall because at some point l3build expects the LaTeX dtx+ins workflow which PGF doesn't have. OK, so if I set up a framework and say one or two demo tests? | 10:17:56 |
| hmenke | That would be like 80% of the work. | 10:18:35 |
| hmenke | Most importantly the framework has to cover all supported engines. | 10:18:58 |
| josephwright | OK, I'll see what I can do over the next few days - I do know l3draw and l3build quite well ;) | 10:19:18 |
| hmenke | We need pvt->tpf tests for driver stuff and lvt->tlg tests for engine-independent stuff like pgfkeys and pgfmath. | 10:20:11 |
| josephwright | In reply to @hmenke:matrix.org
We need pvt->tpf tests for driver stuff and lvt->tlg tests for engine-independent stuff like pgfkeys and pgfmath. Well I can start small, also note that most of the time one can test using \showoutput (that's how I do l3draw, with one result per backend) | 10:22:05 |
| hmenke | Yes, \showoutput could suffice, but for patterns and other global objects we need the entire PDF. | 10:23:29 |
| hmenke | Also, doesn't \showoutput truncate long \specials? | 10:23:53 |
| josephwright | In reply to @hmenke:matrix.org
Also, doesn't \showoutput truncate long \specials? One can fiddle with line length to address that | 10:24:20 |
| josephwright | In reply to @hmenke:matrix.org
Yes, \showoutput could suffice, but for patterns and other global objects we need the entire PDF. Possibly: should still be in the first PDF page though - I'd have to check | 10:24:42 |
| josephwright | In reply to @hmenke:matrix.org
Also, doesn't \showoutput truncate long \specials? I guess the issue there is pgf writes very few lines, whereas for l3draw I've tried to keep each \special independent | 10:26:00 |
| hmenke | There is actually a related thing that I wanted to discuss with the L3 team at some point (probably at a future TUG/Dante/etc meeting): More and more expl3 constructs are infiltrating the LaTeX kernel which is a good thing, since they bring new robust features, but the big downside is that \tracingall becomes more and more useless because expl3 produces lots of log spam. For most users this is a non-issue but developers will have a hard time tracking down bugs. We don't have to (and probably shouldn't) discuss this now; just something to keep in mind. | 10:28:16 |
| hmenke | In reply to @josephwright:matrix.org
I guess the issue there is pgf writes very few lines, whereas for l3draw I've tried to keep each \special independent I don't know for sure whether PGF does generate very long specials. | 10:29:02 |
