@PabloGonzálezL (@DavidCarlisle) I've raised the texdoc business on the TL list

@JosephWright As for the bounding box setting command for l3draw, it seems that metapost and PGF have a different approach: metapost has a special command for creating a rectangle explicitly while PGF seems to provide use as bounding box as option similary to clip, draw, fill etc. While the former is a more straight-forward approach in my opinion (a bounding box is a rectangle), the latter is interesting as you can create a bounding box around whatever path ...

@JasperHabicht I was thinking somewhat hybrid: a dedicated command but using a path ...

@JosephWright Yes, I think using a path is nice. In the end, the bounding box is always created fitting a path, right? So ... maybe a hybrid solution might be a good idea

@JasperHabicht Yup, bb fits the path

@JosephWright Currently you can use \l_draw_bb_update_bool to switch on and off whether the following path will update the box, right? That's about it ...

Well, I leave it to you as I am not that much into the question which programming level you are using (and I don't even know that well which drawing commands would belong to which level) =)

@JasperHabicht Yup

@JasperHabicht I'll perhaps look at this over lunch

@JasperHabicht In metapost boundingbox p will give the boundingbox for the path p. Maybe I misunderstand you.

@mickep Oh, so there is a similar command as well. I thought that I found another command that sets the corners of a rectangle or so, maybe I am mistaken

@mickep You are right! I am wrong. I was refering to setbounds ⟨picture variable⟩ to ⟨path expression⟩.

Clearly, it takes a path expression ... sorry

@JasperHabicht Ah, yes, that is to set it explicitly for the picture (currentpicture if one wants to set it to... well... current picture).

@mickep Yup. Now that I again look in to the manual I wonder how I could misunderstand this =)

@JasperHabicht Oh, no worries.

But then, l3draw should really implement this in a similar way, I think

So, Joseph's approach seems to be great!

@JasperHabicht OK, very good!

@mickep, @JasperHabicht Something like \draw_path_set_bb:? 'Sets the bounding box of the drawing to contain the path, ignoring any existing content and discarding the path'

@JosephWright I'm not familiar with this, but does it also draw the path? Or is the draw in the beginning something common to all those macros?

(Listen to @JasperHabicht who actually uses this..) :)

@JosephWright Yes, I also thought of such an implementation. It should not draw the path. \draw_path_set_bb: or \draw_path_bb_set: (because \l_draw_bb_update_bool)?

@mickep No, the \draw_ part is the name of the module

@JosephWright Right, it should ignore previously drawn paths, but of course later drawn paths would again affect the bbox ...

I think others should probably also give their input =D Maybe David, since he has a golden TikZ badge ...

@JasperHabicht and more importantly: he knows how the bounding box is set in picture mode.

@UlrikeFischer Right! Something we completely ignored up to now ...

@mickep I was thinking a command that explicitly does not draw a path, but only uses it to set the bounding box

@JasperHabicht Yes, that's logical

@UlrikeFischer :)

@JosephWright That is what I thought. It is a bit confusing (when one is not used to this) that it starts with \draw.

@mickep The module is called l3draw, so everything starts \draw_...

@mickep It is okay, since (almost) everything starts with \draw and most commands don't really output anything

@JosephWright I get that.

@mickep That's also why the index of the doc has only three sections: "Symbols", "D" and "G" =D

@JasperHabicht Haha

@mickep And "Symbols" and "G" only contain three entries ...

@JasperHabicht Could perhaps be \draw_bb_from_path:n? Then you'd give the path construct as an argument

@JosephWright Let me check, is there a naming logic in the package?

@JasperHabicht Broadly, yes: I followed pgf, which nicely divides up stuff - if you look at the sources, you'll see for example that \draw_path_... all come from one file

@JosephWright I see. Yes, that's a good idea. So, it starts ffrom the bigger concept. Then, it should start with \draw_bb_... and maybe from_path is not bad. or use_path? But use means: put into output stream / typeset, so might be not a good choice.

@JosephWright Yes, :n and #1 being some path

@JasperHabicht Just took a look at pgf: I think the docs could be tightened up there :) They have effectively \draw_path_use:n { bb } - feels slightly odd to me as it's not really using the path in that sense at all

@JasperHabicht Quite

@JosephWright Right. And from_path is also more descriptive that just set (which might have another meaning in the future or internally even)

@JasperHabicht OK, for the present I think I'll go with \draw_bb_from_path:n - this module remember is experimental, so it could all change - implementation a bit later today, but within the l3draw-path source as it's 'path-like' and comes from the pgf path 'area'

@JosephWright Cool! Yes, I know it is experimental. "Handle with care, code might break at any time" =)

