ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
* Bloody PDF boxes and cr*p marks!
@ 2021-10-12 10:36 Henning Hraban Ramm via ntg-context
  2021-10-12 11:15 ` Hans Hagen via ntg-context
  0 siblings, 1 reply; 10+ messages in thread
From: Henning Hraban Ramm via ntg-context @ 2021-10-12 10:36 UTC (permalink / raw)
  To: mailing list for ConTeXt users; +Cc: Henning Hraban Ramm

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




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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Bloody PDF boxes and cr*p marks!
  2021-10-12 10:36 Bloody PDF boxes and cr*p marks! Henning Hraban Ramm via ntg-context
@ 2021-10-12 11:15 ` Hans Hagen via ntg-context
  2021-10-12 16:18   ` Henning Hraban Ramm via ntg-context
  0 siblings, 1 reply; 10+ messages in thread
From: Hans Hagen via ntg-context @ 2021-10-12 11:15 UTC (permalink / raw)
  To: mailing list for ConTeXt users; +Cc: 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.
> 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
___________________________________________________________________________________

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Bloody PDF boxes and cr*p marks!
  2021-10-12 11:15 ` Hans Hagen via ntg-context
@ 2021-10-12 16:18   ` Henning Hraban Ramm via ntg-context
  2021-10-12 18:48     ` Hans Hagen via ntg-context
  0 siblings, 1 reply; 10+ messages in thread
From: Henning Hraban Ramm via ntg-context @ 2021-10-12 16:18 UTC (permalink / raw)
  To: mailing list for ConTeXt users; +Cc: Henning Hraban Ramm


> Am 12.10.2021 um 13:15 schrieb Hans Hagen <j.hagen@xs4all.nl>:
> 
> 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

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Bloody PDF boxes and cr*p marks!
  2021-10-12 16:18   ` Henning Hraban Ramm via ntg-context
@ 2021-10-12 18:48     ` Hans Hagen via ntg-context
  2021-10-19 20:10       ` Henning Hraban Ramm via ntg-context
  0 siblings, 1 reply; 10+ messages in thread
From: Hans Hagen via ntg-context @ 2021-10-12 18:48 UTC (permalink / raw)
  To: mailing list for ConTeXt users; +Cc: Hans Hagen

On 10/12/2021 6:18 PM, Henning Hraban Ramm via ntg-context wrote:
> 
>> Am 12.10.2021 um 13:15 schrieb Hans Hagen <j.hagen@xs4all.nl>:
>>
>> 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
-----------------------------------------------------------------
___________________________________________________________________________________
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
___________________________________________________________________________________

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Bloody PDF boxes and cr*p marks!
  2021-10-12 18:48     ` Hans Hagen via ntg-context
@ 2021-10-19 20:10       ` Henning Hraban Ramm via ntg-context
  2021-10-30 19:21         ` Henning Hraban Ramm via ntg-context
  0 siblings, 1 reply; 10+ messages in thread
From: Henning Hraban Ramm via ntg-context @ 2021-10-19 20:10 UTC (permalink / raw)
  To: mailing list for ConTeXt users; +Cc: Henning Hraban Ramm


> Am 12.10.2021 um 20:48 schrieb Hans Hagen <j.hagen@xs4all.nl>:
> 
>> 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


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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Bloody PDF boxes and cr*p marks!
  2021-10-19 20:10       ` Henning Hraban Ramm via ntg-context
@ 2021-10-30 19:21         ` Henning Hraban Ramm via ntg-context
  2021-11-01  5:45           ` Duncan Hothersall via ntg-context
  2021-11-01  7:05           ` Floris van Manen via ntg-context
  0 siblings, 2 replies; 10+ messages in thread
From: Henning Hraban Ramm via ntg-context @ 2021-10-30 19:21 UTC (permalink / raw)
  To: mailing list for ConTeXt users; +Cc: Henning Hraban Ramm

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
___________________________________________________________________________________

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Bloody PDF boxes and cr*p marks!
  2021-10-30 19:21         ` Henning Hraban Ramm via ntg-context
@ 2021-11-01  5:45           ` Duncan Hothersall via ntg-context
  2021-11-01  7:05           ` Floris van Manen via ntg-context
  1 sibling, 0 replies; 10+ messages in thread
From: Duncan Hothersall via ntg-context @ 2021-11-01  5:45 UTC (permalink / raw)
  To: mailing list for ConTeXt users; +Cc: Duncan Hothersall


[-- Attachment #1.1: Type: text/plain, Size: 844 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 2077 bytes --]

[-- Attachment #2: Type: text/plain, Size: 493 bytes --]

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Bloody PDF boxes and cr*p marks!
  2021-10-30 19:21         ` Henning Hraban Ramm via ntg-context
  2021-11-01  5:45           ` Duncan Hothersall via ntg-context
@ 2021-11-01  7:05           ` Floris van Manen via ntg-context
  2021-11-01  7:58             ` Color profiles (was: Bloody PDF boxes) Henning Hraban Ramm via ntg-context
  1 sibling, 1 reply; 10+ messages in thread
From: Floris van Manen via ntg-context @ 2021-11-01  7:05 UTC (permalink / raw)
  To: ntg-context; +Cc: Floris van Manen



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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Color profiles (was: Bloody PDF boxes)
  2021-11-01  7:05           ` Floris van Manen via ntg-context
@ 2021-11-01  7:58             ` Henning Hraban Ramm via ntg-context
  2021-11-01  8:07               ` Henning Hraban Ramm via ntg-context
  0 siblings, 1 reply; 10+ messages in thread
From: Henning Hraban Ramm via ntg-context @ 2021-11-01  7:58 UTC (permalink / raw)
  To: mailing list for ConTeXt users; +Cc: Henning Hraban Ramm


> Am 01.11.2021 um 08:05 schrieb Floris van Manen via ntg-context <ntg-context@ntg.nl>:
> 
> 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
___________________________________________________________________________________
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
___________________________________________________________________________________

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Color profiles (was: Bloody PDF boxes)
  2021-11-01  7:58             ` Color profiles (was: Bloody PDF boxes) Henning Hraban Ramm via ntg-context
@ 2021-11-01  8:07               ` Henning Hraban Ramm via ntg-context
  0 siblings, 0 replies; 10+ messages in thread
From: Henning Hraban Ramm via ntg-context @ 2021-11-01  8:07 UTC (permalink / raw)
  To: mailing list for ConTeXt users; +Cc: Henning Hraban Ramm


> Am 01.11.2021 um 08:58 schrieb Henning Hraban Ramm via ntg-context <ntg-context@ntg.nl>:
> 
> 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
___________________________________________________________________________________
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
___________________________________________________________________________________

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-11-01  8:07 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-12 10:36 Bloody PDF boxes and cr*p marks! Henning Hraban Ramm via ntg-context
2021-10-12 11:15 ` Hans Hagen via ntg-context
2021-10-12 16:18   ` Henning Hraban Ramm via ntg-context
2021-10-12 18:48     ` Hans Hagen via ntg-context
2021-10-19 20:10       ` Henning Hraban Ramm via ntg-context
2021-10-30 19:21         ` Henning Hraban Ramm via ntg-context
2021-11-01  5:45           ` Duncan Hothersall via ntg-context
2021-11-01  7:05           ` Floris van Manen via ntg-context
2021-11-01  7:58             ` Color profiles (was: Bloody PDF boxes) Henning Hraban Ramm via ntg-context
2021-11-01  8:07               ` Henning Hraban Ramm via ntg-context

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).