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. I agree the pllegend, plshade(s) issues are a bit more thorny. One advantage of changing now is that we can fix plcolorbar at least before we finalise the API. In C at least old code should work, perhaps with a warning, as the int will be cast to a float. On stricter compilers this might require an explicit cast. For some languages where function arguments can be overloaded we can provide both versions for a while. Andrew ------------------------------------------------------------------------------ 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
