Bloody PDF boxes and cr*p marks!

newer
\externafigure and \at do not work...

older
PDF text stream with delimitedtext

Henning Hraban Ramm

12 Oct 2021 12 Oct '21

10:36 a.m.

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.) Ok, calm down, try again... * MediaBox is supposed to be the biggest, i.e. print sheet. * CropBox is the viewable area – usually same as MediaBox or TrimBox makes sense. * BleedBox must be TrimBox plus bleed. * ArtBox is neglectable for whole layouts (same as TrimBox might make sense), just interesting in \externalfigure. 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 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)! 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). 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! 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! 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”. Hraban

Show replies by date

Hans Hagen

12 Oct 12 Oct

11:15 a.m.

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!

...

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”.

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) 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 -----------------------------------------------------------------

Henning Hraban Ramm

4:18 p.m.

...

Am 12.10.2021 um 13:15 schrieb Hans Hagen :

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.

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).

Hm, you implemented these boxes only in 2015, there was not much change in that regard since then.

...

...
* BleedBox must be TrimBox plus bleed.

a relative new one, probably also sensitive for interpretation by renderer, imo worthless

Not worthless; workflow systems in printshops rely on BleedBox and TrimBox. It’s not about rendering, but imposition and even postprocessing (cutting etc.).

...

...
* ArtBox is neglectable for whole layouts (same as TrimBox might make sense), just interesting in \externalfigure.

also worthless

I agree.

...

...
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 ...

Who sends PDF files directly to a printer (driver)? I know it only from automated, professional workflows. Usually printer drivers gets fed by PDF viewers, and I know none that even *can* print something different than CropBox.

...

...
Beware, \setupbleeding refers only to stretching of images (\externalfigure)!

fwiw, that bleeding options is mostly there to communicate with mp

Good to know. I just browsed the Details manual, didn’t try it yet, since I scale and move my “bleeding” images differently.

...

...
* 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

But it’s convenient ;) I usually just need a format that is big enough for the crop marks, and “oversized” does that.

...

...
% ... and no dependency on interactionscreen!

that's a historic fact ... special pdf features triggered by that command .. basically tex only has a page size

Of course, but it doesn’t make sense any more, and defining the boxes wouldn’t hurt anyone. (I’m quite sure, but let them beat me ;))

...

...
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)

I wouldn’t expect printers (office printing devices) to react at all; I hope that printers (printshop workers) will react positively to correct boxes in our PDFs ;)

...

...
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)

Multiple pages on a sheet are not considered by the PDF specs.

...

(i'm pretty sure that changes will themselves introduce new issues)

Probable.

...

anyway, we can look at it once we're all on lmtx because i'm not going to change mkiv in that aspect

Ok Hraban

Hans Hagen

6:48 p.m.

On 10/12/2021 6:18 PM, Henning Hraban Ramm via ntg-context wrote:

...

...
Am 12.10.2021 um 13:15 schrieb Hans Hagen :

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.

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).

Hm, you implemented these boxes only in 2015, there was not much change in that regard since then.

Way earlier but it wasn't enabled ... (I'm not going to check ancient tex live dvd's). addtopageattributes("CropBox",box) -- mandate for rendering addtopageattributes("TrimBox",box) -- mandate for pdf/x -- addtopageattributes("BleedBox",box) -- addtopageattributes("ArtBox",box) I remember discussing it with (I think) Pablo and it definityely came up when we were dealing with these 'standards'.

...

...
...
* BleedBox must be TrimBox plus bleed.

a relative new one, probably also sensitive for interpretation by renderer, imo worthless

Not worthless; workflow systems in printshops rely on BleedBox and TrimBox. It’s not about rendering, but imposition and even postprocessing (cutting etc.).

...
...
* ArtBox is neglectable for whole layouts (same as TrimBox might make sense), just interesting in \externalfigure.

also worthless

I agree.

...
...
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 ...

Who sends PDF files directly to a printer (driver)? I know it only from automated, professional workflows. Usually printer drivers gets fed by PDF viewers, and I know none that even *can* print something different than CropBox.

afaik some printers accept pdf (hard to check) but I the fact that a viewer does something doesn't mean it did years ago (just like at how crippled tounicode has been / is supported over time)

...

...
...
Beware, \setupbleeding refers only to stretching of images (\externalfigure)!

