On 2008-10-06 13:24+0100 Steve Schwartz wrote: > On Mon, 2008-10-06 at 13:48 +0200, Arjen Markus wrote: >> I do not know if this will be a disappointment for you, but when I >> printed via the humble lp command on an OCE printer we have here, it >> comes out just fine. I am not sure about the margins (some of my >> colleagues are rather keen on getting the fine details right), but it >> is a very presentable picture. > > This neither disappoints nor surprises very much, though it does > frustrate. > >> Now, what does that tell us about the nature of the problem? It may be >> the "e" part (no fixed bounds, IIUIC)... > > I wondered that, though running it through eps2eps leaves it an eps > file, but that one behaves for me. And it should have some idea about > scale, size, resolution, ... and the bounding box at the beginning gives > the origin relative to something. [I might have expected it not > necessarily to have the right origin - and have encountered similar > problems in the past, but I would expect a ps or eps to know what an > inch was.] > > Thanks for retaining interest this long...
Actually, it is an interesting thread since EPS is so important for embedding PostScript inside other documents. Therefore, I decided to compare psc results with pscairo results (even though I know little of the PostScript language). Here is what I could glean from the comparison. * Different identifications. psc:%!PS-Adobe-2.0 EPSF-2.0 pscairo: %!PS-Adobe-3.0 IOW, psc is specifically identifying itself as encapsulated postscript while pscairo is not. How does the result print if you edit the psc file to remove " EPSF-2.0" from the identification? My understanding is that EPS is just a collection of constraints on a valid PostScript document. So if the print result is suddenly well-behaved, that probably means your printer software finds something about the file that it will not accept or misinterprets under the EPS constraints, but which it interprets correctly as PostScript. OTOH if your result is still the same, that probably means there is a general PostScript command buried in the file which your printer is ignoring or misinterpreting. Another experiment I would try is to append " EPSF-3.0" to the pscairo identification to see how your printer responds. Even though pscairo is not specifically identified as EPS, it does have a bounding box (which AFAIK is the principal EPS constraint) so it is likely to be valid EPS, and it would be interesting to see if your printer software agreed with that assessment. I hasten to add we would not want to remove the EPS identification for our psc results since I actually think they do follow the EPS rules, but the above experiments might help us figure out what the problem is. * Different methods of specifying the bounding boxes. Note psc has an accurate bounding box while a pscairo deficiency is the bounding box is a little larger than actually required. psc: %%BoundingBox: 44 44 580 738 pscairo: %%BoundingBox: 0 0 540 720 So far so good with psc. In fact, I think one overall bounding box specification (like psc does it) is sufficient according to the EPS standard, but I notice that pscairo repeats the bounding box information for each page, e.g., with %%Page: 1 1 %%BeginPageSetup %%PageBoundingBox: 0 0 540 720 %%EndPageSetup The corresponding psc command is just %%Page: 1 1 Perhaps your printer software needs these extra commands to set up the individual page (even though those commands appear to be redundant for Arjen's printer)? Anyhow, try adding those commands to your psc file (with the exact bounding box values as taken from the psc file header) right after the Page command to see how the printer responds. If that is all that is necessary to satisfy your printer it should be possible to make the relevant changes in ps.c (and also psttf.c which pretty much follows the PostScript style of ps.c). 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ ------------------------------------------------------------------------- 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
