On 2013-01-29 10:23-0000 Andrew Ross wrote: > On Mon, Jan 28, 2013 at 06:31:42PM -0800, Alan Irwin wrote: >> On 2013-01-15 12:47+0800 H??ili??ng W??ng wrote: >> >>> Hello, >>> >>> I'm plotting a small PDF graph (128x96) with cairopdf driver, and the >>> line width looks too thick with line width 1. >>> >>> To solve the problem, I modify the code within the cairo driver >>> (cairo.c) to set the the line width to 0.2 directly, and the result >>> looks pretty good. >>> >>> I have read the thread below so I know there is no plan to change >>> function plwid's parameter from int to float: >>> http://www.mail-archive.com/plplot-general@lists.sourceforge.net/msg00429.html >>> >>> I'm wondering if it is good idea to add another function to set the >>> line width with a ratio, e.g. void plwidr(double)? So that the real >>> line width becomes a product: linewidth*ratio. By default the ratio is >>> 1.0 so it will not affect the current user, but if the user want finer >>> line width, just set linewidth=1 and the ratio any floating point >>> value they want. >> >> Hi H??ili??ng: >> >> I gave you a quick answer on plplot-general, but I think the rest of >> this discussion should be on plplot-devel. Please subscribe to that >> list (i.e., the current list) if you would like to participate further >> in that discussion. >> >> @Andrew: most of the rest of this is addressed to you. >> >> Since that quick answer I have looked more carefully at what external >> drawing libraries do. Our two best devices drivers are cairo (based >> on the pango and cairo external libraries) and qt (based on the Qt4 >> external libraries. It appears the cairo library uses a floating-point >> pen width which we currently specify by casting the PLplot integer >> width appropriately. Also, it appears from our qt code, that we >> propagate our linewidth to a call the Qt4 setWidth (documented at) >> http://harmattan-dev.nokia.com/docs/library/html/qt4/qpen.html#width >> which takes an integer width argument. But right next to that >> setWidth function they also define setWidthF which takes a >> floating-point pen width argument. So my guess is the Qt4 library >> made the same mistake as PLplot has done (integer width argument) but >> they fixed it later by allowing the setWidthF alternative of >> specifying a floating-point width. >> >> So here is what I suggest we do. >> >> 1. Define a new function plwidth just like plwid is done now but with a >> PLFLT line >> width argument. (Actually, I like the plwidth name better than plwid.) >> >> 2. Wherever plwid is called internally now change that to plwidth >> with approprate cast of the argument (which allows plwid to >> be moved to pldeprecated.c below). >> >> 3. Define plwid as >> >> void plwid(PLINT width) >> { >> plwidth( (PLFLT) width); >> } >> >> and move it to pldeprecated. >> >> 4. Propagate the floating point line width set by plwidth to each of >> our device drivers. That would immediately let users specify a 0.2 >> width for plwidth which would propagate directly to our cairo device >> driver. With some additional work (i.e., replacing setWidth with >> setWidthF everywhere) we could propagate floating-point pen widths to >> our qt device driver as well. >> >> @Andrew: do you see any issues with the above four changes? >> >> Of course, we would still be stuck with integer line widths for the >> pllegend, plshade, and plshades API until we changed those width >> arguments to PLFLT. But making such changes is tougher on our users >> than the above 4 changes because we don't want to change the pllegend, >> plshade, and plshades function names. So we could put that change off >> until later, but if we are going to do the above 4 changes, it is >> probably a good time to do the pllegend, plshade, and plshades API >> changes as well (so long as we warn our users about this in the >> release announcement and do the appropriate SOVERSION bump to force >> them to recompile their applications/libraries.) But I emphasize this >> is a separate issue that should not affect what we decide to do for >> plwid. > > Alan, > > I think this is the best plan. Clearly line with would be better as a > float. I also think plwidth is a better name. I have no objections to > 1-4 above. Some drivers (e.g. postscript) do use int internally, but I > don't think that should be a problem with suitable casting. We might > just want to check that small widths don't become zero and disappear. > This is easily fixed though.
Thanks, Andrew, for your response. I think this is an important issue to fix, and we appear to be in agreement about how to do it so I will take responsibility for this part of the change. I am quite busy at the moment with the Time Ephemerides project, but I hope to squeeze in these plwid/plwidth changes in the next several weeks or so. Once that is done we can decide about the best way to deal with the similar integer ==> floating point width changes for the pllegend and plshade(s) API. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 __________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