fwiw, that bleeding options is mostly there to communicate with mp

Good to know. I just browsed the Details manual, didn’t try it yet, since I scale and move my “bleeding” images differently.

i actually need to pick up that bit ... (some code in my local styles i need to check) because it can be handy for cover pages (but then i also need to check if i don't break something

...

...
...
* 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

But it’s convenient ;) I usually just need a format that is big enough for the crop marks, and “oversized” does that.

sure, i use it too

...

...
...
% ... and no dependency on interactionscreen!

that's a historic fact ... special pdf features triggered by that command .. basically tex only has a page size

Of course, but it doesn’t make sense any more, and defining the boxes wouldn’t hurt anyone. (I’m quite sure, but let them beat me ;))

maybe, but it's also a bit about otr/backend timing, so i need to sit down on it

...

...
...
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)

I wouldn’t expect printers (office printing devices) to react at all; I hope that printers (printshop workers) will react positively to correct boxes in our PDFs ;)

oh, i'm often surprised about printing houses .. (the best were some comment on a file having rgb bitmaps while it actually had cmyk outlines and validators/fixers inlining xforms while setting lines to 0pt widths) .. and some still use acrobat 4 -)

...

...
...
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)

Multiple pages on a sheet are not considered by the PDF specs.

yes but what of context imposes

...

...
(i'm pretty sure that changes will themselves introduce new issues)

Probable.

...
anyway, we can look at it once we're all on lmtx because i'm not going to change mkiv in that aspect

Ok remind me in a few months (it's a typical boring winter evening activity with some music blu ray (or movie) running on a second screen)

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 -----------------------------------------------------------------

Henning Hraban Ramm

19 Oct 19 Oct

8:10 p.m.

...

Am 12.10.2021 um 20:48 schrieb Hans Hagen :

...
Hm, you implemented these boxes only in 2015, there was not much change in that regard since then.

Way earlier but it wasn't enabled ... (I'm not going to check ancient tex live dvd's).

addtopageattributes("CropBox",box) -- mandate for rendering addtopageattributes("TrimBox",box) -- mandate for pdf/x -- addtopageattributes("BleedBox",box) -- addtopageattributes("ArtBox",box)

I remember discussing it with (I think) Pablo and it definityely came up when we were dealing with these 'standards'.

Ok. I found it in lpdf-mis.lua, maybe I’ll use the Lua function directly.

...

...
...
well, that's an assumption ... who knows what a printer (driver) does ... Who sends PDF files directly to a printer (driver)? I know it only from automated, professional workflows. Usually printer drivers gets fed by PDF viewers, and I know none that even *can* print something different than CropBox.

afaik some printers accept pdf (hard to check) but I the fact that a viewer does something doesn't mean it did years ago (just like at how crippled tounicode has been / is supported over time)

Yes, you can send PDF files to some copiers and other professional printing devices. But usually you do this via the manufacturer’s workflow tools – only a few admins still know how to (ab)use a prn queue ;)

...

...
...
...
Beware, \setupbleeding refers only to stretching of images (\externalfigure)!

fwiw, that bleeding options is mostly there to communicate with mp Good to know. I just browsed the Details manual, didn’t try it yet, since I scale and move my “bleeding” images differently.

i actually need to pick up that bit ... (some code in my local styles i need to check) because it can be handy for cover pages (but then i also need to check if i don't break something

I’d be interested to see what you’re trying. I want to create my covers more and more with ConTeXt to avoid manual adaptions due to number of pages.

...

...
...
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) I wouldn’t expect printers (office printing devices) to react at all; I hope that printers (printshop workers) will react positively to correct boxes in our PDFs ;)

oh, i'm often surprised about printing houses .. (the best were some comment on a file having rgb bitmaps while it actually had cmyk outlines and validators/fixers inlining xforms while setting lines to 0pt widths) .. and some still use acrobat 4 -)

Yep, last weekend I finally sent the latest issue of our magazine to the printshop, of course with correctly set boxes (and markings activated), and since the content didn’t need bleed this time, I set the CropBox to TrimBox. Everything in perfect order – but they charged me for adding crop marks... (Without even asking back.) I’ll teach them PDF basics. BTW, is there a hook to replace crop marks with my own? Ah, found page-mrk.mkiv Can I just replace \startuniqueMPgraphic{print:lines} ? (Something to play with if I get into MP mode...)

