On Mon, Mar 24, 2008 at 4:53 PM, Mojca Miklavec wrote:

The problems mentioned under #2 are just a few among many other reasons why I have written the context terminal.

I forgot to say: TikZ is the only other terminal that I know of and that (has a potential to) work reasonably well under ConTeXt, supporting both TeX sugars and high quality output, but: - it is not (yet) adapted to ConTeX (I hope it will be) - you would need to recompile gnuplot anyway - the chances to get either of the two terminals into the gnuplot core are just about equal - using either of them is equally non-portable at the moment Mojca

On Mon, Mar 24, 2008 at 5:35 PM, Morgan Brassel wrote:

Hi Mojca, and thanks for your quick (and detailed) reply,

I'm using debian sid with default ConTeXt, texlive, and gnuplot packages. Not trying to compile gnuplot myself is probably a matter of lazyness, as it should not be too difficult with debian packaging tools available. I guess the best solution for me is to try and test the 'context' terminal.

I don't know how to do it "the debian way", but an universal (less-Debian-like) way to recompile gnuplot it is to download gnuplot from sourceforge, add a line to include context terminal, and compile with ./configure make as described on http://wiki.contextgarden.net/Gnuplot. I have PATH=.:~/bin:/usr/bin ... so I simply copy my own version of gnuplot under ~/bin/gnuplot and the rest of the system remains intact. You do not need to "destroy your system" to make it work. Mojca

On Mon, Mar 24, 2008 at 7:52 PM, Ethan Merritt wrote:

On Monday 24 March 2008 08:53, Mojca Miklavec wrote:

...

PS: I'm CC-ing to Ethan in case he has some proposal about what could be done with metapost terminal to support UTF-8 (one of the best thing to do would be to remove cmr, but more is needed), and I'm CC-ing to the developer of the new TikZ terminal (for no specific reason).

Gnuplot's metapost terminal correctly passes through UTF-8 characters to the output.

That's right.

Metapost itself then mangles them.

That's also right. Actually, "btex label etex" which calls TeX (in an extremely inefficient way, among other things) is the one that doesn't know how to handle them. It would be nice if someone from this mailing list had at least some idea if that is solvable or not. Maybe harcoding utf-8 it into mptopdf could help, but that's far from being a nice solution, and has other undesired side-effects, so it's probably not really desired. Yet another solution would be to add some more commands to verbatimtex ... etex, but I don't see how to do that in some portable way. For example, metapost terminal already tries to be clever in some cases, and then loads obsolete (not to say not-existing-any-more-on-my-computer) fonts.

If there is some additional keyword or command that gnuplot could emit that would allow metapost to do better, please let me know.

OK, I will let you know if someone will come up with some idea.

Otherwise I think this problem must be resolved by using a different toolchain, one that is UTF-8 aware.

Mojca:

If the context terminal allows UTF-8 strings to be properly handled by TeX, for me that's a strong argument in favor of including it in the next gnuplot release. Does it?

Of course. "Anything" that ConTeXt suports can be supported in those labels now, including UTF-8. UTF-8 was one of the main reasons why PostScript terminal was almost out of question for me. Two years ago Hans and Taco "could not sleep" because of my requests & complaints, and they have made some major (great) improvements in ConTeXt and metapost code: labels processing became more reliable and about 100 times faster, and will improve even more with TeX Live 2008 and mplib. Those improvements are also the main reason why terminal didn't work in teTeX (but should work without problems in TeX Live 2007, which should become part of most Linux distributions by now). If you are willing to consider inclusion of the context terminal - may I ask you for your opinion about this terminal as well: http://peter.affenbande.org/gnuplot/ We're having some conversation with Peter about the possibilities to make his Lua-based TikZ terminal portable across plain TeX/LaTeX/ConTeXt formats, while TikZ itself is portable across dvips/pdfTeX (LuaTeX)/XeTeX engines. His terminal is much more popular than mine (there are more LaTeX users around than there are ConTeXt users), but the terminal has a dependency on Lua. However, any further conversation about this should better be moved off-list or to gnuplot-beta. Thanks a lot, Mojca

On Mon, Mar 24, 2008 at 11:02 PM, Hans Hagen wrote:

Mojca Miklavec wrote:

...

That's also right. Actually, "btex label etex" which calls TeX (in an extremely inefficient way, among other things) is the one that doesn't know how to handle them. It would be nice if someone from this mailing list had at least some idea if that is solvable or not.

don't bother too much about these issues ... in mkiv things will be different

It was about plain metapost. Will your tricks also possible when running "plain metapost" (mptopdf)?

i'm currently playing with mplib; the default converter works ok; the specials handler is reimplemented and mostly finished; and now i'm playing with the textual part ... i even got this working ...

\startMPgraphic fill fullcircle scaled 10cm withcolor green ; n := 50 ; for i=1 upto n : draw btex goodbye world etex scaled 2 rotatedaround(origin,i*360/n) ; endfor ; \stopMPgraphic

so, btex/etex works ok in a loop; everything happpens in luatex/mplib

it's even acceptable fast ...

100 times the previous graphic (i.e. 5000 btex/etex's) takes .7 seconds on my machine

Twice "wow" :) (After knowing the timings from the old-good-pre-sometxt times.) Thanks a lot, Mojca

