plplot-devel Mailing List for PLplot

Arjen Markus wrote:
> 
> Hello,
> 
> I have committed new versions of the three files involved in the problem
> of the plvect and plsvect functions not being visible in the Java
> binding.
> 
> With these versions I can make example x22c work properly (this example
> uses said functions, as well as two others that gave me a bit of
> a headache - see previous postings).
> 
> As I do not have a Java development environment ready, I would like to
> ask Ali to test this as soon as the new tarball is ready.
> 

I have received a message from Ali Mohammed, that with these new
versions
the Java bindings can be correctly created on Windows.

Regards,

Arjen

On Thursday 09 September 2004 05:24, Andrew Roach wrote:
| At 06:32 PM 8/09/2004 +0100, Jo=E3o Cardoso wrote:
=2E..
| >| The wingcc driver took a giant leap of faith in this
| >| department by ASSUMING a 24 bit driver, so did not worry about
| >| extending the palette.
=2E..
| >Why isn't a 16 bits truecolor X display enough?
|
| In practice, that would be more than enough to get the job done. Can
| we make the assumption that all X displays are going to be 16 bit ?

I can assume it the same way as you assumed 24bits in gcwin.  All=20
current linux distros must use 16/24 bits as default; and Xservers (is=20
that still a business?) generally have xservers that support multiple=20
color types and depths.

| am not debating the point here - I just do not know. When I looked at
| the xwin code, there seemed to be a lot of logic to handle displays
| with small palettes.

That's legacy code. We also have a laserjet II driver!

| If we can, then you let plplot handle it's own=20
| cmap1 cmap0 palettes, and let freetype automagically smooth the text,
| taking what colours it needs, as it needs them.

OK, thanks for the info. If/when I have spare time I will try that.

Joao

| -Andrew
|
|
|
| -------------------------------------------------------
| This SF.Net email is sponsored by BEA Weblogic Workshop
| FREE Java Enterprise J2EE developer tools!
| Get your free copy of BEA WebLogic Workshop 8.1 today.
| http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=CCk
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

At 06:32 PM 8/09/2004 +0100, Jo=E3o Cardoso wrote:
>| >The iterative driver I think would benefice from freetype is the
>| > xwin driver. I have already thought of that, and it didn't seem to
>| > difficult to do, as most support is already in plfreetype.c. But my
>| > analysis was superficial, and I don't have the time
>|
>| The hardest part comes with the palette support when using the text
>| smoothing.
>
>And if one forgets smoothing? Wouldn't the implementation be much
>simpler? Smoothing is after all an option for the gd family of drivers,
>and we don't need to support it for the xwin driver.

Without smoothing, it is a snap.

Smoothing is used by the wingcc driver too. Believe me, it really shines=20
when used on interactive terms, especially when you use smaller windows,=20
have small fonts, or do multiple plots on a page. With smoothing and 4=20
plots a page, you can still read all the text easily.

>| The wingcc driver took a giant leap of faith in this
>| department by ASSUMING a 24 bit driver, so did not worry about
>| extending the palette.
>
>You mean the X11 xserver color pallete, not the plplot cmap1 pallete,
>right?

Yes.

>Why isn't a 16 bits truecolor X display enough?

In practice, that would be more than enough to get the job done. Can we=20
make the assumption that all X displays are going to be 16 bit ? I am not=20
debating the point here - I just do not know. When I looked at the xwin=20
code, there seemed to be a lot of logic to handle displays with small=20
palettes. If we can, then you let plplot handle it's own cmap1 cmap0=20
palettes, and let freetype automagically smooth the text, taking what=20
colours it needs, as it needs them.

