Re: [NTG-context] Bloody PDF boxes and cr*p marks!

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