On Thu, 6 Feb 2003 15:29:12 +0100 Giuseppe Bilotta wrote:

Thursday, February 6, 2003 Jens-Uwe Morawski wrote:

JUM> Hmm, PSTricks consists of two parts: JUM> a) a TeX-part that provides a user-interface and writes the JUM> PS-specials in the dvi-output JUM> b) a set of PS-macros that provides a varity of interesting JUM> features

[snip]

JUM> So, what do want or what is missing in your opinion, since JUM> some of the PSTricks features are already available in ConTeXt/MFun.

I'm more interested in (a), even if, I assume, some part of (b) would need to be implemented in MetaPost too ...

as you know, PSTricks is a huge package, so where to start? - what features are needed - who can write the TeX interface - i could help with some MP code but one important fact is, that PSTricks is from the normal users point of view a simple 1:1 interface. That means as long as the user is not familiar with TeX-programming one PSTricks command results in specific PS-code in the output. In contrast MetaPost is an easy to learn, clean and simple graphic/programming language; therefore we should not move too many features in the TeX interface since we will loose much of MPs flexibility. IMO, the TeX-part should only be present where interaction between TeX and MP is needed or where some complex MP-code can be hidden with a single TeX-command. Jens

On Thu, Feb 06, 2003 at 11:35:14PM +0100, Giuseppe Bilotta wrote:

Thursday, February 6, 2003 Jens-Uwe Morawski wrote:

JUM> as you know, PSTricks is a huge package, so where to start?

JUM> - what features are needed JUM> - who can write the TeX interface JUM> - i could help with some MP code

