[softwarelist] Re: OPro script prpagew() (RISC OS)
- From: Gavin Crawford <gav@xxxxxxxxxxxxxx>
- To: davidpilling@xxxxxxxxxxxxx
- Date: Mon, 29 Aug 2016 12:44:21 +0100
In message <ed5d72f4-1a76-32c6-9d23-e849795269a1@xxxxxxxxxxxxxxxxxxx>
David Pilling <david@xxxxxxxxxxxxxxxxxxx> wrote:
Hi Gavin,
On 21/08/2016 17:16, Gavin Crawford wrote:
I don't suppose OPro already has these values stored in some variables
that are accessible to scripts, but not mentioned in the manual?
I looked. Apparently not.
Shame.
It's not clear what you would want. There is (as you said) paperbleed().
Crop marks are set from choices, so you might read them from the script
file or similar tricks.
What I'm trying to achieve is to get the bounding box values for the
area that the crop marks surround, as the trim area on the paper
(after any imposition has occured). Along with the area denoted by any
bleed - typically a 2 or 3mm margin outside the crop marks/trim area.
The values are then represented as x,y lower left corner and x,y upper
right corner in page units, i.e. in points, and are inserted as
follows:
[{ThisPage} << /TrimBox [xll yll xur yur] >> /PUT pdfmark
[{ThisPage} << /BleedBox [xll yll xur yur] >> /PUT pdfmark
This then sets the trim and bleed areas in the PDF so other imposition
software can recognise the areas. For example you may send to a
commercial printshop a PDF of an A5 leaflet with crop marks and bleed,
set up on an oversized paper size such as SRA5. The printshop will
often have automated imposition tools to take the A5 and produce it
4up on SRA3. Many of the automated tools look for any trim and bleed
values that may be already set in the PDF. This saves an operator
having to manually set them up before being imposed.
I've have managed to get the figures that seem to work for my usual
settings.
TRIM:
shiftx=prpageshiftx();
shifty=prpageshifty();
workw=prworkw();
workh=prworkh();
marks=papermarks();
markx=papermarkx(marks);
marky=papermarky(marks);
trimxll=shiftx+(markx/2);
trimyll=shifty+(marky/2);
trimxur=txll+(workw-markx);
trimyur=tyll+(workh-marky);
These values are are still in 1/1000 pt but I convert them to pts for
outputting.
BLEED:
bleed=paperbleed();
xll=shiftx+(markx/2)-bleed;
yll=shifty+(marky/2)-bleed;
xur=txll+(workw-markx)+bleed;
yur=tyll+(workh-marky)+bleed;
I do need to test it with many different possibilities of bleed &
printers marks settings to make sure it doesn't throw up some strange
values, before I could ever release the applet into the big wide
world.
If I had the chance to do it all again. Tell me - would we? could we? -
...it was all so simple then, or has time rewritten every line?
Well I wouldn't - but if I did, I'd make it so that anything that can be
written could be read. I suppose it would end up looking like the web
page DOM.
Yes it's interesting how different concepts have emerged over the
years, such as the DOM model and XML based everything. Concepts that
probably wouldn't have been possible back in the days of 1MB RAM and
slow processors (by todays standards).
To unsubscribe or subscribe goto:
//www.freelists.org/list/davidpilling
Other related posts:
