gnuplot-beta

the ConTeXt terminal

[Mojca M. <moj...@gm...>]

Hello,

last time when Ethan mentioned the 4.2 release again, I submitted the
code for the ConTeXt terminal to the patches, but as I supposed it's
not that obvious how to test it since one has to install ConTeXt first
(and hope for proper system settings and no bugs in my code or ConTeXt
itself).

If you freeze the code next week, I can't fix everything properly, but
if you plan to release it in a month or so, I can try to finish it by
then if you are ready to take the terminal into account for the
release.

The whole point is that the terminal is pretty independent of Gnuplot
itself (i.e. rendering of graphics is done outside of gnuplot, the
terminal only "[de]optimizes" the code). For example, the linetype
only outputs
    gp_set_linetype($linetype);
the point only outputs
    gp_point($x,$y,$pointtype);
and the rest is taken care of outside of gnuplot and can be modified
rather quickly if a bug is spotted (serious bugs might be such as the
problem with unproperly free-d "header" when I copied the code from
epslatex, or some complex feature like "3D"; other bugs are not
exluded either, but most probably most bugs lie outside of C source
itself)

Many bugs have been fixed in ConTeXt after I complained about
non-working gnuplot module and quite some things are being improved
constantly in both ConTeXt and pdfTeX which will hopefully speed up
everything. (TeX was not made with graphics in mind, so compiling the
output from ConTeXt terminal is currently pretty slow and often runs
out of TeX memmory.) But just today I got a fix from the developer
that speeds up compilation time for approximately 4 times.

I'm not so good in programming, but I tried to do thing as flexible as
possible, so that the terminal depends on the gnuplot binary as little
as possible. Further development and finetuning might be added any
time in ConTeXt itself then.

What I'm ready to do in the pretty near future (ie. things without
which the terminal may not be added to the repository):
- finish implementation of palettes
- [not critical] do some simple "set term context size Xcm,Ycm", most
probably using Ethan's parse_size
- [important, not much work] complete the help and clean the source
- [thinking, not really implementation problem] change the beginning
and end of files, so that I can assure backward-compatibility later
- [important] sligthly patch text labels
- parsing font size for determining HCHAR, VCHAR

Something rather important is also an option to split labels from
graphics for efficiency, but I'll sacrifice that if I run out of time.

Things to be left for later:
- "with image" (I have to wait for a new pdftex primitive or do some
postprocessing if I want to implement it efficiently)
- more robust guessing of label widths and heights
- do something similar as LaTeX+PostScript merge and add option to use
MetaPost or PostScript as background image where only ConTeXt labels
and/or would be used
- ...

Lots of things and improvements are still to be done outside the
binary, but I can do that any time later.

Is adding that terminal stil doable for the 4.2 release?

Thanks a lot,
    Mojca

Re: the ConTeXt terminal

[Daniel J S. <dan...@ie...>]

Mojca,

Is there a web page for ConTeXt somewhere?  I see the discussion list and a program called PRAGMA that uses ConTeXt.

Does ConTeXt have a graphics engine beyond TeX's rather limited graphics capabilities?  I'd like to get a feeling for how ConTeXt fits in with TeX and its related programs.

Thanks,

Dan

Re: the ConTeXt terminal

[Mojca M. <moj...@gm...>]

On 6/14/06, Daniel J Sebald wrote:
> Mojca,
>
> Is there a web page for ConTeXt somewhere?

http://wiki.contextgarden.net

> I see the discussion list and a program called PRAGMA that uses ConTeXt.

PRAGMA is the name of the author's company (he develops it for his
company, but helps other users a lot).

> Does ConTeXt have a graphics engine beyond TeX's rather limited graphics capabilities?

Yes and no. It's still based on TeX (going to its limits though and
constantly requesting/developing new functionality of pdfTeX), but it
has a rich set of macros and perl/ruby scripts which do some "magic"
with metapost (extension to metafont).

See http://www.pragma-ade.com/general/manuals/metafun-s.pdf (or any
cover of the manuals listed on http://www.pragma-ade.com/overview.htm)

> I'd like to get a feeling for how ConTeXt fits in with TeX and its related programs.