Ok, the precise set of features I need is the one used by the excellent Eukleides program (http://perso.wanadoo.fr/obrecht/); while I was trying to port it to MetaPost and begun converting the instructions I knew how to convert I realized that a full (or as complete as possible) PSTricks emulation would have been the best thing ---and that it could have already been implemented. Which is why I asked :)

In particular, there are a few things that I currently see as "missing" in (plain) MetaPost (and which I couldn't find in MetaFun either); for example, there is no macro that allows to "add" drawoptions; you can only replace them altogether. PSTricks, OTOH (at least for what I could see) has a default color, pensize and line style which can be changed singularly (MetaPost seems to only do this for the pen --currentpen; it doesn't have a currentcolor or currentstyle).

Hello, I suppose you have already had a look at metaobj? ftp://ftp.tex.ac.uk/tex-archive/graphics/metapost/contrib/macros/metaobj/ It implements many of pstricks' features (see pages 93 and following in the manual). If you develop something new, it is worth checking what ideas you could borrow from metaobj. At the end of the metaobj manual, there are also hints for a TeX interface. Denis

On Thu, 6 Feb 2003 23:35:14 +0100 Giuseppe Bilotta wrote:

Thursday, February 6, 2003 Jens-Uwe Morawski wrote:

JUM> as you know, PSTricks is a huge package, so where to start?

In particular, there are a few things that I currently see as "missing" in (plain) MetaPost (and which I couldn't find in MetaFun either); for example, there is no macro that allows to "add" drawoptions; you can only replace them altogether. PSTricks, OTOH (at least for what I could see) has a default color, pensize and line style which can be changed singularly (MetaPost seems to only do this for the pen --currentpen; it doesn't have a currentcolor or currentstyle).

Do you mean something like in the attached files? keyvalmp.mp : package for key-value parameters in MP; used in mpt-conf.mp (BTW, if anybody knows a better way to implement this, please let me know) mptricks.mp : base MPTricks package mpt-conf.mp : MPTricks module that implements the requested feature mpt-test.mp : the example file Best, Jens

On Fri, 7 Feb 2003 21:34:55 +0100 Giuseppe Bilotta wrote:

Friday, February 7, 2003 Jens-Uwe Morawski wrote: JUM> Do you mean something like in the attached files? JUM> keyvalmp.mp : package for key-value parameters in MP; used in mpt-conf.mp JUM> (BTW, if anybody knows a better way to implement this, please JUM> let me know) JUM> mptricks.mp : base MPTricks package JUM> mpt-conf.mp : MPTricks module that implements the requested feature JUM> mpt-test.mp : the example file

EXTREMELY interesting! Thank you very much!

Hmm, it's only the beginning ;-) Can you point me to an up-to-date and good documentation about PSTricks basics, so I can see what else is needed. I've never used PSTricks, esp since i think that the docu is a mess. Jens

At 05:21 PM 2/8/2003 +0100, Denis Roegel wrote:

...

On Fri, 7 Feb 2003 21:34:55 +0100 Giuseppe Bilotta wrote:

...

Friday, February 7, 2003 Jens-Uwe Morawski wrote: JUM> Do you mean something like in the attached files? JUM> keyvalmp.mp : package for key-value parameters in MP; used in mpt-conf.mp JUM> (BTW, if anybody knows a better way to implement

On Sat, Feb 08, 2003 at 03:20:39AM +0100, Jens-Uwe Morawski wrote: this, please

...

...

JUM> let me know) JUM> mptricks.mp : base MPTricks package JUM> mpt-conf.mp : MPTricks module that implements the requested feature JUM> mpt-test.mp : the example file

EXTREMELY interesting! Thank you very much!

Hmm, it's only the beginning ;-) Can you point me to an up-to-date and good documentation about PSTricks basics, so I can see what else is needed.

The only documentation is from 1993. You can find it on CTAN. Or here:

http://tex.loria.fr/graph-pack/pstricks/pst-usr1.pdf http://tex.loria.fr/graph-pack/pstricks/pst-usr2.pdf http://tex.loria.fr/graph-pack/pstricks/pst-usr3.pdf http://tex.loria.fr/graph-pack/pstricks/pst-usr4.pdf http://tex.loria.fr/graph-pack/pstricks/pst-doc1.pdf http://tex.loria.fr/graph-pack/pstricks/pst-doc2.pdf

I didn't study the details of your new implementation, but it looks very promising. When you give options like `a=b', can a and b be defined as macros beforehand, or is that incompatible? That's one of the problems I had in metaobj, hence my contrived way of passing parameters.

I am thinking that it would be nice if sometime in the future we could have metaobj with your syntax for options. On the other hand, if one uses a metapost package within context, the syntax doesn't have so many constraints, because you can hide it with TeX's syntax. That's also why I found the metaobj syntax sufficient for my purpose

in any case it makes sense to cook up a decent system for namespacing so that all those mpt, metaobj and metafun can work together Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------

At 12:18 AM 2/9/2003 +0100, you wrote:

On Sat, 08 Feb 2003 20:23:07 +0100 Hans Hagen wrote:

...

in any case it makes sense to cook up a decent system for namespacing so that all those mpt, metaobj and metafun can work together

currently i use a prefix for variables and a postfix for macros, i.e mpt_VariableName or Macro_mpt for the mptricks package. The problem is that it is useful for internal macros and variables but not for the user interface.

Additionally, this problem is not only important in the ConTeXt arena, so what do you think about opening a MetaPost or TeX-and-Graphics mailinglist. There things like the current thread could be discussed. Has anybody good conections, for example to NTG, to organize this.

getting an ntg list is no problem, as long as we keep that list low bandwidth, keep the context related questions on the context list, since -) something ntg-metapost for mp specific things sounds ok to me Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------

Hi

could you ask for this list?

in progress: metapost@ntg.nl Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------

On Wed, Feb 12, 2003 at 01:25:25PM +0100, Hans Hagen wrote:

Hi

...

could you ask for this list?

in progress: metapost@ntg.nl

What about the list metafont@ens.fr which was also used for metapost related questions? Was it really necessary to create a new list? Denis

On Thu, Feb 13, 2003 at 01:22:26AM +0100, Jens-Uwe Morawski wrote:

Is it really a problem to have a dedicated MP-list? Many MP questions are not interesting to MF users and vice versa. The new list will be a low traffic list. Thus, subscriptions to both should cause not much trouble.

