On 10/12/2021 12:36 PM, Henning Hraban Ramm via ntg-context wrote:
Comrades!
There must have been a time when PDF boxes (i.e. CropBox, TrimBox, BleedBox)
worked as they should, but it must have been a short time.
The wiki page https://wiki.contextgarden.net/PDF_Boxes is mostly a
documentation of bugs and workarounds, but even that is not entirely correct
(any more?).
I gave up on that subject and still fix the boxes with Acrobat Pro whenever I
need them to be correct. But that’s no solution.
(And it’s probably also my fault, since I was one of those who wanted this
implemented and then didn’t check enough if it does what it should.)
I long ago lost track of what all that means ... decades of pdf ...
different viewers, different interpretations ... validators complaining
about things missing ... i guess that bit (like annotations) will always
be in flux (also because specs came before implementations i guess).
Ok, calm down, try again...
* MediaBox is supposed to be the biggest, i.e. print sheet.
it is the oldest o fthe pack
* CropBox is the viewable area – usually same as MediaBox or TrimBox makes
sense.
needed, in order to make it possible to use a pdf as image
* BleedBox must be TrimBox plus bleed.
a relative new one, probably also sensitive for interpretation by
renderer, imo worthless
* ArtBox is neglectable for whole layouts (same as TrimBox might make sense),
just interesting in \externalfigure.
also worthless
According to PDF Standard, MediaBox is the only required one; but CropBox is
the most important one, since PDF viewers rely on it.
With
\setuppaper[A4]
all boxes can be the same (or undefined). Status quo.
With
\setuppaper[A4][A4,oversized]
I’d expect ConTeXt to set...
* MediaBox and CropBox to the bigger format
* TrimBox to the page format (A4)
* BleedBox also to the page format, while no bleed is defined
well, that's an assumption ... who knows what a printer (driver) does ...
Status quo: no additional boxes defined.
Beware, \showframe draws a green box at the paper size (supposed TrimBox), this is
misleading in Acrobat Reader & Pro, where the TrimBox is shown in green (if
this option is activated)!
Bleed is to be defined in \setuplayout:
\showframe
\setuppapersize[A4][A4,oversized]
\setuplayout[
location=middle,
bleedoffset=-5mm,
marking=on,
]
%\setupinteractionscreen[width=max,height=max]
\starttext
X
\stoptext
Status quo:
* works only with \setupinteractionscreen
* bleedoffset must be negative
* BleedBox is set, but not TrimBox (TB > BB is a nesting error)
Beware, \setupbleeding refers only to stretching of images (\externalfigure)!
fwiw, that bleeding options is mostly there to communicate with mp
This gives more or less correct results:
\setuplayout[
location=middle,
trimoffset=-7.5mm,
bleedoffset=3mm,
marking=on,
]
* still works only with \setupinteractionscreen
* negative trimoffset defines the TrimBox (actual page size), value is
subtracted from sheet size.
* positive bleedoffset (internally added to trimoffset)
* to define trimoffset, I must know the difference between paper size and sheet size
("oversized" adds 15 mm).
oversized is a convenience feature, in prepress one would define a real,
target size, not rely on a convenience value
I.e. ConTeXt “thinks” from the sheet size instead from the (IMO more natural)
paper size.
For me, the more natural setup would be:
\setuplayout[
trimoffset=0mm, % from the paper size outward
bleedoffset=3mm, % same, independent of trimoffset
]
% ... and no dependency on interactionscreen!
that's a historic fact ... special pdf features triggered by that
command .. basically tex only has a page size
So far, I ignored cropoffset.
The parameter in itself works as I expected it to: cropoffset=3mm decreases the
visible area by 3mm on each side.
But it also moves the other boxes by that value!
IMO that makes no sense, CropBox can be completely independent of the other
boxes!
It would be logical to use negative values here, since the size decreases, in
opposite to my suggested handling of the other parameters.
Yes, that would mean a backward incompatible change. But how many of us rely on
the strange current behavior?
Please let us fix this!
the problem is as usual documentation and indeed we can have some
backward compatibility issue here ... i honestly have no clue how
viewers and printers react (so if something would be added/changed it
would be option driven)
In some cases it makes sense to have different values on e.g. inner and outer
edges; I feat that would add a plethora of additional parameters
(leftbleedoffset, innerbleedoffset...).
Maybe give a list like in CSS? bleedoffset={3mm,3mm,3mm,0mm} – top, right,
bottom, left order implied; not very “ConTeXt style”.
probably spreads need some treatment (imposition)
(i'm pretty sure that changes will themselves introduce new issues)
anyway, we can look at it once we're all on lmtx because i'm not going
to change mkiv in that aspect
Hans
-----------------------------------------------------------------
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___________________________________________________________________________________
