On Thursday, October 9, 2008 at 23:42:11 (-0500) Maurice LeBrun writes: > On Saturday, October 4, 2008 at 16:46:53 (-0700) Alan W. Irwin writes: > > On 2008-10-04 14:04-0700 Alan W. Irwin wrote: > > > > > Hi Maurice: > > > > > > I have just committed my first attempt (see src/README.pages) to > annotate > > > all the code fragments in our source code that affect paging and > familying. > > > Could you please give this a critical read? I am especially interested > in > > > the open question of whether plsc->page_status should be set to DRAWING > (or > > > perhaps a new status?) for plP_state, and plP_esc. I guess the question > > > turns on why DRAWING is set at all for most plotting operations. If > there > > > is some purpose to that, then my own view is the DRAWING status should > also > > > be set for at least plP_esc (which usually draws something), and perhaps > > > plP_state as well (which AFAIK does not draw, but usually the result is > status > > > information gets written to files for file-oriented devices). > > > > > > To give you some background... > > > [...]Anyhow, my plan is to deal with the repeat pladv(0) case, and once > that > > > simple test case produces valid empty page files (like it should), see > > > whether that fix solves the example 23 issues. > > > > I made the empty-page fix, and indeed that fixed the example 23 issue for > > the pages which consisted just of text (see my recent post on the svg > > status). However, in my view those text-only pages (done with > > plP_esc(PLESC_HAS_TEXT...) should have set the DRAWING status if that > status > > is to be meaningful at all. > > > > What do you think about setting the DRAWING status generally for both > > plP_esc and plP_state? > > That should be ok. The main thing to worry about are the AT_BOP and AT_EOP > values, so the pagination commands don't get confused. Be aware there may be > some situations where you set state to DRAWING when you are actually between > pages, but that shouldn't affect anything. I may have originally had more > plans for DRAWING but now I forget. > > I read through your doc, it looks good except the warning not to mix pladv() > and plbop/pleop is perhaps a bit too strong. One of the reasons for putting > these flags in was in fact to lessen the headache of mixing these. > > I actually can't stand using pladv() or plenv() for pagination -- I always > use > plbop/pleop. Seems much more well defined that way. pladv(0) is the > "carriage return" of printing pages (Where's the carriage? Does it come with > horses and a princess? :) > > But by keeping AT_BOP and AT_EOP status flags, throwing in an extra plbop() > or > an extra pleop() when you're not sure if you've advanced to the next page > never hurts.
To be clear, the latter statement means a primary goal of AT_BOP and AT_EOP was to suppress empty pages that crept into the plotting session by mistake or sloppy programming. That's not been changed overall, correct? -- Maurice LeBrun ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