It's not a problem for me, but since the metafont/metapost list traffic is already very low, I was wondering whether it would be necessary to split it. Btw, would metafont questions be accepted on the new list? Denis

At 01:58 AM 2/13/2003 +0100, you wrote:

On Thu, Feb 13, 2003 at 01:22:26AM +0100, Jens-Uwe Morawski wrote:

...

Is it really a problem to have a dedicated MP-list? Many MP questions are not interesting to MF users and vice versa. The new list will be a low traffic list. Thus, subscriptions to both should cause not much trouble.

It's not a problem for me, but since the metafont/metapost list traffic is already very low, I was wondering whether it would be necessary to split it. Btw, would metafont questions be accepted on the new list?

no, just focus on mp Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------

On Sat, 8 Feb 2003 17:21:14 +0100 Denis Roegel wrote:

On Sat, Feb 08, 2003 at 03:20:39AM +0100, Jens-Uwe Morawski wrote:

...

On Fri, 7 Feb 2003 21:34:55 +0100 Giuseppe Bilotta wrote:

...

Friday, February 7, 2003 Jens-Uwe Morawski wrote: JUM> Do you mean something like in the attached files? JUM> keyvalmp.mp : package for key-value parameters in MP; used in mpt-conf.mp JUM> (BTW, if anybody knows a better way to implement this, please JUM> let me know) JUM> mptricks.mp : base MPTricks package JUM> mpt-conf.mp : MPTricks module that implements the requested feature JUM> mpt-test.mp : the example file

EXTREMELY interesting! Thank you very much!

Hmm, it's only the beginning ;-) Can you point me to an up-to-date and good documentation about PSTricks basics, so I can see what else is needed.

The only documentation is from 1993. You can find it on CTAN. Or here:

http://tex.loria.fr/graph-pack/pstricks/pst-usr1.pdf http://tex.loria.fr/graph-pack/pstricks/pst-usr2.pdf http://tex.loria.fr/graph-pack/pstricks/pst-usr3.pdf http://tex.loria.fr/graph-pack/pstricks/pst-usr4.pdf http://tex.loria.fr/graph-pack/pstricks/pst-doc1.pdf http://tex.loria.fr/graph-pack/pstricks/pst-doc2.pdf

hmm, this is the docu i know. I really do not like to find out in pst-doc* what has changed compared to pst-usr*. Currently i have no plans for MPTricks, eps since MP has IMO too many limitations.

