gay@elde.epfl.ch (David Gay) (04/03/89)
a) YAPQ - Yet another printer question In article <sorry, no ref> daveb@cbmvax.uucp writes: >In article <890329170226.20401ec5@elcc.epfl.ch> I write: >>How can I work out the maximum size for a graphic dump ? If I send a DUMPRPORT >>request with SPECIAL_NOPRINT, SPECIAL_FULLCOLS and SPECIAL_FULLROWS, it sets >>io_DestCols & io_DestRows, but adjusts them so that the ratio of my RastPort i s > >>preserved. Is there any way round this ? If not, any easy way to work these >>out from the returned values ? (I want the margins, left offset, etc to be tak e >n >> >>into account of course.) >> > There are many ways to do what you want. The simplest way is to >set io_DestCols and io_DestRows to some enormus value (like 5000). The printer >device will chop these numbers down so that they fit on the paper. I chose LONG_MAX ... >Another >way would be to set these values explicitly in preferences (on the 2nd printer >graphic screen) under the Limits heading of Pixels. Actually, I'm trying to print according to the users preferences, at the printers resolution, in slices, following a user specified ratio (I'm printing graphs). I have one last (really!) question: Can I use the PaperLength field(in combination with PrintSpacing) of preferences as an indication of the size of one page ? b) I'm having problems with AreaEllipse. However, this problem shows up as intermittent crashes, so it is very hard to pin down(*) ... I'm setting the TmpRas & AreaInfo with the following routines: struct NewAreaInfo { struct AreaInfo area; APTR areabuf; int acnt; }; struct NewTmpRas { struct TmpRas tmpras; int x,y; }; int AllocTmpRas(struct RastPort *rp, long x, long y) { struct NewTmpRas *tmpras; PLANEPTR plane; plane = (PLANEPTR)AllocRaster(x, y); if (plane == NULL) return (NULL); tmpras = (struct NewTmpRas *)AllocMem(sizeof(struct NewTmpRas), 0); if (!tmpras) { FreeRaster(plane, x, y); return(NULL); } tmpras->x = x; tmpras->y = y; rp->TmpRas = &tmpras->tmpras; InitTmpRas(&tmpras->tmpras, plane, RASSIZE(x, y)); return(TRUE); } void FreeTmpRas(struct RastPort *rp) { struct NewTmpRas *tmpras = (struct NewTmpRas *)(rp->TmpRas); FreeRaster(tmpras->tmpras.RasPtr, tmpras->x, tmpras->y); FreeMem(tmpras, sizeof(struct NewTmpRas)); rp->TmpRas = NULL; } int AllocArea(struct RastPort *rp, long acnt, long x, long y) { APTR areabuf; struct NewAreaInfo *areainf; if (!AllocTmpRas(rp, x, y)) return(FALSE); areainf = (struct NewAreaInfo *)AllocMem(sizeof(struct NewAreaInfo), 0); if (areainf == NULL) { FreeTmpRas(rp); return(FALSE); } areabuf = (APTR)AllocMem(5 * acnt, 0); if (areabuf == NULL) { FreeTmpRas(rp); FreeMem(areainf,sizeof(struct NewAreaInfo)); return(FALSE); } InitArea(&areainf->area, (short *)areabuf, acnt); rp->AreaInfo = &areainf->area; areainf->acnt = acnt; areainf->areabuf = areabuf; return(TRUE); } void FreeArea(struct RastPort *rp) { struct NewAreaInfo *areainf = (struct NewAreaInfo *)(rp->AreaInfo); FreeTmpRas(rp); FreeMem(areainf->areabuf, 5 * areainf->acnt); FreeMem(areainf, sizeof(struct NewAreaInfo)); rp->AreaInfo = NULL; } Am I doing anything wrong ? Also, the code is used (more or less) as follows: if (AllocArea(&rp2, 4, w, h)) { AreaEllipse(&rp2, w/2, h/2, w/4, h/4); AreaEnd(&rp2); FreeArea(&rp2); } Freeing the AreaInfo & TmpRas immediately shouldn't cause any problems, should it ? If I comment out the above code, the crashes (seem) to disappear. (*) I can actually reproduce the problem fairly consistently, but this involves setting all memory to a given value, rebooting, running the program. On the fifth call to the above code, the bitmap being written to gets trashed, and the Guru soon follows ... And of course, using CPR, I can't consitently get the bug to happen :-( ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ David Gay 6 x 9 = 42 GAY@ELDE.EPFL.CH, or GAY%ELDE.EPFL.CH@CLSEPF51.bitnet ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
daveb@cbmvax.UUCP (Dave Berezowski) (04/05/89)
In article <890403170253.204022be@elcc.epfl.ch> gay@elde.epfl.ch (David Gay) writes: >a) YAPQ - Yet another printer question > >In article <sorry, no ref> daveb@cbmvax.uucp writes: >>In article <890329170226.20401ec5@elcc.epfl.ch> I write: >>>How can I work out the maximum size for a graphic dump ? If I send a DUMPRPORT > >>>request with SPECIAL_NOPRINT, SPECIAL_FULLCOLS and SPECIAL_FULLROWS, it sets >>>io_DestCols & io_DestRows, but adjusts them so that the ratio of my RastPort i >s >> >>>preserved. Is there any way round this ? If not, any easy way to work these >>>out from the returned values ? (I want the margins, left offset, etc to be tak >e >>n >>> >>>into account of course.) >>> >> There are many ways to do what you want. The simplest way is to >>set io_DestCols and io_DestRows to some enormus value (like 5000). The printer > >>device will chop these numbers down so that they fit on the paper. > >I chose LONG_MAX ... > >>Another >>way would be to set these values explicitly in preferences (on the 2nd printer >>graphic screen) under the Limits heading of Pixels. > >Actually, I'm trying to print according to the users preferences, at the >printers resolution, in slices, following a user specified ratio (I'm printing >graphs). I have one last (really!) question: > >Can I use the PaperLength field(in combination with PrintSpacing) of preferences > >as an indication of the size of one page ? > To get a TRUE indication of the printable graphics area you should look at PED->ped_MaxXDots, PED->ped_MaxYDots, PED->ped_XDotsInch, and PED->ped_YDotsInch. PED->ped_MaxXDots / PED->ped_XDotsInch => printable width PED->ped_MaxYDots / PED->ped_YDotsInch => printable height if PED->ped_MaxYDots == 0 then the printer has no maximum (probably because it is using continuous form paper). Regards, David B