On Tue, 30 Jan 2007, Mojca Miklavec wrote:
On 1/30/07, Aditya Mahajan wrote:
On Tue, 30 Jan 2007, Mojca Miklavec wrote:
Hello,
instead of checking the problems with MyWay about database module, I created another unfinished piece about \sometxt (as promised already long ago):
http://dl.contextgarden.net/myway/sometxt.pdf
\sometxt{...} should be used instead of textext("...") in metafun graphics whenever possible, since it's much more efficient. An average user shouldn't care about much more than that. The MyWay is devoted to the curious ones. I hope that I included all the major ideas which Hans implemented in Summer/Autumn 2006 on my request. Although not all of them are documented well enough, I tried to mention them at least.
Very nice. Now, I do not need to look up old mails to figure out how to manipulate sometxt.
I've put there everything that came to my mind, but 99% of the usage is still only \sometxt{...}. The rest is trickery.
I have one example where \sometxt[...]{...} is useful. If you are interested, I can send it to you.
I can include it in the manual if you want. I used \sometxt[] for gnuplot because it looks more elegant and more backward compatible that adding a bunch of additonal macros in front of it.
I mainly use the \sometxt[..]{..} feature to create labels in my metapost figures. The normal setup is \definetextext[parbox]{\framed[frame=off, width=2cm, autowidth=force, align=middle, background=color, backgroundcolor=white]} Which insures that I do not have to worry about line breaking of long labels, and the unfill trick to get white backgrounds in labels. The down-side is that the background is white instead of being transparent. So, if you have a colored page background, the figure looks odd. I have attached a complete example.
I thought a bit about your feature request, and it is not too difficult to implement it. Here is a patch that allows you to use \sometext[font][iwona,20pt]{...}. Careful of spurious linebreaks.
Great!!!
Having a hardcoded \sometxt[font] doesn't help me much, but I'll copy the code literally to the module and replace [font] by [gp].
The font is not hardcoded. But you need to have something there. Otherwise you need a mechanism to distinguish between \sometxt[whatever] and \sometxt[iwona]
%======================================================= [snip[ %===============================================================
I haven't tested it, but I do not think that this should cause any problems with existing code. \definetextext[font] is just a dummy. It should work with other things also. You can get rid of the dummy by checking in redodofiltersometxt if #1 is has a comma or not. Would that extra overhead be useful of gnuplot?
Yes. But copying the code literally doesn't make as much sense since other users might have different needs than "second optional parameter should switch the font". I'll add that to the gnuplot module directly.
It can be configurable. Maybe something like \defineopttextext[whatever]{\command} so that with \sometxt[whatever][2nd arg]{stuff} translates to \command[2nd ard]{stuff} and \sometxt[whatever]{stuff} translates to \command{stuff}. That would involve more work to write the macro \command, but will provide more flexibility.
The only thing that could help would be a high-level user interface to define such commands, such as is \definetextext[name]{\command}
So that one could then define % I'm not sure what should come inbetween \definetextext[myboldfont]???{\myboldfont} % #1 might be empty \def\myboldfont[#1]#2{\framed{ \doifnot{#1}{}{\switchtobodyfont[#1]} ^^^^^^^^^^^^^^^^ \doifnothing or \doifsomething is easier to read \strut\bf #2}} for example and use it as \sometxt[myboldfont][iwona]{this will be bold and framed iwona}
It may be possible to extend definetextext to do this rather than \defineopttextext. In any case, it is upto the macro \command to ensure that it can handly the optinal argument. I will see if I can cook up something working.
But your current code is more than enough for me (apart from the fact that it's not really nice to redefine low-level macros, but I'll try to keep up with low-level changes, should any accur) ;)
Or persuade Hans to have a proper version in the core :) Aditya