>  The code in gd.c
>seems to use 64 graylevels be default, isn't that available on a 16bits
>truecolor xserver? Sorry for the ignorance :(

Yes, it should be available. Even if the number of greys used for smoothing=
=20
was extended beyond 64**, 99% of the time it would be accommodated in a 16=
=20
bit display driver.

**(in theory, you can go as high as 256; in practice, you cant tell the=20
difference; in reality rarely no more than about 12 ever seem to get used).

-Andrew

On Wednesday 08 September 2004 05:15, Andrew Roach wrote:
| At 08:09 PM 7/09/2004 +0100, Jo=E3o Cardoso wrote:
| >Roughly, what is really needed is to store the text info into the
| > plot buffer.
| >In src/plbuf.c, in function plbuf_esc(), add a case PLESC_HAS_TEXT
| > and in rdbuf_esc() do the same. Some small changes might be needed
| > in plcore.c also.
|
| The thought crossed my mind about adding the text to plbuf, but I was
| a little worried about backwards compatibility with the metafile
| format (it is the same as plbuf isn't it ?),=20

But backward compatibility would be maintained, as existing metafiles=20
would be properly read and displayed; new metafiles couldn't be read by=20
old plplot apps, but that kind of compatibility is most of the time not=20
required or even possible.

| Ideally, ALL text should be saved to the buffer, regardless of
| whether the driver supported it's own text drawing capabilities; that
| way if you replayed a metafile to a device that supported freetype
| (or any other self-rendering), the text would be drawn using
| freetype.

Yes, of course.

| Under this model, the text being drawn in a regular driver=20
| would be parsed to the text commands and converted to vectors. This
| approach would, I assume, make backwards compatibility with metafiles
| a problem since the new way of storing text would fail on old
| versions of plrender.

I don't think this to be a problem.

=2E..

| >The iterative driver I think would benefice from freetype is the
| > xwin driver. I have already thought of that, and it didn't seem to
| > difficult to do, as most support is already in plfreetype.c. But my
| > analysis was superficial, and I don't have the time
|
| The hardest part comes with the palette support when using the text
| smoothing.

And if one forgets smoothing? Wouldn't the implementation be much=20
simpler? Smoothing is after all an option for the gd family of drivers,=20
and we don't need to support it for the xwin driver.=20

| The wingcc driver took a giant leap of faith in this=20
| department by ASSUMING a 24 bit driver, so did not worry about
| extending the palette.

You mean the X11 xserver color pallete, not the plplot cmap1 pallete,=20
right? Why isn't a 16 bits truecolor X display enough? The code in gd.c=20
seems to use 64 graylevels be default, isn't that available on a 16bits=20
truecolor xserver? Sorry for the ignorance :(

Joao


| This assumption, though extreme, should be=20
| safe on pretty much any windows machine assembled in the last 10
| years or so. I don't think you could make the same assumption about
| the xwin driver (that everyone would have 24 bit), so you probably
| would have to deal with the palette more carefully.
|
| -Andrew Roach
|
|
|
| -------------------------------------------------------
| This SF.Net email is sponsored by BEA Weblogic Workshop
| FREE Java Enterprise J2EE developer tools!
| Get your free copy of BEA WebLogic Workshop 8.1 today.
| http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=CCk
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

Hello,

I have committed new versions of the three files involved in the problem
of the plvect and plsvect functions not being visible in the Java
binding.

With these versions I can make example x22c work properly (this example
uses said functions, as well as two others that gave me a bit of 
a headache - see previous postings).

As I do not have a Java development environment ready, I would like to 
ask Ali to test this as soon as the new tarball is ready.

Regards,

Arjen

"Alan W. Irwin" wrote:
> 

> So on the windows side of things do not rely on the "c" prefix to help decide
> whether something is in the public API or not.  Instead, look at the total
> contents of plplot.h to find out what is in the public API.
> 

I think I was making my life a bit more miserable than was actually
necessary:
I had solved this issue with other functions already - now to find the
right
magical combination...

Regards,

Arjen

Andrew Ross wrote:
> 

> Under unix the symlink option would be our neatest bet for a lot of
> these build tree / source tree problems. I've always shrunk away from
> this because it doesn't work on windows. I imagine you would have to
> revert the link to a copy there. Do any windows users have any comments
> on this?
> 

It may be different with the most modern versions of Windows, and 
there is a kind of link mechanism available, but AIUI you would need
a proper copy - this is how the building of the C library works on
Windows
anyway.

Regards,

Arjen

Andrew Ross wrote:
> 
  However,
> > assumed-shape arguments apparently also require something called interface
> > blocks, and I don't know how difficult those are to work with when building
> > a fortran interface to our PLplot library.
> >

The work I referred to in an earlier response is the creation of a 
suitable set of interfaces, that is:
- a small script extracts the argument lists from the C source and
  puts them in a module for Fortran 90/95.
- this module allows better checking of the actual calls to the 
  subroutines in the PLplot library. 
- it can also be used to implement the Fortran 90/95 stubs in the same
  way as we do with C++ (or on Windows with the DLL-version), when
  the interface we would like (like assumed-shape arrays) is not 
  compatible with C.

> > Arjen, does cfortran.h allow the use of assumed shape arguments or would
> > that be a lot of work to implement?  Also, is there any other f90 extension
> > that would be useful for simplifying our fortran interface API?
> >

cfortran.h will not solve this issue, as it is the virtual impossibility
to represent
assumed-shape arrays in C that is at stake here. But the solution is
really
simple:

   subroutine my_array_manipulation( array_2d )
   real, dimension(:,:) :: array_2d  ! This example uses a 2D array

   call actual_c_routine( array_2d, size(array_2d,1), size(array_2d,2) ) 

   end subroutine

where actual_c_routine is the actual C routine that is compatible with
the 
FORTRAN 77 style and hence can be interfaced via cfortran.h

> > Whether or not we decide to add an f90 interface using the f90 extensions to
> > simplify our argument lists or stick with our current fortran API, a version
> > of our fortran examples written taking advantage of all f90 extensions would
> > be most welcome.
> 
> I'd think of it as similar to the C/C++ situation. With f90 we can
> encapsulate the plplot api in a plplot module to provide something
> vaguely akin to a C++ class. Similarly we _could_ use the C API in C++,
> it's just the Object Orientated approach and the extra language features
> are nice.
> 
> Andrew
> 

Yes, these features make it very worthwhile to read about Fortran 90/95
(or
even the next standard: Fortran 2003)

Regards,

Arjen

At 08:09 PM 7/09/2004 +0100, Jo=E3o Cardoso wrote:
>Roughly, what is really needed is to store the text info into the plot
>buffer.
>In src/plbuf.c, in function plbuf_esc(), add a case PLESC_HAS_TEXT and
>in rdbuf_esc() do the same. Some small changes might be needed in
>plcore.c also.

The thought crossed my mind about adding the text to plbuf, but I was a=20
little worried about backwards compatibility with the metafile format (it=20
is the same as plbuf isn't it ?), so thought I would go for the local text=
=20
cache which had zero impact on other parts of the library.

Ideally, ALL text should be saved to the buffer, regardless of whether the=
=20
driver supported it's own text drawing capabilities; that way if you=20
replayed a metafile to a device that supported freetype (or any other=20
self-rendering), the text would be drawn using freetype. Under this model,=
=20
the text being drawn in a regular driver would be parsed to the text=20
commands and converted to vectors. This approach would, I assume, make=20
backwards compatibility with metafiles a problem since the new way of=20
storing text would fail on old versions of plrender. But could we safely=20
assume that since people had built and installed plplot on their system,=20
their plrender was always up to date anyway so this would be a non-issue ?


>| So in short, if you wanted to add freetype to an interactive bitmap
>| terminal that needed cachingof plot commands, you would need to add
>| just one extra line of code beyond what is currently in the
>| documentation. I'll update the docs to reflect this, but if anyone
>| were interested in adding support to an interactive device, look at
>| wingcc.c rather than gd.c.
>
>The iterative driver I think would benefice from freetype is the xwin
>driver. I have already thought of that, and it didn't seem to difficult
>to do, as most support is already in plfreetype.c. But my analysis was
>superficial, and I don't have the time

The hardest part comes with the palette support when using the text=20
smoothing. The wingcc driver took a giant leap of faith in this department=
=20
by ASSUMING a 24 bit driver, so did not worry about extending the palette.=
=20
This assumption, though extreme, should be safe on pretty much any windows=
=20
machine assembled in the last 10 years or so. I don't think you could make=
=20
the same assumption about the xwin driver (that everyone would have 24=20
bit), so you probably would have to deal with the palette more carefully.

-Andrew Roach

On Tuesday 07 September 2004 04:27, Andrew Roach wrote:
| At 11:14 AM 6/09/2004 -0700, Alan W. Irwin wrote:
...
| In adding freetype support to the wingcc driver I did need to expand
| the freetype driver a little by adding a local text cache. When a
| refresh command is requested (usually by windows) within the wingcc
| driver, I simply replayed the plot buffer and redraw everything;
| unfortunately, the text was not buffered because plplots own buffer
| only stores draw commands 

Yes, I miss that when I wrote the PLESC_HAS_TEXT extension, and latter 
didn't find motivation to finish it.

Roughly, what is really needed is to store the text info into the plot 
buffer.
In src/plbuf.c, in function plbuf_esc(), add a case PLESC_HAS_TEXT and 
in rdbuf_esc() do the same. Some small changes might be needed in 
plcore.c also.

| - hence the need for the local text buffer. 
| The changes (from the above docs) needed to make a device driver
| support the text cache are minimal, as freetype itself decides if
| text buffering is required. In the case of wingcc, before I added the
| text cache the replot function was:
|
|                  if (dev->waiting==1)
|                  {
|                      plRemakePlot(pls);
|                   }
| then after it became:
|
|                  if (dev->waiting==1)
|                  {
|                      plRemakePlot(pls);
|                      #ifdef HAVE_FREETYPE
|                      pl_RemakeFreeType_text_from_buffer(pls);
|                      #endif
|                   }

With the above changes this wouldn't be needed. If the above is 
implemented, than at plcore.c:plP_text()

	if (plsc->plbuf_write)
	    plbuf_esc(plsc, PLESC_HAS_TEXT, &args);

would store the text info in the plot buffer and plRemakePlot() would 
read and plot it from the buffer.

But I will not do that, so please feel free to do it yourself :))

| So in short, if you wanted to add freetype to an interactive bitmap
| terminal that needed cachingof plot commands, you would need to add
| just one extra line of code beyond what is currently in the
| documentation. I'll update the docs to reflect this, but if anyone
| were interested in adding support to an interactive device, look at
| wingcc.c rather than gd.c.

The iterative driver I think would benefice from freetype is the xwin 
driver. I have already thought of that, and it didn't seem to difficult 
to do, as most support is already in plfreetype.c. But my analysis was 
superficial, and I don't have the time

| At 11:16 PM 6/09/2004 +0200, Rafael Laboissiere wrote:
| >A better approach would be to use the native affine transformation
| > of the Postscript language to do arbritrary shear/rotation of
| > characters.  Look at the very simple PS file attached below that I
| > wrote to illustrate my point. Implementing this idea may imply in
| > substantial changes in the core functions of PLplot.  A new
| > PLESC_HAS_AFFINE escape code (let's say) could be introduced and
| > used by drivers that claim to be able to do arbitrary rotation and
| > shear of graphical objects (like PostScript does).
|
| I do not think we really need a "PLESC_HAS_AFFINE" escape code ?
| Transformations for text are stored inside "EscText *args" in all
| text drawing functions anyway, so it is there for anything that wants
| it. plfreetype simply interrogates these parameters to find out what
| transformation/shearing is required.

But sometimes, I don't know why, it is not possible to fully recover the 
original information -- that's the reason why in 3D the text is wrongly 
rotated/sheared in the ps driver. By the way, the ps driver uses two 
methods to rotate text, accessible using -drvopt text=1|2, the default 
being 1. Method 2 enables shearing as well, but is incomplete.

The pstex driver suffers from the same problem as the ps one, and in 
addition can't have rotation/shearing/continuous justification, as 
latex don't support it (as far as I know). The pstex driver main 
feature is the ability to use the latex math capabilities.

Joao

|
| -Andrew Roach
|
|
|
|
|
|
| -------------------------------------------------------
| This SF.Net email is sponsored by BEA Weblogic Workshop
| FREE Java Enterprise J2EE developer tools!
| Get your free copy of BEA WebLogic Workshop 8.1 today.
| http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

On Tue, Sep 07, 2004 at 07:55:52AM -0700, Alan Irwin wrote:
> On 2004-09-07 07:34+0100 Andrew Ross wrote:
> 
> The windows build system (in sys/win32/msdev) has always been independent of
> the Unix/Linux build system. The only cross-talk I am aware of between the
> two build systems is the windows side currently needs the swig-generated
> files that are in the tarball, and those wouldn't be necessary if something
> were done on the windows side with swig. Anyhow, symlinks generated at build
> time in our Unix/Linux build tree to the corresponding source tree
> counterparts are not an issue for the independent windows build system.

You are in of course right. In fact according to the autobook (quoting the
GNU coding standards) you can rely on the utility "ln" in you shell
scripts, although you are recommended to use the autoconf macro 
AC_PROG_LN_S to set the variable LN_S since not all systems use the -s
option for soft links. Oh well. Rafael's changes have fixed the problem
in this instance anyway, though we could change some of the cp's to ln's
I guess. I'll bear this in mind for next time.

Andrew

On Tue, Sep 07, 2004 at 09:50:56AM +0200, Rafael Laboissiere wrote:
> * Alan W. Irwin <ir...@be...> [2004-09-06 16:29]:
> 
> > Andrew, I suspect you have already discovered this for yourself, but just to
> > be specific, the latest matwrap available on debian-testing (version 0.57-3)
> > is only slightly different than bindings/octave/matwrap/matwrap.  Also, I
> > just tested that Debian version and it also doesn't recognize the
> > dirname/filename version of plplot_octave_rej.h.
> 
> I just committed a change to bindings/octave/Makefile.am that may work for a
> separate build tree.  Please, try it.  Matwrap is called now with:
> 
>     -cpp_ignore $(scrdir) -cpp_ignore plplot_octave_rej.h
> 
> This is akin to calling gcc with "-L <dir> -l <file>", but matwrap has a
> single option (-cpp_ignore) to specify both directories and files.  What
> matwrap does not accept (and that I only discovered after looking at the
> Perl code) are constructs like "-cpp_ignore <dir/file>".

Excellent - this appears to fix the problem building outside the source 
tree. I uncovered another problem with plplot.doc not being proper
copied. I have hopefully now fixed that as well. This means reverting
the changes to massage.c so is in fact neater anyway. Please check.

Andrew

On 2004-09-07 07:34+0100 Andrew Ross wrote:

> On Mon, Sep 06, 2004 at 04:29:22PM -0700, Alan Irwin wrote:
>> BTW, I asked a question some time ago about the nicest way to establish a
>> symlink in the build tree to the corresponding source tree file (something I
>> need to do to get python in a separate build tree to work properly).  That
>> question was never answered, but if you find a slick way to do it for the
>> present case, it will also help the python case as well.
>
> Under unix the symlink option would be our neatest bet for a lot of
> these build tree / source tree problems. I've always shrunk away from
> this because it doesn't work on windows. I imagine you would have to
> revert the link to a copy there. Do any windows users have any comments
> on this?

The windows build system (in sys/win32/msdev) has always been independent of
the Unix/Linux build system. The only cross-talk I am aware of between the
two build systems is the windows side currently needs the swig-generated
files that are in the tarball, and those wouldn't be necessary if something
were done on the windows side with swig. Anyhow, symlinks generated at build
time in our Unix/Linux build tree to the corresponding source tree
counterparts are not an issue for the independent windows build system.

Alan.
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the PLplot scientific plotting software
package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the
Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

* Alan W. Irwin <ir...@be...> [2004-09-06 16:29]:

> >OK. I didn't realise matwrap was broken in this way. Unfortunately this
> >is partly outside out control, unless we force use of our own copy. I'll
> >look into this further and make sure I thoroughly test building in
> >source tree as well.
> 
> Andrew, I suspect you have already discovered this for yourself, but just to
> be specific, the latest matwrap available on debian-testing (version 0.57-3)
> is only slightly different than bindings/octave/matwrap/matwrap.  Also, I
> just tested that Debian version and it also doesn't recognize the
> dirname/filename version of plplot_octave_rej.h.

I just committed a change to bindings/octave/Makefile.am that may work for a
separate build tree.  Please, try it.  Matwrap is called now with:

    -cpp_ignore $(scrdir) -cpp_ignore plplot_octave_rej.h

This is akin to calling gcc with "-L <dir> -l <file>", but matwrap has a
single option (-cpp_ignore) to specify both directories and files.  What
matwrap does not accept (and that I only discovered after looking at the
Perl code) are constructs like "-cpp_ignore <dir/file>".

-- 
Rafael

* Andrew Roach <aro...@ya...> [2004-09-07 13:27]:

> At 11:16 PM 6/09/2004 +0200, Rafael Laboissiere wrote:
> >A better approach would be to use the native affine transformation of the
> >Postscript language to do arbritrary shear/rotation of characters.  Look at
> >the very simple PS file attached below that I wrote to illustrate my point.
> >Implementing this idea may imply in substantial changes in the core
> >functions of PLplot.  A new PLESC_HAS_AFFINE escape code (let's say) could
> >be introduced and used by drivers that claim to be able to do arbitrary
> >rotation and shear of graphical objects (like PostScript does).
> 
> I do not think we really need a "PLESC_HAS_AFFINE" escape code ? 
> Transformations for text are stored inside "EscText *args" in all text 
> drawing functions anyway, so it is there for anything that wants it. 
> plfreetype simply interrogates these parameters to find out what 
> transformation/shearing is required.

Great, that may simplify a lot the use of native affine transformation in
the ps driver.  BTW, I just notice from the examples (like x18c) that the ps
driver does already rotate the axis labels in 3D plots.  We need only add
shear transformation and the results for the ps driver with "-drvopt text"
will look quite similar to that with the Hershey fonts.

I think that it would be impossible to implement generic shear
transformation of characters in the pstex driver, because it uses the TeX
machinery to render text and TeX does not allow (easily) arbitrary
transformation of the fonts (besides scaling and rotation).

-- 
Rafael

On Mon, Sep 06, 2004 at 04:29:22PM -0700, Alan Irwin wrote:
> On 2004-09-06 22:34+0100 Andrew Ross wrote:
> 
> >OK. I didn't realise matwrap was broken in this way. Unfortunately this
> >is partly outside out control, unless we force use of our own copy. I'll
> >look into this further and make sure I thoroughly test building in
> >source tree as well.
> 
> Andrew, I suspect you have already discovered this for yourself, but just to
> be specific, the latest matwrap available on debian-testing (version 0.57-3)
> is only slightly different than bindings/octave/matwrap/matwrap.  Also, I
> just tested that Debian version and it also doesn't recognize the
> dirname/filename version of plplot_octave_rej.h.
> 
> Looking further into this we have the following quote from the man page:
> 
>        -cpp_ignore filename_or_directory
>            Ignored unless used with the -cpp option.  Causes functions 
>            defined
>            in the given file name or in include files in the given directory
> 	   or subdirectories of it not to be wrapped.  By default, functions
>            defined in "/usr/include", "/usr/local/include", or "*/gcc-lib" 
>            are
> 	   not wrapped.
> 
> So it looks like it is a matwrap design decision to have that option either
> a file or directory, and it may be difficult to recognize the
> dirname/filename version of the filename because of that design decision.
> 
> I agree that with matwrap design decisions like this essentially out of our
> control, a different way (establishing a build tree symlink if the file or
> symlink doesn't already exist in the build tree?) should be found to make a
> separate build tree work.
> 
> BTW, I asked a question some time ago about the nicest way to establish a
> symlink in the build tree to the corresponding source tree file (something I
> need to do to get python in a separate build tree to work properly).  That
> question was never answered, but if you find a slick way to do it for the
> present case, it will also help the python case as well.

Under unix the symlink option would be our neatest bet for a lot of
these build tree / source tree problems. I've always shrunk away from
this because it doesn't work on windows. I imagine you would have to
revert the link to a copy there. Do any windows users have any comments
on this?

Andrew

At 11:14 AM 6/09/2004 -0700, Alan W. Irwin wrote:
>into PLplot.  As I understand it, Andrew (Roach) was close to getting that
>done this summer, but then other PLplot interests (such as the new gif
>device) distracted him.

It is still sitting there on the back burner (don't give up yet). My "quick 
fix" effort was sunk though by some minor problems with the opensource 
unicode library.

>Also, I would like to encourage those who are familiar with writing PLplot
>device drivers to extend our ps device driver to use plfreetype since that
>is one of our most heavily used device drivers.  Andrew, how difficult would
>this be?  Is the documentation at
>http://plplot.sourceforge.net/docbook-manual/plplot-html-5.3.1/freetype-notes.html
>reasonably up to date for the steps you would have to take?

Those documents are pretty up to date and work 100% ok with non-interactive 
devices that do not require refreshes. Any driver that uses bitmaps and has 
a setpixel function should be able to support freetype with the addition of 
a few lines of code.

In adding freetype support to the wingcc driver I did need to expand the 
freetype driver a little by adding a local text cache. When a refresh 
command is requested (usually by windows) within the wingcc driver, I 
simply replayed the plot buffer and redraw everything; unfortunately, the 
text was not buffered because plplots own buffer only stores draw commands 
- hence the need for the local text buffer. The changes (from the above 
docs) needed to make a device driver support the text cache are minimal, as 
freetype itself decides if text buffering is required. In the case of 
wingcc, before I added the text cache the replot function was:

                 if (dev->waiting==1)
                 {
                     plRemakePlot(pls);
                  }

then after it became:

                 if (dev->waiting==1)
                 {
                     plRemakePlot(pls);
                     #ifdef HAVE_FREETYPE
                     pl_RemakeFreeType_text_from_buffer(pls);
                     #endif
                  }

So in short, if you wanted to add freetype to an interactive bitmap 
terminal that needed cachingof plot commands, you would need to add just 
one extra line of code beyond what is currently in the documentation. I'll 
update the docs to reflect this, but if anyone were interested in adding 
support to an interactive device, look at wingcc.c rather than gd.c.

At 11:16 PM 6/09/2004 +0200, Rafael Laboissiere wrote:
>A better approach would be to use the native affine transformation of the
>Postscript language to do arbritrary shear/rotation of characters.  Look at
>the very simple PS file attached below that I wrote to illustrate my point.
>Implementing this idea may imply in substantial changes in the core
>functions of PLplot.  A new PLESC_HAS_AFFINE escape code (let's say) could
>be introduced and used by drivers that claim to be able to do arbitrary
>rotation and shear of graphical objects (like PostScript does).


I do not think we really need a "PLESC_HAS_AFFINE" escape code ? 
Transformations for text are stored inside "EscText *args" in all text 
drawing functions anyway, so it is there for anything that wants it. 
plfreetype simply interrogates these parameters to find out what 
transformation/shearing is required.

-Andrew Roach

On 2004-09-06 22:34+0100 Andrew Ross wrote:

> On Mon, Sep 06, 2004 at 11:14:01PM +0200, Rafael Laboissiere wrote:
>> * Alan W. Irwin <ir...@be...> [2004-09-06 13:43]:
>>
>>> * I believe to avoid breaking the separate build tree case for octave,
>>> Rafael's recent commit for Makefile.am should be reverted. Instead, I
>>> believe the fix should be made in the bindings/octave/matwrap/matwrap perl
>>> script to recognize forms like dirname/filename to access the
>>> plplot_octave_rej.h file.
>>
>> I went ahead and committed the patch because Joao was completely right: the
>> $(srcdir)/plplot_octave_rej.h change made by Andrew Ross three days ago
>> broke indeed the building of the Octave binding in the source tree. This is
>> not acceptable because building in the source tree is by far the most
>> current case (Debian packaging, casual users having CVS checked out, etc).
>> We must find another solution for building PLplot in all possible
>> situations, perhaps along the lines of your suggestion above.  For now,
>> please, do not revert my last change.

Understood, Rafael.

>
> OK. I didn't realise matwrap was broken in this way. Unfortunately this
> is partly outside out control, unless we force use of our own copy. I'll
> look into this further and make sure I thoroughly test building in
> source tree as well.

Andrew, I suspect you have already discovered this for yourself, but just to
be specific, the latest matwrap available on debian-testing (version 0.57-3)
is only slightly different than bindings/octave/matwrap/matwrap.  Also, I
just tested that Debian version and it also doesn't recognize the
dirname/filename version of plplot_octave_rej.h.

Looking further into this we have the following quote from the man page:

        -cpp_ignore filename_or_directory
            Ignored unless used with the -cpp option.  Causes functions defined
            in the given file name or in include files in the given directory
 	   or subdirectories of it not to be wrapped.  By default, functions
            defined in "/usr/include", "/usr/local/include", or "*/gcc-lib" are
 	   not wrapped.

So it looks like it is a matwrap design decision to have that option either
a file or directory, and it may be difficult to recognize the
dirname/filename version of the filename because of that design decision.

I agree that with matwrap design decisions like this essentially out of our
control, a different way (establishing a build tree symlink if the file or
symlink doesn't already exist in the build tree?) should be found to make a
separate build tree work.

BTW, I asked a question some time ago about the nicest way to establish a
symlink in the build tree to the corresponding source tree file (something I
need to do to get python in a separate build tree to work properly).  That
question was never answered, but if you find a slick way to do it for the
present case, it will also help the python case as well.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the PLplot scientific plotting software
package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the
Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

On Mon, Sep 06, 2004 at 11:14:01PM +0200, Rafael Laboissiere wrote:
> * Alan W. Irwin <ir...@be...> [2004-09-06 13:43]:
> 
> > * I believe to avoid breaking the separate build tree case for octave,
> > Rafael's recent commit for Makefile.am should be reverted. Instead, I
> > believe the fix should be made in the bindings/octave/matwrap/matwrap perl
> > script to recognize forms like dirname/filename to access the
> > plplot_octave_rej.h file.
> 
> I went ahead and committed the patch because Joao was completely right: the
> $(srcdir)/plplot_octave_rej.h change made by Andrew Ross three days ago
> broke indeed the building of the Octave binding in the source tree. This is
> not acceptable because building in the source tree is by far the most
> current case (Debian packaging, casual users having CVS checked out, etc).
> We must find another solution for building PLplot in all possible
> situations, perhaps along the lines of your suggestion above.  For now,
> please, do not revert my last change.

OK. I didn't realise matwrap was broken in this way. Unfortunately this
is partly outside out control, unless we force use of our own copy. I'll
look into this further and make sure I thoroughly test building in
source tree as well.

Andrew

* Alan W. Irwin <ir...@be...> [2004-09-06 11:14]:

> Also, I would like to encourage those who are familiar with writing PLplot
> device drivers to extend our ps device driver to use plfreetype since that
> is one of our most heavily used device drivers.  Andrew, how difficult would
> this be?  Is the documentation at
> http://plplot.sourceforge.net/docbook-manual/plplot-html-5.3.1/freetype-notes.html
> reasonably up to date for the steps you would have to take?

I am not sure that using the plfreetype support in the ps-related drivers is
a good idea.  plfreetype.c implements a bitmap-oriented rendering of the
fonts, while the ps driver is vectorized.  Although it could be possible to
implement your idea, it would result in two drawbacks: first, bitmaps would
be included in the resulting PS file for each character rendered, perhaps
with an unacceptable increase in size.  Second (and worst), the result could
look awful.

A better approach would be to use the native affine transformation of the
Postscript language to do arbritrary shear/rotation of characters.  Look at
the very simple PS file attached below that I wrote to illustrate my point.
Implementing this idea may imply in substantial changes in the core
functions of PLplot.  A new PLESC_HAS_AFFINE escape code (let's say) could
be introduced and used by drivers that claim to be able to do arbitrary
rotation and shear of graphical objects (like PostScript does).

This is a great project for someone with plenty of free time, which is not
my case...

-- 
Rafael

* Alan W. Irwin <ir...@be...> [2004-09-06 13:43]:

> * I believe to avoid breaking the separate build tree case for octave,
> Rafael's recent commit for Makefile.am should be reverted. Instead, I
> believe the fix should be made in the bindings/octave/matwrap/matwrap perl
> script to recognize forms like dirname/filename to access the
> plplot_octave_rej.h file.

I went ahead and committed the patch because Joao was completely right: the
$(srcdir)/plplot_octave_rej.h change made by Andrew Ross three days ago
broke indeed the building of the Octave binding in the source tree. This is
not acceptable because building in the source tree is by far the most
current case (Debian packaging, casual users having CVS checked out, etc).
We must find another solution for building PLplot in all possible
situations, perhaps along the lines of your suggestion above.  For now,
please, do not revert my last change.

-- 
Rafael

On 2004-09-06 18:57+0100 Jo=E3o Cardoso wrote:

> Hi,
>
> I coulnd't reproduce (in the build tree) the reported problem. The GIF
> device works fine for me with any of the x??c Octave demos.

Actually, that was everybody else's experience as well.  Gif seems fine wit=
h
the low-level (x example) interface.

>
> I had to download, compile and install gd-2.0.28 in order to have GIF
> support. Perhaps the problem is the gd library version?

My tests have always been for that version (Debian testing version,
2.0.28-2).

>
> I had however some other problems to compile plplot_octave --- strange
> that nobody else reported it. I had to change the matwrap options in
> order to have no errors, as the other attached patch shows.

I don't understand why this patch (just committed by Rafael) is now
required. (It wasn't the last time I ran a complete check which I think was
sometime in the last week or so.) The only change is you replace
$(srcdir)/plplot_octave_rej.h by plplot_octave_rej.h. On my system, with a
build in the source tree, $(srcdir) reduces to ".", but somehow that is now
confusing the local bindings/octave/matwrap/matwrap perl script.  Could we
fix that script instead?  If we do it that way, we don't break
the separate build tree case.

> cd plplot/bindings/octave
> octave
octave:1>  fig(1,"gif","foo.gif"); plSetOpt("fam","1"); p7; closefig

> This generates two GIF files/images. The p7 demo changes the colormap,=20
> so one should be able to see different colormap in each of the
> generated files. However, this does not happens, both figures have the
> same (last set) colormap, but that is is a problem of the GIF driver
> and not of octave.

I confirm that there appears to be a colour map problem with p7 both in the
gif and png devices when compared to the psc device results.  However, the
octave logic for that plot is still problematic; if you look at the results
of the first page (even in postscript) there seems to be two different sets
of labels superimposed on each other.  I would like to see those p7.m logic
problems straightened out before we come to any conclusions about how gif
and png handle colour maps. For example, those devices do just fine for the
python/xw08.py example where the colour map is reset several times.

> [out of order]
> With the p?? Octave demos there is also no problem, if we apply the
> attached patch.

This figure.m patch (just committed to cvs by Rafael) works for me.
plplot-test.sh now goes through without any problems with the gif device.
The "p" example results (for all devices including postscript) are now much
better.  Also, valgrind results (within the noise created by memory
management problems in octave itself) seem okay for this simple test that
did not work before:

valgrind --num-callers=3D10 octave -f -q -p $octavedir
toggle_plplot_use
figure (1, "psc", "foo.ps");
colormap (ones (10, 3));
closefig
ctrl-d

Thanks Joao, for finding the fix to this subtle problem!

In sum, the principal problem seems to have been addressed by Joao's
figure.m change, but there remain some other issues.

* I believe to avoid breaking the separate build tree case for octave,
Rafael's recent commit for Makefile.am should be reverted. Instead, I
believe the fix should be made in the bindings/octave/matwrap/matwrap perl
script to recognize forms like dirname/filename to access the
plplot_octave_rej.h file.

* the problems with the p7 logic need to be addressed.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the PLplot scientific plotting software
package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the
Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

On 2004-09-06 19:00+0100 Andrew Ross wrote:

> On Mon, Sep 06, 2004 at 08:53:10AM -0700, Alan Irwin wrote:
>> I have a lot of fortran-77 programming experience, but little fortran 90
>> experience.  Nevertheless, my understanding is that f90 is a pure extension
>> to f77 so wouldn't the present interface (or one based on cfortran.h) just
>> work with f90?  (In fact, I am positive some of our users have used absoft
>> f90 to build our fortran interface and fortran examples.)
>>
>> That said, I can see where one of the f90/f95 extensions might be useful to
>> our interface.  For example, from the F95_Reference.pdf manual from absoft,
>> there appears to be something called assumed shape arguments which would
>> allow us to drop array dimension information from our fortran interface API
>> (similar to what we do now in python and java), and I would be keen to see
>> an additional fortran interface with that simplification.  However,
>> assumed-shape arguments apparently also require something called interface
>> blocks, and I don't know how difficult those are to work with when building
>> a fortran interface to our PLplot library.
>>
>> Arjen, does cfortran.h allow the use of assumed shape arguments or would
>> that be a lot of work to implement?  Also, is there any other f90 extension
>> that would be useful for simplifying our fortran interface API?
>>
>> Whether or not we decide to add an f90 interface using the f90 extensions to
>> simplify our argument lists or stick with our current fortran API, a version
>> of our fortran examples written taking advantage of all f90 extensions would
>> be most welcome.
>
> I'd think of it as similar to the C/C++ situation. With f90 we can
> encapsulate the plplot api in a plplot module to provide something
> vaguely akin to a C++ class. Similarly we _could_ use the C API in C++,
> it's just the Object Orientated approach and the extra language features
> are nice.

In my very quick reading this morning about f90 I noticed a chapter on
modules, but I skipped it.  Would a PLplot fortran 90 module allow us to
sort out the fortran streams situation similar to what you did in the C++
interface?

Even if that is not what you had in mind, I will take your word for it that
a PLplot fortran 90 module would be good in general. The question remains
would a fortran 90 PLplot module and the assumed-shape argument extension
for arrays be something that could be implemented using cfortran.h?

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the PLplot scientific plotting software
package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the
Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

I just tried the following experiment:

./x08c -dev pstex -o test.pstex -fam -fsiz 2k
pstex2eps test.pstex.1
gv test.pstex.1.eps

and all the axes have bad-looking labels because of 3D rotation problems
with the pstex device.

I am not sure whether it is worth fixing this device since few are using it
(or if anybody is using it, they haven't complained about the above
bad-looking results).

For those who just want good-looking font results, another option is using
the devices (png, jpeg, gif) associated with the gd device driver and the
-drvopt text or -drvopt text,smooth command-line options to use plfreetype
(as a front-end to libfreetype2) to specify the fonts.  plfreetype gives
good-looking png results for my research plots. However, specification of
mathematical symbols and non-English language symbols within PLplot is
difficult for general true-type fonts until we can introduce unicode support
into PLplot.  As I understand it, Andrew (Roach) was close to getting that
done this summer, but then other PLplot interests (such as the new gif
device) distracted him.

Also, I would like to encourage those who are familiar with writing PLplot
device drivers to extend our ps device driver to use plfreetype since that
is one of our most heavily used device drivers.  Andrew, how difficult would
this be?  Is the documentation at
http://plplot.sourceforge.net/docbook-manual/plplot-html-5.3.1/freetype-notes.html
reasonably up to date for the steps you would have to take?

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the PLplot scientific plotting software
package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the
Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

On Mon, Sep 06, 2004 at 08:53:10AM -0700, Alan Irwin wrote:
> On 2004-09-06 08:38+0100 Andrew Ross wrote:
> 
> >I agree with Arjen that we should seriously look into a f90/95 module.
> >This is currently one of the major bindings lacking. I know you can use
> >the f77 support, but proper f90 support would be useful. I've thought
> >about this myself, but not got to the point of implementing anything. If
> >you have ideas though Arjen I'm happy to help.
> 
> I have a lot of fortran-77 programming experience, but little fortran 90
> experience.  Nevertheless, my understanding is that f90 is a pure extension
> to f77 so wouldn't the present interface (or one based on cfortran.h) just
> work with f90?  (In fact, I am positive some of our users have used absoft
> f90 to build our fortran interface and fortran examples.)
> 
> That said, I can see where one of the f90/f95 extensions might be useful to
> our interface.  For example, from the F95_Reference.pdf manual from absoft,
> there appears to be something called assumed shape arguments which would
> allow us to drop array dimension information from our fortran interface API
> (similar to what we do now in python and java), and I would be keen to see
> an additional fortran interface with that simplification.  However,
> assumed-shape arguments apparently also require something called interface
> blocks, and I don't know how difficult those are to work with when building
> a fortran interface to our PLplot library.
> 
> Arjen, does cfortran.h allow the use of assumed shape arguments or would
> that be a lot of work to implement?  Also, is there any other f90 extension
> that would be useful for simplifying our fortran interface API?
> 
> Whether or not we decide to add an f90 interface using the f90 extensions to
> simplify our argument lists or stick with our current fortran API, a version
> of our fortran examples written taking advantage of all f90 extensions would
> be most welcome.

I'd think of it as similar to the C/C++ situation. With f90 we can
encapsulate the plplot api in a plplot module to provide something
vaguely akin to a C++ class. Similarly we _could_ use the C API in C++,
it's just the Object Orientated approach and the extra language features 
are nice.

Andrew