OK - I understand now. Veusz picks up the printer's settings. That's fine.
On 01/27/2013 07:00 PM, [email protected] wrote: > Send Veusz-discuss mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.gna.org/listinfo/veusz-discuss > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Veusz-discuss digest..." > > > Today's Topics: > > 1. Re: LAS files (Jeremy Sanders) > 2. Re: LAS files (Dave Hughes) > 3. Re: LAS files (Jeremy Sanders) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 26 Jan 2013 17:50:32 +0100 > From: Jeremy Sanders <[email protected]> > To: Jim Leven <[email protected]> > Cc: [email protected] > Subject: Re: [Veusz-discuss] LAS files > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 26/01/13 15:48, Jim Leven wrote: >> Dear Jermey >> >> Firstly - thanks. Veusz is the first general purpose plotting program >> that I have seen with a sensibly thought out user interface - your tree >> structure. >> >> I would like to use it for well log interpretation. Three questions if >> I may? (Note that firefox tells me that your wiki is insecure.) >> >> 1. Can you add A3 to the paper size for plots? > Do you mean in the print dialog box? Which platform is this? I see the > paper sizes the printer supports on linux and windows. Veusz just uses > the qt print dialog box and doesn't know about page sizes itself. > > As for the page size itself, you can just enter how many cm you want the > page/document to be in the settings for the page or document. You can > also define a default page size for new documents. > > Jeremy > > > > > > ------------------------------ > > Message: 2 > Date: Sat, 26 Jan 2013 18:58:31 +0000 > From: Dave Hughes <[email protected]> > To: [email protected] > Subject: Re: [Veusz-discuss] LAS files > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > On 26/01/13 16:47, Jeremy Sanders wrote: >> On 26/01/13 17:23, Dave Hughes wrote: >> >>> Jeremy might have a better method, but I see what you mean about the >>> fill above/below functions operating on a horizontal basis. I'm guessing >>> getting this working in Veusz "natively" would require adding fill >>> left/right functions as well. I might see if I can dig into the code and >>> figure that out in a bit... >> Hi Dave - I'm thinking there might be too many options to have >> Above/Below/Left/Right added. > Yup, I think I agree. I finished implementing it for the point plot and > the resulting interface is more than a little cluttered (not to mention > redundant given that the above+left, and below+right fills at least > partially overlap). I'm also none to sure how to proceed with things > like the error fills (the diamond one in particular has me rather > confused). Oh well. > >> I wonder whether it would be better to change Below/Above to >> Fill1/Fill2 and to have an option for each saying to which edge to >> fill to (like for the polar/ternary plot). That way you could add >> things like fill centre/topleft/topright... if it would be useful. > That sounds more reasonable. So, to get this straight in my head: the > PointFill class in settings.collections would gain an extra attribute > (based on settings.controls.Choice presumably) called, say, "edge" which > could accept "left", "right", "top", "bottom". Then > widgets.points._drawPlotLine gets re-written to figure out the polygon > that needs constructing to fill to the specified edge, and likewise for > _drawBezierLine (doubt it'll be difficult; it wasn't for a FillLeft and > FillRight implementation). > > I'll have to have a longer play with the error-bar handling to figure > out the necessary alterations to _errorBarsBoxFilled and > _errorBarsDiamondFilled. > >> I'd need to translate the original fills to the old (for backward >> compatibility). > Hmm, that bit I've no idea about. Is there already some code for > handling on-the-fly translation of deprecated settings somewhere in > Veusz? I've not run across it yet... > > If I can come up with something workable I'll bung over another pull > request in GitHub. > > > Cheers, > > Dave. > > > > ------------------------------ > > Message: 3 > Date: Sun, 27 Jan 2013 10:22:25 +0100 > From: Jeremy Sanders <[email protected]> > To: [email protected] > Subject: Re: [Veusz-discuss] LAS files > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 26/01/13 19:58, Dave Hughes wrote: >> On 26/01/13 16:47, Jeremy Sanders wrote: >>> On 26/01/13 17:23, Dave Hughes wrote: >>> >>>> Jeremy might have a better method, but I see what you mean about the >>>> fill above/below functions operating on a horizontal basis. I'm guessing >>>> getting this working in Veusz "natively" would require adding fill >>>> left/right functions as well. I might see if I can dig into the code and >>>> figure that out in a bit... >>> Hi Dave - I'm thinking there might be too many options to have >>> Above/Below/Left/Right added. >> Yup, I think I agree. I finished implementing it for the point plot and >> the resulting interface is more than a little cluttered (not to mention >> redundant given that the above+left, and below+right fills at least >> partially overlap). I'm also none to sure how to proceed with things >> like the error fills (the diamond one in particular has me rather >> confused). Oh well. >> >>> I wonder whether it would be better to change Below/Above to >>> Fill1/Fill2 and to have an option for each saying to which edge to >>> fill to (like for the polar/ternary plot). That way you could add >>> things like fill centre/topleft/topright... if it would be useful. >> That sounds more reasonable. So, to get this straight in my head: the >> PointFill class in settings.collections would gain an extra attribute >> (based on settings.controls.Choice presumably) called, say, "edge" which >> could accept "left", "right", "top", "bottom". Then >> widgets.points._drawPlotLine gets re-written to figure out the polygon >> that needs constructing to fill to the specified edge, and likewise for >> _drawBezierLine (doubt it'll be difficult; it wasn't for a FillLeft and >> FillRight implementation). >> >> I'll have to have a longer play with the error-bar handling to figure >> out the necessary alterations to _errorBarsBoxFilled and >> _errorBarsDiamondFilled. > I think so - nonorthpoint has something similar. > >>> I'd need to translate the original fills to the old (for backward >>> compatibility). >> Hmm, that bit I've no idea about. Is there already some code for >> handling on-the-fly translation of deprecated settings somewhere in >> Veusz? I've not run across it yet... > There is something for Setting objects (SettingBackwardCompat), but > probably not for Settings objects (confusing name). Maybe it's fine > leaving it as FillAbove/Below. Only API users and saved documents will > see the difference. As long as the side top/bottom default values are > correct it should be ok for old documents. > > Thanks! > > Jeremy > > > > > ------------------------------ > > _______________________________________________ > Veusz-discuss mailing list > [email protected] > https://mail.gna.org/listinfo/veusz-discuss > > > End of Veusz-discuss Digest, Vol 79, Issue 4 > ******************************************** >
_______________________________________________ Veusz-discuss mailing list [email protected] https://mail.gna.org/listinfo/veusz-discuss
