Menu
▾
▴
plplot-general
|
From: Valery P. <pi...@is...> - 2006-08-03 04:30:34
|
Dear All,
The following line is perfectly work for ps driver ( plsdev("ps") ) at 5.3.1:
pllab("TIME, [YR]", "[Wb#u2#d]","#(2412)#(2229)h#d#(2053)#u#(2229)dV#dCZ#u")
For 5.6.1 the chars #(2053) and #(2229) does not work.
I've tried this for python and for yplot. I'm able to reproduce the example
7 for given implementions of plplot-5.6.1. I'm in puzzle why in 5.6.1 some of
chars does not work when I call them in pllab
best regards
Valery
|
|
From: Alan W. I. <ir...@be...> - 2006-08-03 07:43:01
|
On 2006-08-03 13:30+0900 Valery Pipin wrote:
> Dear All,
>
> The following line is perfectly work for ps driver ( plsdev("ps") ) at 5.3.1:
> pllab("TIME, [YR]", "[Wb#u2#d]","#(2412)#(2229)h#d#(2053)#u#(2229)dV#dCZ#u")
>
> For 5.6.1 the chars #(2053) and #(2229) does not work.
> I've tried this for python and for yplot. I'm able to reproduce the example
> 7 for given implementions of plplot-5.6.1. I'm in puzzle why in 5.6.1 some of
> chars does not work when I call them in pllab
>
> best regards
> Valery
Hi Valery:
I get a slightly different result with the CVS version of PLplot: #(2229)
(vertical bar) works okay, but #(2053) (italic upper case C) does not.
To solve the problem I suggest you use -drvopt text=0 which enforces Hershey
fonts in all cases. That option is what you want to reproduce legacy plots
exactly.
The fundamental issue is that the Adobe Type 1 fonts are not as complete as
the Hershey fonts. To get pure Hershey fonts (as in 5.3.1) use the option
-drvopt text=0. To get pure Adobe type 1 fonts in all cases (both symbols
and text) use -drvopt hrshsym=0. If you use that option for example 7, you
will see just how many glyphs are missing for the Adobe fonts. The default
is -drvopt text=1 (Adobe fonts for text) and -drvopt hrshsym=1 (Hershey
fonts for symbols) which is why example 7 looks okay by default, but text as
in your example above may be missing some glyphs. Typically, symbols are
used to label points in plots so we provided hrshsym=1 by default so that at
least those symbols would be complete (although ugly). For text as in
labels, however, Adobe type 1 fonts are the default since the results
normally look a lot better than the ugly Hershey fonts (unless a glyph is
missing for the Adobe font).
For new plots I suggest you abandon -dev psc and use -dev psttfc instead.
You then are allowed to specify the labels and symbols with either UTF8
strings or else the #[nnn] notation mixed in with FCI's #<0x8nnnnnnn> to
change fonts in mid-string (see
http://plplot.sourceforge.net/docbook-manual/plplot-html-5.6.1/characters.html).
This gives you a completely flexible way to specify the labels and symbols
that you want in the fonts (e.g., upright or italic) that you want. The
other advantage of -dev psttfc is it uses TrueType fonts which tend to be
much more complete than either Hershey or Adobe type 1 fonts.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); 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
__________________________
|
|
From: Valery P. <pi...@is...> - 2006-08-03 08:42:14
|
Hello Alan,
Thanks for the quick help!
> I get a slightly different result with the CVS version of PLplot: #(2229)
> (vertical bar)
Yes it is also works for me. I wanted to refer the char #(2104) for
differential
> works okay, but #(2053) (italic upper case C) does not.
>
> To solve the problem I suggest you use -drvopt text=0 which enforces
> Hershey fonts in all cases.
where should I place this option? Can I use plparseopts?
> For new plots I suggest you abandon -dev psc and use -dev psttfc instead.
I found psttf drivers are problematic to use.
pllab("TIME,
[YR]", "[Wb#u2#d]","#(2412)#(2229)h#d#(2053)#u#(2229)#(2104)V#dCZ#u")
gives quite ugly results for ps file. The characters itself look very well
but there combination does not.
Another problem for me with the collor ps drivers that I could not find the
simple way to get the black color (with white background).
For plplot5.3.1 in yplot I find that plscol0,1,1,1,1 gives the perfectly
black color. However its python conterpart plscol0(1,1,1,1) gives gray
color.
> You then are allowed to specify the labels and symbols with either UTF8
> strings or else the #[nnn]
However the proposed table of characters is not as complete as the Hershey
table.
best regards,
Valery
|
|
From: Alan W. I. <ir...@be...> - 2006-08-03 15:05:46
|
On 2006-08-03 17:42+0900 Valery Pipin wrote:
> Hello Alan,
>
> Thanks for the quick help!
>> I get a slightly different result with the CVS version of PLplot: #(2229)
>> (vertical bar)
> Yes it is also works for me. I wanted to refer the char #(2104) for
> differential
>> works okay, but #(2053) (italic upper case C) does not.
>>
>> To solve the problem I suggest you use -drvopt text=0 which enforces
>> Hershey fonts in all cases.
> where should I place this option? Can I use plparseopts?
hmmm. I am sure there is an internal way to specify it, but I always just
specify it on the command line.
>> For new plots I suggest you abandon -dev psc and use -dev psttfc instead.
> I found psttf drivers are problematic to use.
> pllab("TIME,
> [YR]", "[Wb#u2#d]","#(2412)#(2229)h#d#(2053)#u#(2229)#(2104)V#dCZ#u")
> gives quite ugly results for ps file. The characters itself look very well
> but there combination does not.
The old #(nnnn) notation has some internal limitations. You have to move to
the new scheme (UTF8 strings or #[nnn] with FCI's) to get complete results
for special characters with the unicode fonts.
>
> Another problem for me with the collor ps drivers that I could not find the
> simple way to get the black color (with white background).
> For plplot5.3.1 in yplot I find that plscol0,1,1,1,1 gives the perfectly
> black color. However its python conterpart plscol0(1,1,1,1) gives gray
> color.
The first index in cmap0 is the special background colour index, and it must
be set before plinit in order for it to work at all. The simple way is
to use the -bg option on the command line. (Use the -h option on the
command line to see all the options available.)
>
>> You then are allowed to specify the labels and symbols with either UTF8
>> strings or else the #[nnn]
> However the proposed table of characters is not as complete as the Hershey
> table.
There are literally millions of unicode glyph possibilities which are now
accessible with PLplot. (Example 23 is only a tiny subset of what is
possible with -dev psttfc.) Also, unicode is the standard so if people
actually want to use a glyph it tends to be represented in the unicode
tables of glyphs. That said, I agree that some of the more exotic Hershey
glyphs are not represented in the unicode glyphs (or we haven't found them
yet in the millions of possibilities), but I doubt those glyphs are used by
too many people if they are not already in the unicode tables.
I highly recommend trying the gucharmap GUI to see all the unicode glyph
possibilities available for the fonts installed on your system. Those glyph
possibilities are _all_ accessible with PLplot and the #[nnn] scheme.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); 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
__________________________
|
|
From: Alan W. I. <ir...@be...> - 2006-08-03 17:19:57
|
On 2006-08-03 08:05-0700 Alan W. Irwin wrote: >> Another problem for me with the collor ps drivers that I could not find the >> simple way to get the black color (with white background). >> For plplot5.3.1 in yplot I find that plscol0,1,1,1,1 gives the perfectly >> black color. However its python conterpart plscol0(1,1,1,1) gives gray >> color. > > The first index in cmap0 is the special background colour index, and it must > be set before plinit in order for it to work at all. The simple way is > to use the -bg option on the command line. (Use the -h option on the > command line to see all the options available.) > I answered this part of your post too quickly without much thought. Obviously, it is the zero index which is the background so my comment about that case is not relevant to your issue. To answer your original question, to get black on white results just use -dev ps or -dev psttf rather than -dev psc or -dev psttfc. Note also to get true black you should specify plscol0(index,0,0,0), although since the allowed range is 0-255 (see http://plplot.sourceforge.net/docbook-manual/plplot-html-5.6.1/plscol0.html), specifying plscol0(index,1,1,1) should be indistinguishable from true black. I have just checked that with python, and that is indeed the case on my system with both -dev xwin and -dev psttfc. I had to change to plscol0(1,100,100,100) to get a grey result. I have no idea why you are getting a grey result with plscol0(1,1,1,1). Could you give more specifics such as a simple python test code that produces that result? Also, tell us your PLplot version, the devices that produce the grey result, etc. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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 __________________________ |
|
From: Valery P. <pi...@is...> - 2006-08-04 02:34:51
|
Dear Alan,
thanks for the help. The problem with colors is solved, indeed, if I put
plscol0(1,0,0,0); before definitions for device and plinit();
I don't understand why it works. I have to read the documentaion.
The grey color was resulted from the subsequent calls of several plplot-python
routines in one buffer. I thought that definitions for colors are reseted
after plend().
> > pllab("TIME,
> > [YR]", "[Wb#u2#d]","#(2412)#(2229)h#d#(2053)#u#(2229)#(2104)V#dCZ#u")
> > gives quite ugly results for ps file. The characters itself look very
> > well but there combination does not.
>
> The old #(nnnn) notation has some internal limitations. You have to move to
> the new scheme (UTF8 strings or #[nnn] with FCI's) to get complete results
> for special characters with the unicode fonts.
I think it is not only about internal limitations of #(nnnn).
The problem is that "[Wb#u2#d]" looks ugly as well for psttf drivers (at least
in my case)
best regards
Valery
|
|
From: Alan W. I. <ir...@be...> - 2006-08-04 14:27:41
|
On 2006-08-04 11:34+0900 Valery Pipin wrote: > I think it is not only about internal limitations of #(nnnn). > The problem is that "[Wb#u2#d]" looks ugly as well for psttf drivers (at least > in my case) I confirm this problem with the psttf device driver. Also, "[Wb#d2#u]" shows the same problem for subscripts. The horizontal spacing is not done properly after the superscript or subscript so the bracket is written right over the superscript or subscript 2. That's curious because many aspects of the psttf driver are based on the ps device driver, and the problem does not occur for -dev ps(c). Anyhow, you have found a clear bug for the psttf device driver that should be fixed. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2006-08-07 18:17:28
|
On 2006-08-04 07:27-0700 Alan W. Irwin wrote: > On 2006-08-04 11:34+0900 Valery Pipin wrote: > >> I think it is not only about internal limitations of #(nnnn). >> The problem is that "[Wb#u2#d]" looks ugly as well for psttf drivers (at least >> in my case) > > I confirm this problem with the psttf device driver. Also, "[Wb#d2#u]" > shows the same problem for subscripts. I was dismayed I didn't spot this issue when we first released the psttf device, but no pre-release testing is perfect, and this is a nice example of how PLplot users can do us a great service by speaking up about issues that they find. Andrew Ross has kindly fixed this psttf bug in CVS, and I confirm that the subscript and superscript horizontal spacing is now correct. Valery, will you give the cvs version of PLplot a try and let us know if you have any other concerns about the psttf device driver? We want everything to be correct for this device because when it matures it will probably be our showcase device with so many nice-looking glyphs available for plotting (if you stick to UTF8 or the #[nnnnnn] notation), with easy access to TrueType fonts (via libfontconfig), and with automatic complex text layout (CTL) capability via libpango. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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 __________________________ |
|
From: Valery P. <pi...@is...> - 2006-08-08 06:59:07
|
Dear Alan, Dear Andrew, Thank you very much for the quick fix of the problem. It also fixes the absence some of hershey chars in psttf driver (I mentioned them in my first message). I've tried two different way to build plplot. The usual way is to use cf/bootstrap.sh. and ./configure --with-freetype-font-dir=/usr/share/fonts/default/TrueType-freefont --with-psttf It works for me. I've tried cmake as well. cmake do't want to put "ON" the options for dyndrivers, for python binding, for freetype support and for psttf. It is not clear how to do it. Note that I was able to activate these options via the usual configure best regards Valery |
|
From: Alan W. I. <ir...@be...> - 2006-08-08 16:30:10
|
On 2006-08-08 15:59+0900 Valery Pipin wrote: > I've tried cmake as well. cmake do't want to put "ON" the options for > dyndrivers, for python binding, for freetype support and for psttf. All options can be set with cmake -D options. However, the ccmake command-line interface is much more convenient because it displays default values and documentation strings for all variables that you can change. However, the necessary resources must be installed and accessible (see comments below) or some of these options will be turned OFF (with a WARNING message) even when the default is ON or you specify ON. By default, the CMake build system uses dyndrivers, builds the psttf device driver, builds the python binding, and uses libfreetype. So I presume all of those are being turned off internally for your CMake build because it is unable to find certain resources. Look for WARNING messages when you run cmake (or ccmake). For example, dyndrivers gets turned off if libltdl is not installed on your system. (The autotools build system, builds a copy of this library internally from libtool source, but CBS needs an installed version.) The psttf device is only built for the dyndrivers case (and also requires libLASi to be found). Our python interface is only built if swig is installed on your system. I need a look at your WARNING messages, but I presume the freetype library is not being found by CMake on your system because you need to specify (via ccmake) a font path and/or font file names. (We didn't have this capability before, but I just committed a change to implement that.) Finally, if anything is installed in non-standard locations you need to specify the environment variables CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH (documented in http://www.cmake.org/Wiki/CMake_Useful_Variables) to help the PLplot CMake build system to find it. If you have further trouble with the CMake build system feel free to contact me off list with all the details (complete cmake output), and I should be able to help you get it to work so you can enjoy the extraordinary configuration speed of CMake. By the way, I implemented the Tcl component of the PLplot CBS this weekend. That leaves just the implementation of the Tk component (next few days), the octave component, and the wxwidgets device driver to complete our CBS on Linux. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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 __________________________ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X