« first day (4862 days earlier)      last day (55 days later) » 

8:04 AM
@PabloGonzálezL (@DavidCarlisle) I've raised the texdoc business on the TL list
 
 
4 hours later…
11:44 AM
@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
 
12:12 PM
@JasperHabicht In metapost boundingbox p will give the boundingbox for the path p. Maybe I misunderstand you.
 
12:24 PM
@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!
 
12:50 PM
@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..) :)
 
1:03 PM
@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 ...
2
 
@JasperHabicht and more importantly: he knows how the bounding box is set in picture mode.
 
@UlrikeFischer Right! Something we completely ignored up to now ...
 
1:26 PM
@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
 
1:32 PM
@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
 
1:38 PM
@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" =)
 
 
3 hours later…
4:40 PM
@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.
 
5:10 PM
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
 
5:36 PM
@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:-)
4
 
@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
 
6:06 PM
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? =)
 
6:38 PM
@Simd Runs for me but don't do typesetting in the preamble
 
7:00 PM
@JosephWright it must be an auxiliary file
Thanks for looking at it
it was indeed the .aux file
 
7:14 PM
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...
 
7:28 PM
@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
 
8:26 PM
@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 :)
 
8:49 PM
@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
 
8:54 PM
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 :)
 
9:27 PM
@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
 
9:47 PM
@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 ...
 
10:19 PM
@JosephWright I hope you won't read the whole thing or we won't see you for quite some time :)
3
 
@samcarter :)
 
10:36 PM
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
 

« first day (4862 days earlier)      last day (55 days later) »