!printers or postscript
Pages: 1 2
Colin (478) 2433 posts |
I’ve been trying to print a document, which has a custom paper size set up in !printers, as a pdf file using !printpdf but ghostscript always fails. Looking at the postscript file the offending lines are
RM is the name of the paper set up in ‘Edit paper sizes’ in !Printers. If I change rm to a1,a2 or a3 !printpdf creates the pdf file on a1,a2 or a3 paper. It seems obvious to me that if the only thing defining the page size is the name of the paper that a postscript device wouldn’t know about a custom paper size name. Anyone know how to print pdfs to a custom paper size? |
Rick Murray (539) 13385 posts |
Not like that. It appears as if GhostScript inky recognises specific paper sizes. Can PrintPDF let you add to or modify the commands used to generate the PDF? You can apparently do it from the command line – have a look at this: http://stackoverflow.com/questions/12675371/how-to-set-custom-page-size-with-ghostscript |
Colin (478) 2433 posts |
In case it is of interest to anyone this is how I did it. 1. Set up a page size in !printers width 190.5mm = 540pt, height = 228.6mm = 648
-dPDFFitPage didn’t seem to do anything -dDEVICEWIDTHPOINTS=540 -dDEVICEHEIGHTPOINTS=648 clips the paper so if you use the wrong paper size in !printers you just get the bottom left hand section of whatever the !Printers paper size was. |
Rick Murray (539) 13385 posts |
Inky? Inky??? |
Chris Dewhurst (1709) 152 posts |
Er, have given up guessing Rick. What was “Inky” supposed to be…? |
Colin (478) 2433 posts |
only. After a while you can predict the predictive text :-) Edit: Poirot mode. I think its unfair of Rick to blame the spell checker. i is next to o on the keyboard and k is next to l. Now if Rick has fat fingers on a small touchscreen only can easily become inky which is a proper word so won’t be spell checked. So my conclusion is Rick has fat fingers :-) |
Trevor Johnson (329) 1645 posts |
My phone recently “autocorrected” het1 to heterosexual and rhe2 to rhetorical! 1 get 1 the |
Rick Murray (539) 13385 posts |
I dont Kajiura aboutir faut funeste Crap – was still in French mode. Anyway, I don’t know about fat fingers, I’m a bit cack-handed with typing so I use the swipey-typey; it’s just that the first option offered is often not the word you wanted. For illustration – is justified that the first words offered is often boot the works you warranted. That was the same adenosine (???? sentence) only accepting the words it thought I wanted. |
Steve Fryatt (216) 2044 posts |
Possibly. You can certainly feed it a PDFMark file via the dialogue, but I think this is just PDFMark and not the command line itself. I’ll look into adding some sensible page size support, however; it would certainly be useful. |
Steve Fryatt (216) 2044 posts |
There’s now a test build of PrintPDF at http://www.stevefryatt.org.uk/software/test/ which contains support for setting paper sizes. As well as the old behaviour of letting GhostScript try and work things out from the paper name set by the printer driver, r1887 will let the user select one of the numerous “standard” sizes that GhostScript supports or define a custom page size to suit their document. It’s a test build so while it appears to work for me, feedback and bug reports are welcome. (ETA: Thanks to Rick for the pointer upthread towards what to search for in the GhostScript documentation!) |
Colin (478) 2433 posts |
I’m afraid it doesn’t work for me because all the commands Rick pointed out to you to do is clip the paper relative to the paper bottom left not the document bottom left. To get the correct origin for the document I need to also set a custom papersize in !printers with the correct dimensions and name it “A0 anything”. The postscript driver ignores the ‘anything’ and puts a PageSize name of ‘A0’ in the postscript file – this stops ghostscript failing because of an unknown paper name. You can then use Rick’s commands to clip the paper. An ideal solution for me would be if you could name the paper ‘w19050h22860’ (mm x 100) in !printers and !PrintPdf then searched for the PageSize line, replaced ‘w19050h22860’ with ‘A0’ and clipped the paper to the dimensions in the paper name. Then I don’t need to set anything in !PrintPdf |
Steve Fryatt (216) 2044 posts |
As far as I know, GS only fails for an unknown paper size if you don’t tell it what paper size you’re trying to use via the command line parameters? Assuming that the origins match, aren’t you just reinforcing the printer driver’s page size in PrintPDF?
I agree that this avoids setting things in PrintPDF, but what other advantages does this have? Editing the contents of the PS file isn’t trivial, as you’re looking at changing something at the start of a file that could be many MB in size. It’s not impossible, but I’d need convincing that there’s a good reason as it’s the complete opposite of how PrintPDF has been developed to work (“use parameters and PDFMark data; don’t touch the original PS data at all”). |
Colin (478) 2433 posts |
!printers embeds the pagesize in the postscript file as I’ve shown when I started the thread. If I print to a !printers custom page size called ‘RM’ RM gets embedded and ghostscript fails. Your modification requires me to set a custom paper size in !printers and pick a custom paper size in !PrintPdf. So that means I have to set a paper size in techwriter, remember to set the paper size in !printers and now set the paper size in !printpdf. As I see it all you are doing in PrintPDF is guillotining the paper which isn’t what is required. Even with the changes its still easier to use a ghostscript obey file. Anyway its just a thought. I’ve worked out what I need to do now so it’s not a problem for me. Personally I’d remove your changes as they just add more to the confusion. Standard Size Names can be used ‘Paper Sizes’ in !printers – where they should be set – so you wouldn’t need to set them in !printpdf. If there is a way of specifying PaperSize by dimensions maybe the best solution is a modification to !Printers. |
nemo (145) 2437 posts |
I’m sorry I was away when one of those questions I am uniquely qualified to answer comes by. :-( OK, !Printers paper handling is staggeringly stupid, assuming that if you define a page size called ‘foo’ it can select it using the PostScript operator ‘foo’ (in the absence of some magic). D’oh! Once upon a time, for convenience (and not by definition) you could select some paper sizes on some PostScript devices by name. But only if you were lucky. That’s absolutely NOT the way to do it in general (not that “that’s not the way to do it” informed any part of Acorn’s PostScript printer driver design). In the real world you set page size using the setpagedevice operator. The bit of ‘magic’ I implied earlier is that !Printers first looks in Printers:ps.Paper for a PostScript snippet with the same name as your paper. Ideally !Printers would just emit the correct PostScript in the first place, but in the absence of that, to set a custom page size you do this: 1. Create a new page size in !Printers, eg 190.5mm, 228.6mm and call it ‘190x228’ %%BeginFeature: PageSize 190.5x228.6mm << /PageSize [ 190.5 2.835 mul 228.6 2.835 mul ] >> setpagedevice %%EndFeature Hey presto, correct page size. Hopefully it should be obvious what to change in that file to create other page sizes. As I said, PDriverPS ought to spit this out itself (and programs such as Impression and Vantage do so anyway) but this manual method does work. |
Colin (478) 2433 posts |
Thanks that worked a treat – after I discovered it was case sensitive :-). I also used a %% instead of % at the beginning. |
Steve Pampling (1551) 7921 posts |
I may be missing something (Colin did say that worked) but the only ps.Paper directory I can see is in !Printers not in Choices.Printers. |
Colin (478) 2433 posts |
I used the one in !printers |
nemo (145) 2437 posts |
Thanks. Typo fixed.
Create one.
Yeah, don’t do that. Next time you update !Printers you could lose it. |
Colin (478) 2433 posts |
I can lose things from !boot when I update that – which I do more often than I change !printers. I’d really like my choices separate from !boot. There used to be !Choices but don’t know what happened to it. |
Steve Pampling (1551) 7921 posts |
Shouldn’t printers do that when it runs? like it created the printers directory and content including the ps sub-directory
Then again most people update by copying over the top. |
Steve Fryatt (216) 2044 posts |
Having thought about this some more over the weekend, I think there’s some info missing from Colin’s description. While the PS2 driver is indeed “staggeringly stupid”, AFAIK the PS3 driver inserts a valid setpagedevice block into the output PS. This probably explains why I’d not really considered the mess before: I only use the PS3 driver nowadays (and I’ve also got some sane files in ps.Paper to save the PS2 driver from it’s own stupidity — I’ve no idea where they came from…). It would be useful to know which driver Colin is (was) using. 1. Create a new page size in !Printers, eg 190.5mm, 228.6mm and call it ‘190×228’ Would there be any reason for not scanning the list of defined pages sizes and creating suitable snipppets in ps.Paper whenever new page sizes are defined? I’m thinking here of either updating !Printers to do it as part of the paper size editor, or creating a separate utility which the user could run after saving the page sizes in the front-end. |
Steve Pampling (1551) 7921 posts |
Having looked at the equivalent snippets for A4 and A3, legal etc I think I see the braindead element that nemo refrerred to – the snippets don’t define the values but just assume the printer actually has some defaults that can be referred to. Perhaps all those existing snippets need re-writing to define the dimensions and a few extras can be created. |
Colin (478) 2433 posts |
Not sure what you want a date for, I’m using !printers 1.81. Is that what you want? I don’t see why !Printers is adding the paper size postscript snippets it must know the paper dimensions so why can’t it just add that. |
Steve Fryatt (216) 2044 posts |
No: I’m assuming you’re using the Postscript Level 2 driver supplied with the OS? There is also the Postscript Level 3 driver sold for £35 by John Tytgat and Martin Wuerthner1, which was developed to resolve some of the more, er, “staggeringly stupid” aspects of Acorn’s Postscript 2 implementation (as well as add a lot of other useful stuff). If you were using that with PrintPDF, I think things would “just have worked” because the generated PS file contains the correct information by default (I’ve just tried it, and it spat out
into the PS for a randomly named paper size).
It isn’t actually Printers doing this, as I realised over the weekend: this is a feature of the Postscript 2 driver. The Postscript 3 driver does add the paper dimensions, using more or less the code that Nemo recommended adding to the Postscript 2 driver’s snippets files. The files in ps.Paper and putting just a paper name into the PS file by default is only an issue if you’re using the Postscript 2 driver. It would be nice to make the PS2 driver work more sanely (hence my question about automatically generating those snippets, which could be easy to do), but unless we’re planning to re-invent the work done on the PS3 drivers (which seems a massive waste of everyone’s time), I’d suggest that perhaps the best solution would be to concentrate on PS3 (and encourage anyone who hits the deficiencies of Acorn’s PS2 implementation to upgrade). Thoughts welcomed, as I’m no expert on any of this. |
Colin (478) 2433 posts |
No-ones going to write a new ps3 driver, but thats no reason not to make things easier for ourselves. Somewhere in the ps2 drivers it loads a paper file to include in the postscript file. It can’t be that difficult to replace that code with code to insert the paper size instead – even if you just create a paper size file on the fly in pipefs and insert that. |
Pages: 1 2