@JosephWright but can be computationally hard if the path is a curve hence sometimes nice to give it a rectanglem as it has to be a rectangle in the end.

In expl3, literate programming would suggest I should favor \g_teepeemm_fooinbar_bool instead of the scratch \g_tmpa_bool % is foo in bar?. Using the scratch would save a single definition, but my memory is more of a problem than the computer's memory. Are there considerations that would make me want to lean toward using the global scratch variables?

@Teepeemm The 'scratch' vars are really there for document author use/testing/true one-offs - anything for a package should use it's own ones

@Teepeemm scratch macros \@tempa were designed to save a few dozen csnames in latex2.09 and 2e, when the csname hash table was almost always nearly full. But now, by the time you've loaded expl3 and unicode-math and tikz and ... worrying about one extra csname probably is not worth the worry:-)

@mickep blame you? github.com/latex3/unicode-math/issues/631

@DavidCarlisle the first time I see an example were this actually does something. Do you know an example where all values have some effect?

@DavidCarlisle That is what I get with luatex, so probably a macro package issue :P

@mickep not that that would absolve you of blame, but I guess I'd better check....

@UlrikeFischer well you need a more complicated example as the italic correction is used or not used so to show 4 diffeent outcomes you need an example with potentially two italic corrections

hi all

I have clearly made a dumb mistake but could anyone please tell me why this doesn't render? bpa.st/FVWEO

pdflatex says I am probably missing a '}'

@JosephWright Maybe something for l3debug? =)

@Simd Runs for me but don't do typesetting in the preamble

@JosephWright it must be an auxiliary file

Thanks for looking at it

it was indeed the .aux file

argh it has stopped working again

I think this is the relevant part of the log bpa.st/NJJXI

@Simd Did you move the example into the document?

@mickep like this? bpa.st/EAWP4

same problem sadly

@Simd Exactly how are you typesetting

oh wait...

sorry I didn't delete the first version

it works now.. the problem was having it before begin{document} as you suspected

thank you

@Simd Well, that was what Joseph wrote above...

@mickep thank you Joseph. I foolishly thought it was a stylistic criticism

@Simd Sometimes it's only that, but you simply can't assume fonts, colour, ... are set up properly in the preamble

it must have worked in a previous version of texlive as this is something I wrote a long time ago

@Simd Please don't cross-post without linking to all other versions of your discussions in every place where you post this

@samcarter ?

@JosephWright The same discussion was posted in more than one chat room

@samcarter Ah, yes, I see: in Another Place

@JosephWright :)

@samcarter point accepted

@Simd Many of the regulars are the same

@JosephWright don't know what you mean :)

@Skillmon Typo - will fix ;)

@JosephWright that is good really

@Skillmon Many people hang out here and in Another Place to a greater or lesser extent

That means the House of Lords in the UK

@Simd Thanks!

As you may already know

@Simd Not only that ...

@JosephWright don't worry, I understood you in the first place, was meant to be a stupid joke, doesn't work well in written form :P

@Skillmon Instead of writing, you could send a messenger duck to each chat participant which would deliver a voice message :)

@JasperHabicht (@mickep) I've been reading over he pgf code, and I think the way it does relevant for bounding box is basically just what I've provided as \l_draw_bb_update_bool, i.e. you just draw your path then set that false

pgf makes it 'internal' but as l3draw is more 'programmatic' I think on reflection it's OK as it is

@JosephWright Well the point is that if you use TikZ's \path(without draw or fill), it will still affect the bounding box. But if you use \draw_path_use(_clear):n { }, it does not affect the bounding box. So, with the l3draw package, it is currently not possible to "use" a path to affect the bounding box.

@JasperHabicht Yeah, that worries me: they don't suppress the correction for the linewidth, which suggests a bug to me

@JasperHabicht Will re-read the pgf manual again :)

@JosephWright Hm, I did not check this. So, \path(without draw) won't take into account previously set line width is what you mean? Or maybe I can't follow

@JasperHabicht I'm working on it ...

@JosephWright I hope you won't read the whole thing or we won't see you for quite some time :)

@samcarter :)

@JasperHabicht github.com/latex3/latex3/commit/…

I should probably come up with some kind of test ....

Ah, so you can use draw_path_replace_bb: after draw_path_use:n? Or can you just omit draw_path_use:n?

@JasperHabicht Well you could use it after - feels a bit odd as \draw_path_use:n already sets the bb, and you could simply turn off updating before that ... but up to yu

@JasperHabicht \draw_path_use:n always involves the path data ending up in the output: stroke or fill or a clip path - the bb is something that only exists at the macro/box level, it's not a path construct in that sense

I see (more or less) =)

I'll look at it tomorrow, but it looks great