I would say that it (mis)uses pdfTeX to much greater extent than LaTeX
does, although LaTeX has much more packages and much more text
editors/magazines support/use LaTeX. ConTeXt is a kind of
revolutionair. It goes to the very limits / uses the newest
technologies / might be full of bugs (but once reported they usualy
get fixed within a day) / uses consistent layout / is very centralized
(one mailing list where the author himself is active) / users'
requests are often fullfilled (in LaTeX you depend on yourself: you
can make your own package, but can't add some functionality to the
existing core) / has very bad documentation (even though it's dozens
of megabytes, most things are undocumented: people read sources) / if
Hans quits, ConTeXt might die.

It has both its pros and cons ... so take the above words with a
reserve, since I might have too good opinion about it and it's
author[s].

Mojca

Re: the ConTeXt terminal

[Daniel J S. <dan...@ie...>]

Mojca Miklavec wrote:
> On 6/14/06, Daniel J Sebald wrote:
> 
>> Mojca,
>>
>> Is there a web page for ConTeXt somewhere?
> 
> 
> http://wiki.contextgarden.net

Ah, so it is similar to LaTeX in many ways with perhaps a slight variation in syntax and improved features.  Math formatting looks very similar to LaTeX.  The examples on the Wiki page look good.

What is the approach your are taking?  I see there is a means to import external graphics into ConTeXt.  The power of Xfig and gnuplot, in my mind, is the ability to have combined LaTeX and PostScript, i.e., the math format and font characteristics native to LaTeX typesetting intermixed with the far superior graphical elements of PostScript.  Is that what you are aiming for in ConTeXt as well?

Dan

Re: the ConTeXt terminal

[Mojca M. <moj...@gm...>]

On 6/14/06, Daniel J Sebald wrote:
> Mojca Miklavec wrote:
> > On 6/14/06, Daniel J Sebald wrote:
> >
> >> Mojca,
> >>
> >> Is there a web page for ConTeXt somewhere?
> >
> >
> > http://wiki.contextgarden.net
>
> Ah, so it is similar to LaTeX in many ways with perhaps a slight variation in syntax and improved features.  Math formatting looks very similar to LaTeX.

Math formatting should not only be similar, but exactly the same
(unless perhaps in some multiline environments ...) since both LaTeX
and ConTeXt use (plain) TeX for doing math.

>
> What is the approach your are taking?  I see there is a means to import external graphics into ConTeXt.  The power of Xfig and gnuplot, in my mind, is the ability to have combined LaTeX and PostScript, i.e., the math format and font characteristics native to LaTeX typesetting intermixed with the far superior graphical elements of PostScript.  Is that what you are aiming for in ConTeXt as well?

I started thinking about PostScript after I realized how slow current
rendering indeed was, but the developer of ConTeXt is currently
reimplementing the whole mechanism for handling labels inside
graphics, so I expect drastic improvements in efficiency.

The current implementation does both graphics and labels in ConTeXt
(in MetaFun): I wouldn't call the PS terminal "far superior graphical
elements of PostScript", but rather "far more efficient". ConTeXt can
theoretically do just as good job as PostScript (it's indeed using
a-kind-of-postscript intermediate step), but it can't "write PS
procedures" just as PS terminal does and the intermediate files are
currently way too big. You could compare PostScript terminal vs.
ConTeXt graphic capabilities with (highly portable) assembler vs. C
for simple tasks on ancient machines. With C you can theoretically do
the same as with Assembler, but not as efficient and you need some
compiler first.

