Menu
▾
▴
plplot-devel
|
From: Rafael L. <rla...@us...> - 2005-01-22 22:25:44
|
Good news: I finally got it right and just commit the changes that fix the alignment problems for single glyphs plotted via plpoin when using the gd drivers with TT fonts. See my last CVS commit for details. Example x01c produces now a correct png output. This was the last showstopper preventing all of our demos in plplot.sf.net to be generated with -dev png -drvopt text,smooth. This brings me to another subject: I am not willing to make the changes to the web site prior to a new release of PLplot. I think it is inappropriate to advertise example results that the current released version of PLplot cannot really obtain. However, I do not know what would be the appropriate timing for the next release. From my previous experience, the amount of work involved in release management is overwhelming and I cannot afford this right now in my free time budget. I know Alan and I are the better indicated persons to be RM, but I am afraid both of us do not have much time. Volunteers are welcome, anyway. -- Rafael |
|
From: Rafael L. <rla...@us...> - 2005-01-22 23:51:37
Attachments:
x01c.png
|
* Rafael Laboissiere <rla...@us...> [2005-01-22 23:25]: > Example x01c produces now a correct png output. This was the last > showstopper preventing all of our demos in plplot.sf.net to be generated > with -dev png -drvopt text,smooth. I forget to attach the output of the x01c with the options above. It is below. -- Rafael |
|
From: Alan W. I. <ir...@be...> - 2005-01-22 23:58:40
|
On 2005-01-22 23:25+0100 Rafael Laboissiere wrote: > Good news: I finally got it right and just commit the changes that fix the > alignment problems for single glyphs plotted via plpoin when using the gd > drivers with TT fonts. See my last CVS commit for details. > > Example x01c produces now a correct png output. This was the last > showstopper preventing all of our demos in plplot.sf.net to be generated > with -dev png -drvopt text,smooth. Thanks, Rafael, for your excellent work. > > This brings me to another subject: I am not willing to make the changes to > the web site prior to a new release of PLplot. I think it is inappropriate > to advertise example results that the current released version of PLplot > cannot really obtain. However, I do not know what would be the appropriate > timing for the next release. From my previous experience, the amount of > work involved in release management is overwhelming and I cannot afford this > right now in my free time budget. I know Alan and I are the better > indicated persons to be RM, but I am afraid both of us do not have much > time. Volunteers are welcome, anyway. To solve the problem of updating the example png's without leading user's astray as to what is in the released version, how about making a parallel web tree called plplot.sf.net/pre-release ? Part of the reason why the release process is such a burden right now is all the website changes that have to be done and tested in a short space of time. If we spread that effort out over time with a definite alternative site that every developer can review and update, it takes the pressure off the RM. For example, it would be nice to generate all the example pngs for the alternate site right now, and similarly I would like to put all the font documentation changes I am currently making onto the alternate site since this documentation is not relevant to our released version of the code. Rafael, how hard would it be to have a parameter in your web-related scripts that allows you to have the option of putting everything into a pre-release area while still preserving the normal website that users are aware of? Switching to the broader issue of the manager for the next PLplot release, I don't think we have to worry about that just yet. I hope we have a release within 6 months to show off all our sexy new fonts to our users, but it is probably still several months away at minimum because our code is not in releasable state, IMHO. There are code cleanups to do, font transformation bugs still to fix, e.g., misaligned X and Y titles for 3D plots for gd.c and plfreetype.c, and the axis label size and alignment issues that are just noticable enough for my research plots to be a showstopper and which become really apparent for azimuths less that 10 deg or so. There is also the issue of the ps.c bounding box being completely wrong for unicode fonts. That's just on the Linux side of things. There is lots of work to do to make these changes work on the Windows side of things as well. Also, although it is not essential for the release, I still hope somebody will get inspired and put in transformations from UTF-whatever to our UCS4 internal representations which will allow PLplot captions in all languages of the world. In sum, here is what I think we should do with regard to the next release. * Have a pre-release web site for web site changes appropriate for the next release. I could use such a site right now for my font documentation changes, and it would be wonderful to see all the png examples done with unicode fonts on this pre-release version of the website as well. * Keep track of font issues and how fast they are being solved. Obviously, Rafael has made big strides the last few days on some aspects of this, but there is some more to do before we can release. * Once our code is in more releasable state, quickly decide on a release manager (either Rafael or I or some other volunteer might be available then) and get out the release within a month at that point before bit-rot sets in. 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 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: Rafael L. <rla...@us...> - 2005-01-23 00:57:18
|
* Alan W. Irwin <ir...@be...> [2005-01-22 15:58]: > To solve the problem of updating the example png's without leading user's > astray as to what is in the released version, how about making a parallel > web tree called plplot.sf.net/pre-release ? > > Part of the reason why the release process is such a burden right now is all > the website changes that have to be done and tested in a short space of > time. If we spread that effort out over time with a definite alternative > site that every developer can review and update, it takes the pressure off > the RM. For example, it would be nice to generate all the example pngs for > the alternate site right now, and similarly I would like to put all the font > documentation changes I am currently making onto the alternate site since > this documentation is not relevant to our released version of the code. > > Rafael, how hard would it be to have a parameter in your web-related scripts > that allows you to have the option of putting everything into a pre-release > area while still preserving the normal website that users are aware of? There are many web-related scripts and change all them will be a PITA, besides the increase in work to maintain both sites. I am afraid I cannot commit myself to this extra burden. I have another proposal that is much simpler (although sub-optimal): just generate a cvs tarball release (as we did many times in the past) and update the documentation and example areas of plplot.sf.net with the results of this cvs release. I do not believe that HEAD is in a broken state now, so that a cvs tarball will keep all the functionalities of 5.3.1 intact. In particular, if users do not use -drvopt text, then everything should be identical as before. Even is they use, I do not see how there could be problems introduced after 5.3.1 that did not existed before. This is a no-hassle, no-head-ache solution, but we must make it clear at the web-site that both the documentation and examples relate to the forthcoming official release. Users can install in their systems the 5.3.1 documentation and examples (from the latest official release tarball) if they wish. -- Rafael |
|
From: Alan W. I. <ir...@be...> - 2005-01-23 05:31:45
|
On 2005-01-22 15:58-0800 Alan W. Irwin wrote:
> * Keep track of font issues and how fast they are being solved. Obviously,
> Rafael has made big strides the last few days on some aspects of this, but
> there is some more to do before we can release.
I have looked some more at this point, and here are the current results
for the case of
-dev png -fam -fflen 2 -drvopt text,smooth,24bit
These problems do not show up for -dev png with no -drvopt
+ There are still problems with vertical alignment of characters. See
example 6 line 100 where the characters move up or down depending on whether
they have an ascender, descender or neither.
+ Rafael's recent changes did help the vertical alignment of full-scale
labels, but for smaller plots (e.g., the 4 subplots of example 1) the vertical
alignment of labels is still off.
+ Example 4 still plots "-20db/decade" string at somewhat wrong angle.
+ If you extend the x axis and y axis labels on example 8 to extend completely
through the entire axis length, the y axis labels gradually drift away
from the axis, and the x axis labels gradually drift toward the axis. This
problem was first mentioned by Tom, and it is still with us.
+ Examples 9 displays contour labels outside viewport. This is probably a
core non-Hershey font problem since it also occurs for postscript.
+ Example 9 and 22 second and subsequent pages have rectangular viewports
with no box or tick marks for the png device and non-Hershey fonts. If you
switch to Hershey fonts for png or any kind of fonts for postscript, this
bug goes away. Thus, it is likely a plfreetype problem. valgrind shows no
associated memory management problems with examples 9 and 22. I have no
clue what is causing this bug. OTOH, this may have the same root cause as
the following problem because when I remove the 24bit -drvopt option, the
problem disappears.
+ x19c, the 2nd and 3rd pages disappear. The problem goes away if you drop
24bit from the -drvopt list just as for the previous problem. There are no
memory management problems according to valgrind. I investigated further,
and there is a color problem on this bug and the previous one concerning
examples 9 and 22. If you use the option -bg FFFFFF, it shows that the red
colour used for the box outlines and the maps has been turned into black,
and that is why it doesn't show with the normal black background. Andrew
(Roach), can you figure out why 24bit affects familied colour for these
cases? The first pages are fine, it is the second and subsequent pages that
have the red colour clobbered (except for example 9 where the final pages
with round or oval red boundary are fine again).
Here are the remaining postscript problems that I mentioned before with
-psc -drvopt text
These problems disappear if -drvopt text is dropped.
+ Contour labels outside viewport as for
-dev png -fam -fflen 2 -drvopt text,smooth,24bit
+ showstopper axis labelling issue for 3D plots with azimuth within 15 deg
or so of multiples of 90 deg.
+ the xform setting in plhrsh (plsym.c) is a kludge.
+ bounding box done incorrectly. Shows especially in example 13.
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 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: Rafael L. <rla...@us...> - 2005-01-23 22:19:16
|
* Alan W. Irwin <ir...@be...> [2005-01-22 21:31]: > + There are still problems with vertical alignment of characters. See > example 6 line 100 where the characters move up or down depending on whether > they have an ascender, descender or neither. No idea where this come from, but it is not really a showstopper. If I find inspiration, I will take a look. > + Rafael's recent changes did help the vertical alignment of full-scale > labels, but for smaller plots (e.g., the 4 subplots of example 1) the > vertical > alignment of labels is still off. You have an eagle's eye! The labels are verically misaligned by only one pixel. Integer truncation is the root of the problem. The characters have 12 pixels and the exact computation of vertical shift is around 5.93. However an integer shift operation (>> 6) yields 5 instead. I do not know yet how I will cope with this. The code in plfreetype.c is unfortunately heavily based on such integer truncation operations. -- Rafael |
|
From: Arjen M. <arj...@wl...> - 2005-01-24 08:09:14
|
Rafael Laboissiere wrote: > > * Alan W. Irwin <ir...@be...> [2005-01-22 21:31]: > > > + There are still problems with vertical alignment of characters. See > > example 6 line 100 where the characters move up or down depending on whether > > they have an ascender, descender or neither. > > No idea where this come from, but it is not really a showstopper. If I find > inspiration, I will take a look. > > > + Rafael's recent changes did help the vertical alignment of full-scale > > labels, but for smaller plots (e.g., the 4 subplots of example 1) the > > vertical > > alignment of labels is still off. > > You have an eagle's eye! The labels are verically misaligned by only one > pixel. Integer truncation is the root of the problem. The characters have > 12 pixels and the exact computation of vertical shift is around 5.93. > However an integer shift operation (>> 6) yields 5 instead. > > I do not know yet how I will cope with this. The code in plfreetype.c is > unfortunately heavily based on such integer truncation operations. > Maybe we should use the "fuzzy" algorithms that were developed years ago for this kind of things. I have got the code (Fortran) and it can be easily converted to C. These algorithms come from the APL community and are meant to help with such operations in a consistent way. No idea if it will work, though - that will require experimentation. Regards, Arjen |
|
From: Rafael L. <rla...@us...> - 2005-01-24 22:57:33
|
* Rafael Laboissiere <rla...@us...> [2005-01-23 23:19]: > You have an eagle's eye! The labels are verically misaligned by only one > pixel. Integer truncation is the root of the problem. The characters have > 12 pixels and the exact computation of vertical shift is around 5.93. > However an integer shift operation (>> 6) yields 5 instead. > > I do not know yet how I will cope with this. The code in plfreetype.c is > unfortunately heavily based on such integer truncation operations. This has being fixed by my last commit. See plplot-cvs for details. Text rotation is still inaccurate, but I do not have a clue about the roots of the problem. I will investigate it as time permits. -- Rafael |
|
From: Andrew R. <and...@us...> - 2005-01-24 18:52:17
|
On Sat, Jan 22, 2005 at 09:31:40PM -0800, Alan Irwin wrote: > On 2005-01-22 15:58-0800 Alan W. Irwin wrote: > > + Examples 9 displays contour labels outside viewport. This is probably a > core non-Hershey font problem since it also occurs for postscript. The contour labelling is done by calling plptex. According to the documentation this clips to the viewport. It does for the Hershey fonts because the lower level plotting routines do the clipping. For either the postscript or freetype fonts there is no clipping however. Presumably this bug has been there for a long time with the old postscript "-drvopt text" option but no-one has noticed. For postscript this can probably be relatively easily fixed using the postscript clip. In fact we could probably alter plsclp to set the clip path and that would solve the problem neatly for this and any other future clipping issues? For freetype fonts - I don't know. I guess this clipping has to be done at the font level because at the plptex level we don't know what size and length the strings are? Andrew |
|
From: Andrew R. <and...@us...> - 2005-01-25 11:13:38
|
On Mon, Jan 24, 2005 at 06:51:29PM +0000, Andrew Ross wrote: > On Sat, Jan 22, 2005 at 09:31:40PM -0800, Alan Irwin wrote: > > On 2005-01-22 15:58-0800 Alan W. Irwin wrote: > > > > + Examples 9 displays contour labels outside viewport. This is probably a > > core non-Hershey font problem since it also occurs for postscript. > > The contour labelling is done by calling plptex. According to the > documentation this clips to the viewport. It does for the Hershey fonts > because the lower level plotting routines do the clipping. For either > the postscript or freetype fonts there is no clipping however. > Presumably this bug has been there for a long time with the old > postscript "-drvopt text" option but no-one has noticed. > > For postscript this can probably be relatively easily fixed using the > postscript clip. In fact we could probably alter plsclp to set the clip > path and that would solve the problem neatly for this and any other > future clipping issues? I have now fixed this for the postscript driver using clipping. In fact it turned out to be easier just to add the clipping around the text in the postscript file. This now works. While testing I noticed that example 21 uses the 5th plpoin symbol to plot the data. This is missing from my postscript fonts at least so it is possibly not a good choice for our examples. If I can get my head around the transformations I will try and look at the bounding box issue as well. > For freetype fonts - I don't know. I guess this clipping has to be done > at the font level because at the plptex level we don't know what size > and length the strings are? |
|
From: Rafael L. <rla...@us...> - 2005-01-25 13:24:47
|
* Andrew Ross <and...@us...> [2005-01-25 11:13]: > While testing I noticed that example 21 uses the 5th plpoin symbol to > plot the data. This is missing from my postscript fonts at least so it > is possibly not a good choice for our examples. Fixed in CVS, as per my last commit to fonts/plhershey-unicode.csv. -- Rafael |
|
From: Rafael L. <rla...@us...> - 2005-01-25 09:58:17
|
* Alan W. Irwin <ir...@be...> [2005-01-22 21:31]: > + Example 4 still plots "-20db/decade" string at somewhat wrong angle. > > + If you extend the x axis and y axis labels on example 8 to extend > completely through the entire axis length, the y axis labels gradually > drift away from the axis, and the x axis labels gradually drift toward the > axis. This problem was first mentioned by Tom, and it is still with us. This bug was due to truncation problems in FT_WriteStrW and has been fixed in my latest cvs commit. Examples x04c and x08c produce now good results. -- Rafael |
|
From: Andrew R. <and...@us...> - 2005-01-25 15:28:57
|
On Sat, Jan 22, 2005 at 09:31:40PM -0800, Alan Irwin wrote: > On 2005-01-22 15:58-0800 Alan W. Irwin wrote: > > Here are the remaining postscript problems that I mentioned before with > > -psc -drvopt text > > These problems disappear if -drvopt text is dropped. > > + Contour labels outside viewport as for > > -dev png -fam -fflen 2 -drvopt text,smooth,24bit > > > + showstopper axis labelling issue for 3D plots with azimuth within 15 deg > or so of multiples of 90 deg. > > + the xform setting in plhrsh (plsym.c) is a kludge. > > + bounding box done incorrectly. Shows especially in example 13. Bounding box calculation now done for postscript driver. Have to estimate the length of a string since we don't know the actual width of postscript characters. I have taken strong length (number of non-escape characters) * character height * 0.6 as the width of the string. Also added an extra 1.5 character heights for safety. This seems to be slightly generous for the examples so should hopefully cover most cases. Example 13 now looks much better. If anyone can think of a better way of doing this then let me know. If you really want to fix this up for a given plot then you can always using the ghostscript bb driver and edit the bounding box by hand... Andrew |
|
From: Rafael L. <rla...@us...> - 2005-01-26 07:42:17
|
* Andrew Ross <and...@us...> [2005-01-25 15:28]: > If anyone can think of a better way of doing this then let me know. If > you really want to fix this up for a given plot then you can always > using the ghostscript bb driver and edit the bounding box by hand... I use ps2eps for that. See http://www.tm.uka.de/~bless/ps2eps.html There is also a Debian package for it (which I maintain, BTW). -- Rafael |
|
From: Alan W. I. <ir...@be...> - 2005-01-28 01:29:46
|
Thanks to Andrew (Ross) and Rafael for clearing up roughly half the unicode issues I mentioned. Here is the current report card for a fresh checkout. On 2005-01-22 21:31-0800 Alan W. Irwin wrote: > here are the current results > for the case of > > -dev png -fam -fflen 2 -drvopt text,smooth,24bit > > These problems do not show up for -dev png with no -drvopt > > > + Rafael's recent changes did help the vertical alignment of full-scale > labels, but for smaller plots (e.g., the 4 subplots of example 1) the > vertical > alignment of labels is still off. Fixed. > > + Example 4 still plots "-20db/decade" string at somewhat wrong angle. Fixed. > > + If you extend the x axis and y axis labels on example 8 to extend > completely > through the entire axis length, the y axis labels gradually drift away > from the axis, and the x axis labels gradually drift toward the axis. This > problem was first mentioned by Tom, and it is still with us. Fixed So all the above is great news, but now for the remaining png bad news. > + There are still problems with vertical alignment of characters. See > example 6 line 100 where the characters move up or down depending on whether > they have an ascender, descender or neither. Not fixed. This problem also shows up for example 7. It seems to be limited to lower case letters only. > > + Examples 9 displays contour labels outside viewport. This is probably a > core non-Hershey font problem since it also occurs for postscript. Not fixed, although there has been speculation on list about a methods of fixing this using libfreetype clipping (which I prefer since it is a more general resolution of the problem) or libgd clipping. > > + Example 9 and 22 second and subsequent pages have rectangular viewports > with no box or tick marks for the png device and non-Hershey fonts. If you > switch to Hershey fonts for png or any kind of fonts for postscript, this > bug goes away. Thus, it is likely a plfreetype problem. valgrind shows no > associated memory management problems with examples 9 and 22. I have no > clue what is causing this bug. OTOH, this may have the same root cause as > the following problem because when I remove the 24bit -drvopt option, the > problem disappears. > > + x19c, the 2nd and 3rd pages disappear. The problem goes away if you drop > 24bit from the -drvopt list just as for the previous problem. There are no > memory management problems according to valgrind. I investigated further, > and there is a color problem on this bug and the previous one concerning > examples 9 and 22. If you use the option -bg FFFFFF, it shows that the red > colour used for the box outlines and the maps has been turned into black, > and that is why it doesn't show with the normal black background. Andrew > (Roach), can you figure out why 24bit affects familied colour for these > cases? The first pages are fine, it is the second and subsequent pages that > have the red colour clobbered (except for example 9 where the final pages > with round or oval red boundary are fine again). > Not fixed. Lets call the above two one 24bit issue with clobbering cmap0. I believe this issue should be addressed by Andrew Roach since the 24bit code is his. **********Now for the ps issues: > > Here are the remaining postscript problems that I mentioned before with > > -psc -drvopt text > > These problems disappear if -drvopt text is dropped. > > + Contour labels outside viewport as for > > -dev png -fam -fflen 2 -drvopt text,smooth,24bit Fixed for ps.c. > > + showstopper axis labelling issue for 3D plots with azimuth within 15 deg > or so of multiples of 90 deg. Fixed. Thanks, Andrew! That makes a large practical difference to me. > > + the xform setting in plhrsh (plsym.c) is a kludge. Not fixed. > > + bounding box done incorrectly. Shows especially in example 13. This has been partially fixed. The bounding box has been substantially increased so at least parts of the plot are not cut off. However, we should ideally be able to do a complete fix where the bounding box is exact (without calling exterior programmes like ps2eps). I noticed code in ps.c where the commentary said "for measurement purposes only." If I am reading this bit of code correctly, it is apparently not used for the bounding box calculation, but I wonder if it could be used that way (especially if esc_purge and the loop after this comment are adjusted to handle font changes similar to the way it is done for the loop where characters are actually plotted rather than measured. I would be happy to make the loop changes to change fonts in mid-string if somebody else knows enough postscript to utilize these "measurement purposes only" results for the bounding box calculation. Other device driver issues which I have mentioned only in passing before.... Both pstex.c and xfig.c currently use EscText so they presumably need some work to utilize the new core unicode font handling. Presumably the same is true of Tom's new device driver and the aquaterm device driver. In sum, thanks to the recent hard work by Andrew (Ross) and Rafael, we are much better off than before for unicode fonts, but there are still a few plfreetype.c and ps.c issues to sort out as well as substantial work to do for other device drivers. 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 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: Andrew R. <and...@us...> - 2005-01-28 12:25:30
|
On Thu, Jan 27, 2005 at 05:20:01PM -0800, Alan Irwin wrote: > Thanks to Andrew (Ross) and Rafael for clearing up roughly half the unicode > issues I mentioned. > > Here is the current report card for a fresh checkout. > > Fixed. Thanks, Andrew! That makes a large practical difference to me. > > > > >+ the xform setting in plhrsh (plsym.c) is a kludge. > > Not fixed. Alan, do you have an example of what the problem is here? > >+ bounding box done incorrectly. Shows especially in example 13. > > This has been partially fixed. The bounding box has been substantially > increased so at least parts of the plot are not cut off. > > However, we should ideally be able to do a complete fix where the bounding > box is exact (without calling exterior programmes like ps2eps). I noticed > code in ps.c where the commentary said "for measurement purposes only." If I > am reading this bit of code correctly, it is apparently not used for the > bounding box calculation, but I wonder if it could be used that way > (especially if esc_purge and the loop after this comment are adjusted to > handle font changes similar to the way it is done for the loop where > characters are actually plotted rather than measured. I would be happy to > make the loop changes to change fonts in mid-string if somebody else knows > enough postscript to utilize these "measurement purposes only" results for > the bounding box calculation. The real problem here is that currently the ps driver knows nothing about the font widths. All we do is specify a font name and size. All the actual font handling is done by the postscript interpreter. In theory this information is in the font metric files (.afm files). Freetype can now handle Type1 fonts as well, so perhaps we can use it to calculate the string bounding boxes. There is still a problem identifying the fonts. Currently there is no need to have any PS fonts installed to use the PS driver. Perhaps you just have a PS printer? Also many people will be using ghostscript as a PS interpreter. This doesn't come with the standard Adobe PS fonts. Instead it uses free alternatives which it maps onto the standard fonts. Even with the freetype approach we need to know what font we want to compare with and where it resides. Actually we could generate the .afm files ourselves using something like getafm and then distribute the ones we need with plplot. Alternatively I'm not sure about the Adobe license on these files - perhaps we can use theirs. This seems to be what things like enscript and a2ps do and may be a neater solution. For now I'll think about how to use the .afm files and worry about the mechanics of finding them later. Andrew Perhaps someone with some freetype experience could comment on how easy it is to extract a string width once the font is loaded? |
|
From: Alan W. I. <ir...@be...> - 2005-01-28 22:11:29
|
Two more postscript issues. + The overall size of the text is systematically smaller than for Hershey of TrueType fonts whether plptex or plpoin is being used. + For Example 6 text the labels written with plptex seem to be positioned correctly, but the symbols written with plpoin are positioned consistently too high. For the latter issue, I am wondering if there may simply be a positioning bug in the way that I have called the unicode array method for handling the symbol font change plus a single character in plhrsh. I was sometimes guessing there, and somebody with a deeper understanding of PLplot positioning should review the plhrsh code. plhrsh is the routine called by plpoin. For plptext, the setup of the unicode array method is done with entirely different code which appears to be correct as far as position information is concerned. A similar problem used to occur for plfreetype although the issue was complicated by plptex positioning problems as well which now seem perfectly fixed by Rafael's changes. But as I recall, some of Rafael's fixes were specific to the plhrsh call in the sense that call was recognized by the font change plus one character being sent. If a bug is found in the way positions are set up in plhrsh so that the postscript positions come out right, then you may be able to simply strip out all those special "plhrsh" fixes in the plfreetype code, and have the png symbol positions come out right as well. The current set of "plhrsh" plfreetype fixes need to be reviewed in any case, since the consistent symbol shift we used to have has now been turned into a symbol shift that is correct for upper case letters but which varies from character to character (compare "i" and "j") for lower case characters. 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 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...> - 2005-01-29 19:36:40
|
On 2005-01-28 14:03-0800 Alan W. Irwin wrote:
> + For Example 6 text the labels written with plptex seem to be positioned
> correctly, but the symbols written with plpoin are positioned
> consistently too high.
>
> For the latter issue, I am wondering if there may simply be a positioning
> bug in the way that I have called the unicode array method for handling the
> symbol font change plus a single character in plhrsh. I was sometimes
> guessing there, and somebody with a deeper understanding of PLplot
> positioning should review the plhrsh code. plhrsh is the routine called by
> plpoin. For plptext, the setup of the unicode array method is done with
> entirely different code which appears to be correct as far as position
> information is concerned.
>
> A similar problem used to occur for plfreetype although the issue was
> complicated by plptex positioning problems as well which now seem perfectly
> fixed by Rafael's changes. But as I recall, some of Rafael's fixes were
> specific to the plhrsh call in the sense that call was recognized by the
> font change plus one character being sent. If a bug is found in the way
> positions are set up in plhrsh so that the postscript positions come out
> right, then you may be able to simply strip out all those special "plhrsh"
> fixes in the plfreetype code, and have the png symbol positions come out
> right as well. The current set of "plhrsh" plfreetype fixes need to be
> reviewed in any case, since the consistent symbol shift we used to have has
> now been turned into a symbol shift that is correct for upper case letters
> but which varies from character to character (compare "i" and "j") for lower
> case characters.
Here is some additional background to the vertical positioning problem for
symbols handled by plhrsh and plfreetype. In off-list discussions with
Andrew Roach prior to my FCI changes to plfreetype.c, he explained to me he
used a completely separate code path in plfreetype.c to deal with calls from
plhrsh. That code path (the call to plD_render_freetype_sym from
plD_render_freetype_text) was triggered by args->unicode_array_len == 0. I
bypassed plD_render_freetype_sym because I needed to communicate FCIs with
unicode_array even in the single-character case, and I assumed that
plD_render_freetype_sym could be mimicked by the normal code in
plD_render_freetype_text. I haven't followed Rafael's changes in detail,
but I think all that has to be done for the plhrsh case (which should
probably be signalled in a flag in EscText rather than relying on the test
if ((args->unicode_array_len == 2)
&& (args->unicode_array[0] == 0x10000004))
) is to follow what Andrew did for vertical positioning in
plD_render_freetype_sym. Alternatively, plD_render_freetype_sym could be
made FCI aware. Andrew (Roach) might follow that path eventually because he
was concerned about inefficiencies in the plD_render_freetype_text for
single characters, but if we can mimic plD_render_freetype_sym positioning
exactly in plD_render_freetype_text I would prefer to do that since it would
be nice (from the code maintainability POV) to eliminate
plD_render_freetype_sym altogether.
I have no more time to do any changes to plfreetype myself, but I thought I
had better give this background so those who are working out the remaining
unicode font issues are aware of why the currently unused
plD_render_freetype_sym is still in plfreetype.c as reference code and also
as the basis for a possible FCI enabled version in the future.
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 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: Rafael L. <rla...@us...> - 2005-01-29 19:52:51
|
* Alan W. Irwin <ir...@be...> [2005-01-29 11:36]: > I haven't followed Rafael's changes in detail, but I think all that has to > be done for the plhrsh case (which should probably be signalled in a flag > in EscText rather than relying on the test > > if ((args->unicode_array_len == 2) > && (args->unicode_array[0] == 0x10000004)) This is one of the ugliest hacks I have ever written in my life (BTW, 0x10000004 must be changed to PL_FCI_MARK | PL_FCI_SYMBOL). I did it because a proof of concept was needed for the right positioning of single symbols. Indeed, the results for x01c are correct now, thanks to the horrible hack. I have already privately discussed with Andrew Roach about a partial rewrite of plfreetype.c. I stopped working in this file because I think that we are stacking hack on hack and the code is becoming quite unmaintainable. -- Rafael |
|
From: Alan W. I. <ir...@be...> - 2005-01-23 04:49:24
|
On 2005-01-23 01:57+0100 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2005-01-22 15:58]: > >> To solve the problem of updating the example png's without leading user's >> astray as to what is in the released version, how about making a parallel >> web tree called plplot.sf.net/pre-release ? >> >> Part of the reason why the release process is such a burden right now is all >> the website changes that have to be done and tested in a short space of >> time. If we spread that effort out over time with a definite alternative >> site that every developer can review and update, it takes the pressure off >> the RM. For example, it would be nice to generate all the example pngs for >> the alternate site right now, and similarly I would like to put all the font >> documentation changes I am currently making onto the alternate site since >> this documentation is not relevant to our released version of the code. >> >> Rafael, how hard would it be to have a parameter in your web-related scripts >> that allows you to have the option of putting everything into a pre-release >> area while still preserving the normal website that users are aware of? > > There are many web-related scripts and change all them will be a PITA, > besides the increase in work to maintain both sites. I am afraid I cannot > commit myself to this extra burden. I have another proposal that is much > simpler (although sub-optimal): just generate a cvs tarball release (as we > did many times in the past) and update the documentation and example areas > of plplot.sf.net with the results of this cvs release. > > I do not believe that HEAD is in a broken state now, so that a cvs tarball > will keep all the functionalities of 5.3.1 intact. In particular, if users > do not use -drvopt text, then everything should be identical as before. Even > is they use, I do not see how there could be problems introduced after 5.3.1 > that did not existed before. > > This is a no-hassle, no-head-ache solution, but we must make it clear at the > web-site that both the documentation and examples relate to the forthcoming > official release. Users can install in their systems the 5.3.1 > documentation and examples (from the latest official release tarball) if > they wish. That seems fine with me. 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 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...> - 2005-01-29 00:39:13
|
On 2005-01-28 12:25-0000 Andrew Ross wrote: > On Thu, Jan 27, 2005 at 05:20:01PM -0800, Alan Irwin wrote: >> Thanks to Andrew (Ross) and Rafael for clearing up roughly half the unicode >> issues I mentioned. >> >> Here is the current report card for a fresh checkout. >> >> Fixed. Thanks, Andrew! That makes a large practical difference to me. >> >>> >>> + the xform setting in plhrsh (plsym.c) is a kludge. >> >> Not fixed. > > Alan, do you have an example of what the problem is here? Basically, that part of the code needs thorough review for all position and transformation information (see my other post today). But in the specific case I was alluding to above here is the situation. I tried various xforms until I got one that would work, but if you define TEST_FOR_MISSING_GLYPHS, it quits working (all the characters are twisted by 90 deg). I have no explanation why there is that interaction with plhrsh2 being called or not. I suspect examples 6 and 7 only work now because an early character is undefined so that plhrsh2 is called to set things up properly for characters which do not have circular symmetry. That possibility worries me considerably, but I don't understand enough about PLplot positioning logic to know what to do about it. Try with and without TEST_FOR_MISSING_GLYPHS. Also, you might try one call to plsym with a code for a defined unsymmetrical character to see what happens when plhrsh2 is not called just through execution logic as opposed to conditional compilation logic. > >>> + bounding box done incorrectly. Shows especially in example 13. >> >> This has been partially fixed. The bounding box has been substantially >> increased so at least parts of the plot are not cut off. >> >> However, we should ideally be able to do a complete fix where the bounding >> box is exact (without calling exterior programmes like ps2eps). I noticed >> code in ps.c where the commentary said "for measurement purposes only." If I >> am reading this bit of code correctly, it is apparently not used for the >> bounding box calculation, but I wonder if it could be used that way >> (especially if esc_purge and the loop after this comment are adjusted to >> handle font changes similar to the way it is done for the loop where >> characters are actually plotted rather than measured. I would be happy to >> make the loop changes to change fonts in mid-string if somebody else knows >> enough postscript to utilize these "measurement purposes only" results for >> the bounding box calculation. > > The real problem here is that currently the ps driver knows nothing > about the font widths. All we do is specify a font name and size. All > the actual font handling is done by the postscript interpreter. > > In theory this information is in the font metric files (.afm files). But the postscript interpreter must have that information as well, otherwise it wouldn't know where to place the characters. Can the interpreter be interrogated for where that position will be with some sort of dry run? I thought the latter might be occurring with the code commented "measurement purposes only", but that code doesn't currently set anything having to do with the bounding box (AFAIK) so it is used for some other purpose that is unknown to me. But I wonder if that approach could be adapted for the bb calculation involving character output if I dealt with the case of font changes in mid-string. > Freetype can now handle Type1 fonts as well, so perhaps we can use it to > calculate the string bounding boxes. There is still a problem > identifying the fonts. Currently there is no need to have any PS fonts > installed to use the PS driver. Just to clarify that, are you saying because the postscript font names we use are standard (a fairly large subset of the 35 standard postscript font names), no additional font information has to be loaded in the postscript language file we produce other than those standard font names? > Perhaps you just have a PS printer? No, I have no printer at all that is readily accessible. I could use the UVic astrogroup printers to check things out, but I rarely get over there. Normally, I just use gv to view the postscript results. That is a front-end for gs, and I assume it is gs that will look for fonts that match the standard font names in the postscript language file that PLplot produces. In my case I have gsfonts installed which is a Recommends for gs-gpl. gsfonts provides lookalikes for the 35 standard postscript fonts, and I assume gv will not work without it (unless there is no unicode symbols/characters at all in the plot). OTOH, I assume if the postscript file that PLplot produced was sent to a commercial printer, the actual original adobe postscript standard fonts would be used instead (but the result would look identical to the case if you printed out the plot with a home-brew printer that used gsfonts instead). > Also > many people will be using ghostscript as a PS interpreter. This doesn't > come with the standard Adobe PS fonts. Instead it uses free alternatives > which it maps onto the standard fonts. Are you referring to gsfonts here or are there other free alternatives as well? In the gsfonts case, they are advertised as look-alikes to the Adobe originals so I assume the metrics are indistinguishable. > Even with the freetype approach > we need to know what font we want to compare with and where it resides. > Actually we could generate the .afm files ourselves using something like > getafm and then distribute the ones we need with plplot. Alternatively > I'm not sure about the Adobe license on these files - perhaps we can use > theirs. This seems to be what things like enscript and a2ps do and may > be a neater solution. > > For now I'll think about how to use the .afm files and worry about the > mechanics of finding them later. I would prefer getting the metric information from the postscript interpreter if possible, but if that is really a no-hoper, then getting it from a metric file is a reasonable alternative. In case that alternative is necessary, I think you could just use the gsfonts metric files that are installed in /usr/share/fonts/type1/gsfonts/ since presumably those files are indistinguishable from the adobe versions. Thanks very much for your efforts at getting some of these difficult remaining issues dealt with. 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 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 __________________________ |