...

...
...
probably spreads need some treatment (imposition) Multiple pages on a sheet are not considered by the PDF specs.

yes but what of context imposes

Right. IMO, if there’s a BleedBox defined, ConTeXt should use it as “page size”, otherwise CropBox.

...

remind me in a few months (it's a typical boring winter evening activity with some music blu ray (or movie) running on a second screen)

I’ll never understand how others can work with such distractions ;) Hraban

Henning Hraban Ramm

30 Oct 30 Oct

7:21 p.m.

I finally reworked the wiki page https://wiki.contextgarden.net/PDF_Boxes and also extended https://wiki.contextgarden.net/PDFX a bit. Hraban

Duncan Hothersall

1 Nov 1 Nov

5:45 a.m.

Thank you for this, that's the first time this stuff has made any sense to me. On Sat, 30 Oct 2021 at 20:22, Henning Hraban Ramm via ntg-context < ntg-context@ntg.nl> wrote:

...

I finally reworked the wiki page https://wiki.contextgarden.net/PDF_Boxes and also extended https://wiki.contextgarden.net/PDFX a bit.

Hraban

___________________________________________________________________________________ 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

___________________________________________________________________________________

Floris van Manen

7:05 a.m.

On 30/10/2021 21:21, Henning Hraban Ramm via ntg-context wrote: this document:

...

and also extendedhttps://wiki.contextgarden.net/PDFX a bit.

contains a link to the Ghent Workshop that returns a 404 Special thanks must go to the Ghent PDF Workgroup (GWG) for making a list of recommended profiles. Please have a look at the official documentation first (will take you only a minute). The origin of this document (and some more info) is located [here]. [here] -> http://www.gwg.org/recommended_ICC_profiles.phtm -> 404 .F

Henning Hraban Ramm

7:58 a.m.

New subject: Color profiles (was: Bloody PDF boxes)

...

Am 01.11.2021 um 08:05 schrieb Floris van Manen via ntg-context :

this document:

...
and also extendedhttps://wiki.contextgarden.net/PDFX a bit.

contains a link to the Ghent Workshop that returns a 404

[here] -> http://www.gwg.org/recommended_ICC_profiles.phtm -> 404

Thank you. The information from 2008 was outdated anyway; GWG’s latest recommendations from 2015 don’t contain ICC profiles any more (maybe their settings for commercial applications do, didn’t check). And it seems like GWG is in conflict with the PDF association, at least GWG’s recommendations contradict PDF/X. I’ll try to reflect both... From my personal experience: – If you don’t exactly know what you’re doing, you should use sRGB as RGB working color space, because most cameras and scanners use it. Yes, parts of the color space are outside the printable range, that’s why GWG (used to) recommend ECI RGB. – Don’t use CMYK images, since they’re bigger, and if they’re not in the same CMYK color space as the one used by the printshop, the conversion is more lossy than any RGB-CMYK conversion. – You can use DeviceCMYK (i.e. without profile) for graphical elements, that’s what GWG recommends, but it’s against PDF/X-3+. – Use the latest FOGRA (Coated/Uncoated) CMYK profile as output intent, at least that’s what German/European printshops use in offset and digital printing. If not, your printshop should tell you which profile they use. – For printing in the USA, use a SWOP CMYK profile as output intent. (SWOP and Euroscale CMYK colors are visibly different!) – I don’t know about printshops in other parts of the world. Hraban

Henning Hraban Ramm

8:07 a.m.

New subject: Color profiles (was: Bloody PDF boxes)

...

Am 01.11.2021 um 08:58 schrieb Henning Hraban Ramm via ntg-context :

And it seems like GWG is in conflict with the PDF association, at least GWG’s recommendations contradict PDF/X.

GWG doesn’t want to contradict but has a quality focus, see https://www.pdfa.org/further-quality-requirements-pdfx-plus/ (I attended a few workshops by the author Stephan Jaeggi in about 2005...) Hraban

1147

Age (days ago)

1167

Last active (days ago)

List overview

Download

9 comments

4 participants

participants (4)

Duncan Hothersall
Floris van Manen
Hans Hagen
Henning Hraban Ramm

Bloody PDF boxes and cr*p marks!

tags

participants (4)