Hi everyone, Hi Mojca, I finally compiled gnuplot with support for the context terminal. It was really easy in the end, I should not have been afraid... I have two questions however (see example below): * Does the option 'solid' work with the context terminal? I still get dashed lines here... * ' and " quotes do not give the same result when UTF-8 character are involved. Is it wanted? Best regards, Morgan \enableregime[utf] \usemodule[gnuplot] \setupcolors[state=start] \setupGNUPLOT[options=color solid] \startGNUPLOTscript[sin] set ylabel "héllo" set xlabel 'héllo' plot sin(x), sin(2*x) \stopGNUPLOTscript \starttext \useGNUPLOTgraphic[sin] \stoptext

You can use

\setupGNUPLOTterminal [context] [dashed=no, textscale=0.9]

Thank you, Mojca! The dashed option is ok, but I didn't manage to have 'textscale' work: adding these lines in my previous example still gives 12pt font... Am I missing something?

...

* ' and " quotes do not give the same result when UTF-8 character are involved. Is it wanted?

No. It's the same problem that I have mentioned last time. If you take a look at filename-gnuplot-1.plt you will see:

set ylabel "h\dochar {233}llo" set xlabel 'h\dochar {233}llo'

The second case gets literally to the output file, but then ConTeXt interprets it OK again. In the first case backslash is lost, and you get nonsense. This can be solved by using \detokenize as descriibed last time, but then again - it would be best if Taco or Hans or someone else had an idea of how to prevent that weird expansion inside \startGNUPLOTscript. I always use simple quotes for no particular reason (or maybe because I sometimes want to use \bf or other commands with backslash).

Sorry to make you explain again, I'm a bit lost with all those new things... I'll use simple quotes from now on, but is there a simple way to escape the ' character in this case? I tried set xlabel 'I\'\ m sorry!' but the ' is not typeset correctly then. A big thanks for your great patience! Morgan

Am 2008-03-25 um 18:11 schrieb Mojca Miklavec:

On Tue, Mar 25, 2008 at 4:57 PM, Morgan Brassel wrote:

...

set xlabel 'I\'\ m sorry!'

If UTF-8 works, why don’t you just use a proper apostrophe (’ vs. ') then? Greetlings from Lake Constance! Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)

On Wed, Mar 26, 2008 at 9:05 AM, Taco Hoekwater wrote:

Hi,

This thread is a bit confusing to me, so if there is an actual question to me, someone has to rephrase it (and keep in mind that I have not used gnuplot in 'ages').

Yes, I have two questions (that have been discussed at the begining of development already). 1.) here's a minimal example: \enableregime[utf] \usemodule[gnuplot] \setupGNUPLOT[terminal=mp] % so that you don't need to use the special binary \startGNUPLOTscript[sin] set xlabel 'héllo' plot sin(x), sin(2*x) t '$sin(2x)$' \stopGNUPLOTscript \startGNUPLOTscript[cos] # this comment doesn't work set xlabel 'héllo' plot cos(x) \stopGNUPLOTscript \starttext \useGNUPLOTgraphic[sin] \useGNUPLOTgraphic[cos] \stoptext Now, run texexec filename and take a look at filename-gnuplot-1.plt The second example needs to be commented out anyway as it fails completely. The problem is that the content of between GNUPLOTscript should be copied *verbatim* to .plt file. Now it goes through some semi-modified TeX parser that usually screws up some non-trivial cases (or, better said, only trivial cases work OK). If there existed some \startbuffer[name][continue], then it could be misused to put the content between GNUPLOTscript literally to that plt file. However, I have already been asking about how to do that (already in the time when line endings were screwed up) and there has been no real conclusion made so far. I guess it is possible, otherwise buffers and verbatim would not work, but I have no idea how to do that. Question 1a would probably be how to do that in mkiv, but that's not such a high priority as fixing the "bug" in the old code.

Mojca Miklavec wrote:

...

set ylabel "h\dochar {233}llo"

Should this not be

set ylabel "h\\dochar {233}llo"

It should. But it's not me the one who has put that junk to the .plt file :) :) :) ConTeXt does some weird thing with characters and puts "\dochar {233}" instead of "é" into the .plt file. (Almost) "the same thing" (printed \dochar) has happened to me a few times when using verbatim in ConTeXt (but got fixed).

because of GNUplot's own double-quoted string parsing? Independent of expansion in \startGNUPLOTscript, I mean?

True, but how are you going to convince TeX (ConTeXt) to put double backslash there?

Speaking as the maintainer of Metapost, assuming 'plain.mp': you should be able to use UTF-8 in btex ... etex under the following (narrow) conditions:

* you have set up the verbatimtex .. etex properly so that your macro package nows how to handle the UTF-8 input; * your tex engine generates DVI files * the resulting fonts that are used in that DVI are TFM-based.

For context, that would mean mkii pdftex with \enableregime[utf], but in that case, you are much better off using \textext.

2.) So - how should the (plain) metapost file look like and how should mptopdf be called, so that utf-8 would work OK in some portable-enough way? (\'e works OK there, it was only one backslash missing.)

You cannot have UTF-8 in literal metapost label strings, because Metapost only knows about traditional TFM fonts (single byte).

That's fine. I do not need metapost label strings. Thanks a lot, Mojca