I'm thinking about adding an option to use PostScript instead of
"quasi-native" graphics for the background, but many other things have
higher priority for now. (I would probably need to rewrite parts of
PostScript terminal and to study undocumented PS code as well as
supporting that inclusion in ConTeXt, so it could take me some time
that I don't feel worth investing yet.)

Mojca

Re: the ConTeXt terminal

[Daniel J S. <dan...@ie...>]

Mojca Miklavec wrote:

> I'm thinking about adding an option to use PostScript instead of
> "quasi-native" graphics for the background, but many other things have
> higher priority for now. (I would probably need to rewrite parts of
> PostScript terminal and to study undocumented PS code as well as
> supporting that inclusion in ConTeXt, so it could take me some time
> that I don't feel worth investing yet.)

But if you use something derivative of pslatex, you shouldn't have to study undocumented PS code.  That should be handled correctly already.  You'd need simply to supply the proper syntax for the text that ConTeXt requires as opposed to what LaTeX requires.

Unless ConTeXt is improving on TeX graphics, from what I've seen PostScript is better than TeX graphics.  Much nicer looking and controllable arrows, etc.

Dan

Re: the ConTeXt terminal

[Mojca M. <moj...@gm...>]

On 6/17/06, Daniel J Sebald wrote:
> Mojca Miklavec wrote:
>
> > I'm thinking about adding an option to use PostScript instead of
> > "quasi-native" graphics for the background, but many other things have
> > higher priority for now. (I would probably need to rewrite parts of
> > PostScript terminal and to study undocumented PS code as well as
> > supporting that inclusion in ConTeXt, so it could take me some time
> > that I don't feel worth investing yet.)
>
> But if you use something derivative of pslatex, you shouldn't have to study undocumented PS code.  That should be handled correctly already.  You'd need simply to supply the proper syntax for the text that ConTeXt requires as opposed to what LaTeX requires.

I know that I could ignore the PostScript graphic commands, but I need
to study the way how (La)TeX &.PostScript are integrated/how separate
files are handled inside Gnuplot, etc. I have to patch/integrate both
terminals in this case. I'm planning to do that, but it's not really
the priority unless someone confident with that code would be willing
to help. For the moment is was much easier to write my own code for
doing the graphic.

> Unless ConTeXt is improving on TeX graphics, from what I've seen PostScript is better than TeX graphics.  Much nicer looking and controllable arrows, etc.

What exactly do you mean by TeX graphics? \begin{picture} is useless
from my point of view, picTeX might be slightly better(?), but not
that much. What "ConTeXt graphic" means in this case is the following:

    \commandtostartgraphic
    ...
    drawing commands
    ...
    \commandtostopgraphic

drawing commands (ie. everything between the two commands for start
and stop the graphic) are written to a file, processed by MetaPost
which outputs a PostScript file which is postpocessed (converted to
PDF with special trickery) and included into final PDF literally. I
don't know how exactly it works if a flavour of TeX other than pdfTeX
is used, for example XeTeX, with DVI file as an intermediate step
(.tex -> .dvi -> PDF). But when XeTeX came out for the Linux platform
last monts, Hans was sitting the whole afternoon behind the laptop
trying to fix the existing code, so that transparency started to work
with XeTeX as well.

But the nice part of it is that I don't really have to care about what
is going on behind the scenes: it simply works (with exceptions of
bugs).

With MetaPost ("ConTeXt graphics") you can basically do everything
that you can do in PostScript: the code is converted to PostScript
indeed. You can't write literal PS code, but MetaPost is still a
programming language. You can draw exactly the same arrow in MetaPost
as you can do in PostScript.

Less supported (but conditionally possible) are shading and other
patterns introduced in later versions of PostScript. But on the other
hand you can use spot colors, transparency, ...

Mojca

Re: the ConTeXt terminal

[Daniel J S. <dan...@ie...>]

Mojca Miklavec wrote:

> I know that I could ignore the PostScript graphic commands, but I need
> to study the way how (La)TeX &.PostScript are integrated/how separate
> files are handled inside Gnuplot, etc. I have to patch/integrate both
> terminals in this case. I'm planning to do that, but it's not really
> the priority unless someone confident with that code would be willing
> to help. For the moment is was much easier to write my own code for
> doing the graphic.

Well, it's up to you of course, and both methods have their benefits.  But if you haven't given combined LaTeX/PostScript a try, it is worth understanding.


>>Unless ConTeXt is improving on TeX graphics, from what I've seen PostScript is better than TeX graphics.  Much nicer looking and controllable arrows, etc.
> 
> 
> What exactly do you mean by TeX graphics? \begin{picture} is useless
> from my point of view, picTeX might be slightly better(?),

Yes, this is what I was referring to, TeX graphics worthless.


> which outputs a PostScript file which is postpocessed (converted to
> PDF with special trickery) and included into final PDF literally.

Something like ps2pdf, I take it.


> I
> don't know how exactly it works if a flavour of TeX other than pdfTeX
> is used, for example XeTeX, with DVI file as an intermediate step
> (.tex -> .dvi -> PDF). But when XeTeX came out for the Linux platform
> last monts, Hans was sitting the whole afternoon behind the laptop
> trying to fix the existing code, so that transparency started to work
> with XeTeX as well.
> 
> But the nice part of it is that I don't really have to care about what
> is going on behind the scenes: it simply works (with exceptions of
> bugs).

"It" meaning what simply works?


> 
> With MetaPost ("ConTeXt graphics") you can basically do everything
> that you can do in PostScript: the code is converted to PostScript
> indeed. You can't write literal PS code, but MetaPost is still a
> programming language. You can draw exactly the same arrow in MetaPost
> as you can do in PostScript.

Yes, I see that now having paged through Hans H.'s amazing document metafun-s.pdf.  Wow, he put a lot of work into that!  I wonder, though, why he didn't simply format the text more like a book as opposed to slides.  I find the gray, seemingly random borders a tad disorienting and annoying.

OK, so I've learned a bit here about ConTeXt.  Thanks.

Dan

Re: the ConTeXt terminal

[Mojca M. <moj...@gm...>]

On 6/17/06, Daniel J Sebald wrote:
> Mojca Miklavec wrote:
>
> > I know that I could ignore the PostScript graphic commands, but I need
> > to study the way how (La)TeX &.PostScript are integrated/how separate
> > files are handled inside Gnuplot, etc. I have to patch/integrate both
> > terminals in this case. I'm planning to do that, but it's not really
> > the priority unless someone confident with that code would be willing
> > to help. For the moment is was much easier to write my own code for
> > doing the graphic.
>
> Well, it's up to you of course, and both methods have their benefits.  But if you haven't given combined LaTeX/PostScript a try, it is worth understanding.

As soon as I manage to do the rest, I'll look into it.

> >>Unless ConTeXt is improving on TeX graphics, from what I've seen PostScript is better than TeX graphics.  Much nicer looking and controllable arrows, etc.
> >
> > What exactly do you mean by TeX graphics? \begin{picture} is useless
> > from my point of view, picTeX might be slightly better(?),
>
> Yes, this is what I was referring to, TeX graphics worthless.

I would agree with it. PSTricks might be a bit better, but then again:
they don't work with pdfTeX well. There are some more packages around,
but once I saw metapost, I didn't want to exchange it for anything
else for static 2D drawings.

> > which outputs a PostScript file which is postpocessed (converted to
> > PDF with special trickery) and included into final PDF literally.
>
> Something like ps2pdf, I take it.

No, self-written (assuming the simple output from metapost).

>
> > I
> > don't know how exactly it works if a flavour of TeX other than pdfTeX
> > is used, for example XeTeX, with DVI file as an intermediate step
> > (.tex -> .dvi -> PDF). But when XeTeX came out for the Linux platform
> > last monts, Hans was sitting the whole afternoon behind the laptop
> > trying to fix the existing code, so that transparency started to work
> > with XeTeX as well.
> >
> > But the nice part of it is that I don't really have to care about what
> > is going on behind the scenes: it simply works (with exceptions of
> > bugs).
>
> "It" meaning what simply works?

I just wanted to say that I don't have to care about calling dozens of
conversions inbetween. Very simple syntax integrates TeX and graphics
pretty well. (The conversions happen behind the scenes.)

> Yes, I see that now having paged through Hans H.'s amazing document metafun-s.pdf.  Wow, he put a lot of work into that!  I wonder, though, why he didn't simply format the text more like a book as opposed to slides.

It's more convenient to use on the computer. You also have a paper
version from the same source:
http://www.pragma-ade.com/general/manuals/metafun-p.pdf.

(see http://www.pragma-ade.com/overview.htm)

> I find the gray, seemingly random borders a tad disorienting and annoying.

They are random (each time when a source is compiled they come out
differently, but PDF isn't able to handle randomness, so they are
"fixed"). However: I like the design, but that's my personal opinion
only.

Mojca