Re: [Plplot-devel] Legends
On Oct 5, 2010, at 21:42 , Alan W. Irwin wrote: > On 2010-10-05 22:19-0400 Schwab,Wilhelm K wrote: > >> I was interested in building it (5.9.7) to try the legend code. >> Is there a reason for the double pointer? It seems that >> >> this part\0that part\0...\0and the last part\0\0 >> >> would do the job just as easily?? > > I am willing to keep an open mind about changing the > present approach if we run into trouble interfacing const char ** > text to > other languages. FWIW, I vote for keeping it as char**. For the smallish amounts of legend text it probably doesn't matter that much either way, but with more and/or larger strings that might come from different locations, the cost of copying into one buffer can become significant. Creating an array of char* and populating with pointers into a long buffer containing back-to-back strings is not nearly so onerous (presuming you know how many strings you have to begin with so you can allocate a big enough char* array). Does the library strdup the passed in strings, render them before returning, or just copy the pointers for later rendering? Thanks, Dave (who has obviously not examined the legend implementation!) -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Legends
On 2010-10-05 22:19-0400 Schwab,Wilhelm K wrote: > I was interested in building it (5.9.7) to try the legend code. Is there a > reason for the double pointer? It seems that > > this part\0that part\0...\0and the last part\0\0 > > would do the job just as easily?? I guess arranging a string with a bunch of null terminations scattered through out it to delimit the parts would work, but to me that seems a less standard approach than simply using an array of pointers to strings. My feeling is the present approach will interface well with standard string handling methods for the various languages we support. That proved to be the case for python/numpy since that combination has an object (a numpy array of pointers to strings) which maps quite well to the present const char ** text. However, that is only one interfacing case so far, and I am willing to keep an open mind about changing the present approach if we run into trouble interfacing const char ** text to other languages. 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Legends
I started out trying to build the new release and did not get far with the instructions on the wiki. Then I found this: http://www.linuxquestions.org/questions/linux-newbie-8/unable-to-install-and-build-plplot-5-9-a-789425/ Building plplot-5.9.5 : 1) cd plplot-5.9.5/ , 2) mkdir build 3) cd build/ , 4) cmake .. ( cmake ) The text output in the terminal will show, what's included in the configuration / Makefile : tcl/tk , wxwidgets, pyqt4, python, etc. 4) make : will build the binaries and the libraries. My own addition was then sudo make install which *appears* to have worked. I was interested in building it to try the legend code. Is there a reason for the double pointer? It seems that this part\0that part\0...\0and the last part\0\0 would do the job just as easily?? Bill -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Greek characters in qt-driver
On 2010-10-05 20:29+0100 Schwartz, Steven J wrote: > Should plplot draw it's Greek theta from a script-like font when all the other Greek symbols (bar uppercase upsilon) are drawn from the default sans serif font? Would it look strange to a Greek person to see a word spelled with this mixture of fonts? > I suspect I'm the only one who might have noticed :-) Actually, I notice these things as well, but that was a deliberate change. If you look at the 600 section or 2100 section of example 7 with -dev xwin (i.e, Hershey fonts), you will see that there are two versions of episilon, theta, and phi available for the Hershey fonts. I changed the Hershey to unicode transformation to match those two variations of the three glyphs as closely as possible, and I have just confirmed that sections 600 and 2100 of example 7 give Greek letter variants for the qt and cairo devices that are in at least the same spirit of the Greek letter variants you see for -dev xwin. In other words, the point of plsym (and plpoin) for unicode-aware devices is to match what is done for the Hershey devices (whether right or wrong) as closely as possible for the best backwards compatibility. That is, if people went out of their way to use what they considered to be the best variation of Greek letters with Hershey devices, they could rely on that behaviour continuing with unicode-aware devices. Note also these Greek-letter variations are all available in the same font. So it is not a matter of suddenly changing fonts in the middle of a string. Instead, it is using the same font with different Hershey and therefore UCS4 indices representing different variant forms of Greek letters depending upon what the user wants to do. All this will be much clearer with the planned plglyph functionality. There, you will get whatever unicode glyph corresponds to the UCS4 index you specify. So typically you would window-shop in gucharmap until you find a glyph you like taking into account all variants mentioned in the character details. Then you use the UCS4 index of that glyph directly in the call to plglyph for your plot. Of course, the user of plglyph will still be subject to possible mistakes in how a given font designer renders the glyph. Also, the qt and cairo devices use generic fonts where an external library (e.g., fontconfig for cairo) decides on the best sans or serif choice to represent the glyph. That potentially means you could get several different fonts used in the same text string if a higher-ranked font had a lot of glyphs missing so you had to fall back to a lower-ranked fonts for some of the glyphs. But in practice that happens rarely since most OS's only deploy True-Type font choices with relatively large glyph coverage. To end on a philosphical note, I used to ignore fonts altogether back in the dark ages when there was no choice other than Hershey for PLplot. But I have become completely enthused about fonts now that PLplot gives access to such a wide variety of them that represent ~500 years of artistic and mathematical tradition. Totally cool! 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Greek characters in qt-driver
Hi Alan Ok as I suspected it is a qt issue and I agree that the qt3 Oct 2010, at 21:01, "dabergs...@comcast. guys mostly make positive improvements - although the migration of our code from Qt3 to Qt4 was far from painless. Since we bundle plplot with our software and deal with a variety of users who won't want to fetch/install alternate qt installations we'll run with my workaroumd for the time being. Thanks for the confirmation that it should work on newer installations - I may check my own qt installation to see if I can configure it to pick up the necessary fonts. It leaves me with a more philosophical and aesthetic question that I pose without malice: Should plplot draw it's Greek theta from a script-like font when all the other Greek symbols (bar uppercase upsilon) are drawn from the default sans serif font? Would it look strange to a Greek person to see a word spelled with this mixture of fonts? I suspect I'm the only one who might have noticed :-) Regards Steve --- Steve Schwartz Space and Atmospheric Physics Imperial College London Tel 020 7594 7660 On 5 Oct 2010, at 19:00, "Alan W. Irwin" wrote: > On 2010-10-05 13:02+0100 Steve Schwartz wrote: > >> [...]Gucharmap shows both >> the symbols and alternatives, and the xcairo driver finds them, so I >> guess they reside somehow on my system but not accessed by my version of >> qt (4.5.3). > > I used to encounter this same difficulty (Qt was not as good at > finding system fonts as xcairo and gucharmap). I speculate that older > versions of Qt used their own library for finding system fonts and not > the standard fontconfig library that is used by xcairo and gucharmap > or else Qt used fontconfig in a poorly configured way. However, for > Qt-4.6.3 (the version that comes with Debian testing) I have not > encountered this issue. For example, the Hershey numbers below are > all rendered fine with example 7 and -dev qtwidget. > >> Hershey numbersplplot5.9.7 unicode change to this >> 46, 546 0x03d2 0x03a5 Upsilon >> 534 0x03d1 0x03b8 theta >> 98, 684, 21840x03f5 0x03b5 epsilon >> 686, 21860x03d5 0x03c6 phi variant > > As you can see from Section 2.28 of our release announcement, later > versions of Qt seem to solve a number of issues we see for earlier > versions of Qt so the fix for this font-finding issue appears to be > just one more fix in the series of Qt improvements that also doesn't > seem to have introduced any regressions (at least up to 4.6.3). So > TrollTech/Nokia seem to have a pretty good track record for > constantly improving Qt4. > > The Qt download site at http://qt.nokia.com/downloads/ gives you > access to the latest Qt version (currently 4.7.0) in binary form. If > that version works well for you (i.e., solves the above issue without > introducing any regressions), then you might want to recommend it to > your QSAS users that don't have access to Qt-4.6.3 or above from their > distribution. Alternatively, you could temporarily deploy the above > workaround until essentially all distros have updated to 4.6.3 or > above. > > Finally, these issues remind me again that plpoin and plsym access > unicode glyphs in an indirect and extremely limited way. Therefore, I > have decided it is long past time we introduced a new function > plglyph(n, x, y, ucs4) which allowed plotting glyphs corresponding to > the ucs4 index for those drivers which are unicode aware. Such a > function would allow users full and direct access to the extremely > wide variety of generic sans and serif glyphs that are available on > their system for unicode-aware device drivers like qt (with Qt-4.6.3 > or later) or cairo. I will try implementing a first cut at plglyph > later today. > > 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 libLASi project (unifont.org/lasi); the Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __ > > Linux-powered Science > __ -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/list
Re: [Plplot-devel] Greek characters in qt-driver
On 2010-10-05 13:02+0100 Steve Schwartz wrote: > [...]Gucharmap shows both > the symbols and alternatives, and the xcairo driver finds them, so I > guess they reside somehow on my system but not accessed by my version of > qt (4.5.3). I used to encounter this same difficulty (Qt was not as good at finding system fonts as xcairo and gucharmap). I speculate that older versions of Qt used their own library for finding system fonts and not the standard fontconfig library that is used by xcairo and gucharmap or else Qt used fontconfig in a poorly configured way. However, for Qt-4.6.3 (the version that comes with Debian testing) I have not encountered this issue. For example, the Hershey numbers below are all rendered fine with example 7 and -dev qtwidget. > Hershey numbersplplot5.9.7 unicode change to this > 46, 546 0x03d2 0x03a5 Upsilon > 534 0x03d1 0x03b8 theta > 98, 684, 21840x03f5 0x03b5 epsilon > 686, 21860x03d5 0x03c6 phi variant As you can see from Section 2.28 of our release announcement, later versions of Qt seem to solve a number of issues we see for earlier versions of Qt so the fix for this font-finding issue appears to be just one more fix in the series of Qt improvements that also doesn't seem to have introduced any regressions (at least up to 4.6.3). So TrollTech/Nokia seem to have a pretty good track record for constantly improving Qt4. The Qt download site at http://qt.nokia.com/downloads/ gives you access to the latest Qt version (currently 4.7.0) in binary form. If that version works well for you (i.e., solves the above issue without introducing any regressions), then you might want to recommend it to your QSAS users that don't have access to Qt-4.6.3 or above from their distribution. Alternatively, you could temporarily deploy the above workaround until essentially all distros have updated to 4.6.3 or above. Finally, these issues remind me again that plpoin and plsym access unicode glyphs in an indirect and extremely limited way. Therefore, I have decided it is long past time we introduced a new function plglyph(n, x, y, ucs4) which allowed plotting glyphs corresponding to the ucs4 index for those drivers which are unicode aware. Such a function would allow users full and direct access to the extremely wide variety of generic sans and serif glyphs that are available on their system for unicode-aware device drivers like qt (with Qt-4.6.3 or later) or cairo. I will try implementing a first cut at plglyph later today. 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] [ plplot-Bugs-3081443 ] mingw install - ada example - missingdll/libplplotadad.dll.a
Bugs item #3081443, was opened at 2010-10-05 14:10 Message generated for change (Tracker Item Submitted) made by r29173 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102915&aid=3081443&group_id=2915 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Laurent Lemaitre (r29173) Assigned to: Nobody/Anonymous (nobody) Summary: mingw install - ada example - missingdll/libplplotadad.dll.a Initial Comment: Hi, FYI! I just installed successfully plplot-5.9.7 on mingw :-) However I had to do a minor change to make 'make' happy. More specifically I had to: cp dll/libplplotadad.dll dll/libplplotadad.dll.a Details: I ran the following commands: 1. mkdir buildmingw 2. cmake -G "MSYS Makefiles" -DCMAKE_INSTALL_PREFIX=install -DCMAKE_VERBOSE_MAKEFILE=ON -DBUILD_TEST=ON .. 3. make It is at step 3 when ada examples are compiled that I get the problem of missing dll/libplplotadad.dll.a file. Laurent -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102915&aid=3081443&group_id=2915 -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Greek characters in qt-driver
Alan, In looking over legend things, I've discovered that as of 5.9.7 (and probably also 5.9.6 but I only have 5.9.5 built) there have been a few changes to the hershey-unicode mappings that don't work with the qt driver (but are ok with the xcairo one). I presume this is down to my local font holdings. I append below the summary and workaround I sent internally to my team in order to get our software to display the relevant characters. It looks like for some characters you have decided to pick them not from the standard Greek family ( 0x03a,b,c ) but a variant (0x03d,f). I run an OpenSuse 11.1 system. Gucharmap shows both the symbols and alternatives, and the xcairo driver finds them, so I guess they reside somehow on my system but not accessed by my version of qt (4.5.3). I don't know if you want this submitted as a bug, or if your own systems do better. Let me know... Regards, Steve [ snip ...] Some Greek characters have been moved in plplot to what I presume they find more appealing alternatives. The escapes in question include #gU and #gh (capital Upsilon and lower case theta respectively). Additionally there are two more characters, lunate epsilon and a variant of lower case phi, that can be invoked by plsym but don't work for me. This appears to be a shortcoming in qt, as the Cairo drivers can find them. As before, the "fix" involves changing entries in plhershey-unicode.h: Hershey numbersplplot5.9.7 unicode change to this 46, 546 0x03d2 0x03a5 Upsilon 534 0x03d1 0x03b8 theta 98, 684, 21840x03f5 0x03b5 epsilon 686, 21860x03d5 0x03c6 phi variant -- +---+ Professor Steven J SchwartzPhone: +44-(0)20-7594-7660 Head, Space & Atmospheric Physics Fax: +44-(0)20-7594-7772 The Blackett LaboratoryE-mail: s.schwa...@imperial.ac.uk Imperial College LondonOffice: Huxley 6M67A London SW7 2AZ, U.K. Web: www.sp.ph.ic.ac.uk/~sjs +---+ -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
