Re: [Printing-architecture] PDFio: Replaced QPDF by PDFio in libcupsfilters as GSoC project?

On 07/12/2023 21:17, Tobias Hoffmann wrote:
> AFAIR the hard thing was exactly this: To transform(move, rotate) the 
> annotations (just keeping them when no transformations are applied was 
> never the problem), as required esp. for n-up.
>

Yes, this is what I mean what has to be taken care off, independent of 
how many input pages are put on one output page.

> At the time, the "easiest" way – actually the only way I've seen it 
> implemented in other open source projects – was to first convert the 
> annotations into regular /Content commands (called "flatten" – 
> implemented by Jay in QPDF) that are then simply subject to all the 
> transformations applied there (which is not the case for /Annots, IIRC). 
> AFAIK this also the only way to "clip" annotations to only be drawn 
> inside a given area.
> 

Yes, for printing, where it does not matter whether the annotations are 
separately managed annotations or integral part of the graphical 
content, it simplifies a lot to flatten the annotations before doing any 
other operation, and so the risk to introduce bugs lowers a lot.

> But I would be delighted to see a different implementation.
> 

On the other side, keeping the annotations as such while doing the 
conversions makes the filter function more universal, and not only 
usable for printing.

> As a side note, when sufficiently complex transformations are required 
> (e.g. n-up), the current qpdf based pdftopdf implementation converts 
> pages to "Form XObjects", that could be draw just like Images onto new 
> pages. But these XObjects cannot have Annotations themselves, only the 
> Page where they would be drawn to has /Annots.
> 

And so probably flattening before the operation simplifies the work even 
more.

    Till