When you give options like `a=b', can a and b be defined as macros beforehand, or is that incompatible?

a (the key) is only a local variable of specific type The macro that processes the keyval-parameters changes the meaning of ',' to be like a ';' Since colors and pairs contain commas too, it changes also the meaning of '(' and ')', so the grouping of (...) is not broken. But now it expects that (...) is a pair or color. Therefore you cannot use something that contains '(' and ')' as the value b if it is no color or pair. for example: picture pic ; pic:=image(draw origin) ; YourKeyValMacro(logo=pic) ; is possible, but not YourKeyValMacro(logo=image(draw origin)) ; on the other hand, some simple primaries work: YourKeyValMacro(shape=fullcircle scaled 2) ;

That's one of the problems I had in metaobj, hence my contrived way of passing parameters.

your way inspired me to try something like the keyvalMP package ;) My first implementation based also on strings, i.e. "logo=something,shape=anything" but this doesn't allow strings to be passed as values.

I am thinking that it would be nice if sometime in the future we could have metaobj with your syntax for options.

it will not work, since metaobj relies on macros as values. Or would you like to rewrite metaobj completely? :) It's a nice and useful package, as it currently is.

On the other hand, if one uses a metapost package within context, the syntax doesn't have so many constraints, because you can hide it with TeX's syntax.

if you hide MP with TeX code then you will loose the programming capabilities of MP. Thus, the user is forced to TeX-programming that is much harder to learn. IMO, using TeX on top of MP makes sense for specific applications (for example, contexts flow-chart module or my piechartMP package) but not for "low-level" graphics operations. AND i really like the metapost language. draw MyNicePath withcolor red this is not programming, this is conversation ;) Best, Jens

On Sat, 8 Feb 2003 22:10:22 +0100 Denis Roegel wrote:

On Sat, Feb 08, 2003 at 09:07:32PM +0100, Jens-Uwe Morawski wrote:

...

...

That's one of the problems I had in metaobj, hence my contrived way of passing parameters.

your way inspired me to try something like the keyvalMP package ;)

Thanks, at least it was useful to provide ideas to others!

IMO it is very useful for its task, esp since it has no limitations like keyvalMP.

...

My first implementation based also on strings, i.e. "logo=something,shape=anything" but this doesn't allow strings to be passed as values.

Yes, but there are workarounds. If you always expect a string as a value, and if this value doesn't contain commas, you can make it a string afterwards.

what are you doing here? Do you read the parameter as suffix and convert it with 'str' in a string?

That is what I do in metaobj. For instance, what you just wrote becomes

"logo(something)","shape(anything)" (you get used to it, and a TeX interface can hide it if necessary)

In cases where the value is a string, for instance when I specify the drawing direction of a tree, I write "treemode(U)" for treemode="U", but the parser knows to make a string of it.

I found that this works reasonably well and I don't have constraints on my keys and values.

agree, but in case of a workaround i could use ';' as seperators in the keyval-list and so all problems are gone: YourKeyValMacro(logo=image(draw origin); shape=fullcircle scaled 2) or one can use special symbols to mark strings "logo=something,shape=anything,text=''some words'' " But the question i had was to write a keyval package that implements an interface the users know or are familiar with.

...

it will not work, since metaobj relies on macros as values.

What example did you have in mind?

nothing specific, but for example the treemode-thing you gave above; here treemode is a macro and i believe that it does more than assigning the parameter "U" to an internal variable. So you have to rewrite many parts of metaobj. We can try it if you are interested but currently keyvalMP is only used in 3 of my packages and none of them is released. so, we need some testing and have to look if the limitations allow all things required for meatobj to be implemented. Jens

On Sun, 9 Feb 2003 19:30:00 +0100 Denis Roegel wrote:

On Sun, Feb 09, 2003 at 02:14:19PM +0100, Jens-Uwe Morawski wrote:

...

So you have to rewrite many parts of metaobj.

I am actually not sure of that. When I setup options or when I create an object, I am parsing the options and making a number of assignments. That's basically it. I think that the changes would be very much isolated. It would be worth having a look, but I am a bit busy these days. I could take out of metaobj what has to be changed. There is very little, I think.

Our discussion inspired me to try another, string-based keyval implementation. It allows different kind of parameters, so one can mix them all together: YourKeyValFunction "state=start,color=blue","treemode(U)","framed(r),dashes=off" or YourKeyValFunction "state=start,color=blue,dashes=off","treemode(U),framed(r)" i'm currently working on the string-parser and after i've finished some additional macros that make writing key/val macros easier i will post it here. Then we can dicuss the pros and cons and you can pick the package you prefer. Jens

On Sat, 08 Feb 2003 21:00:00 +0100 Hans Hagen wrote:

At 05:42 PM 2/7/2003 +0100, Jens-Uwe Morawski wrote:

...

Do you mean something like in the attached files? keyvalmp.mp : package for key-value parameters in MP; used in mpt-conf.mp (BTW, if anybody knows a better way to implement this, please let me know)

nice example of expansion and redefinition of symbols

about this picture key/val problem: how about passing it as string, say

SomePic=pic("picture stuff")

in keyvalmp.mp i've simplified the problem to picture-keys, since the problem will occur mostly in those cases. But the problem exists for all given values that contain groups of (...) where the (...) is not a pair or color. For example, using MetaFun, even foreground=cmyk(1,0,1,0) does not work. (BTW, this problem with a list of 4 numerics in a (...) could be solved, but not if the (...) contains a list of 5 and more numerics) Therefore i prefer something like: defineLogo(MyLogo)( label("some text",origin) ; ) ; TheKeyValMacro(logo=MyLogo) ; In contrast to your suggestion, here one can use strings in the picture expression. Jens