In AFP the Y coordinate system is top left down, not bottom left up. This gives a problem when trying to convert customers existing workflow. Take the following example to demonstrate issue (not the actual customer workflow). Customer prints 3 different portrait jobs on US Letter but the jobs he prints could be 8 inch tall, 9 inch tall and 10 inch tall. With AFP, the page is aligned top left and therefore the extra blank of 3, 2 and 1 inch is at the bottom, which is trimmed off later. With JDF and similar PDF data, the blank would be at the top (as they are aligned bottom left). To make matter worse, some days the same job is printed on another paper size, say 8.5 x 12, again, the 4, 3 and 2 inch blank is at the bottom, and other days on any unknown paper size.
How could I change the anchor point in JDF to top left so that an AFP workflow can be converted without expecting the customer to operationally change or know the paper / pdf size ahead of JDF preparation?
Is this a limitation in JDF or ...?
You may know to use many converting software from AFP to PDF.
Therefore we don't need JDF's support for this issue.
Why do you ask this.
I can't understand this problem.
customers have existing (pure) AFP workflows and want to migrate to (pure) PDF workflows (not PDF in AFP object containers). Its easy for them to generate the same page in PDF that was generated in AFP with software. So lets take the example of the placement of a 4 inch high page with AFP on 8.5 inch high paper. The coordinate 0,0 starts top left and comes down 4 inches. Now the equivalent PDF page, the coordinate 0,0 is bottom left and the page goes up 4 inches. Obviously the two outputs look different. So now think of a data stream, where every page of PDF could be a different height, 4 inch, 5 inch, 3 inch etc; because of a different coordinate system, it is not possible to make a <Layout> with @automated="true" to achieve the same, without the suggested multiple rotation trick, but this isn't how an architected solution should be. There should be the ability to switch the coordinate system, or a way of top aligning the output page to be able to ease migration from other systems.
how would I progress this to be an enhancement request?
How do I progress this into an enhancement request???
How do I turn this into a request for JDF functionality? Its a sever limitation not to be able to use top left x/y across/down or "align PDF page to top left" if we expect people to migrate from major alternatives such as AFP. Dont PDF users also want to be able to have one JDF for variable length PDF's and desire the blank for at the page bottom for easy trimming ?
I really appreciate the suggestion which as you say, should theoretically work. However, don't you believe this is a limitation of JDF that should be addressed, after all migration of AFP to JDF is a large target market and the average user will struggle to build JDF scripts that have so may factors to consider. In JDF, FitPolicy is used to say a PDF can be scaled/clipped/tiled to fit a media, wouldn't a sensible extension be the ability to align to top left the presentation space to the media?
This is a bit sticky, since it touches my favourite topic: coordinate systems.
Unfortunately, there is no really simple answer and the following solution should theoretically solve your problem, but only if all coordinate system rotations are fully implemented by the receiving device, which is not guaranteed.
in essence you have to rotate twice: Rotate the layout of the printed sheet by 180° and then rotate the output component by another 180 degrees.
With LayoutPreparation, you'd add a PageCell/@Rotate="180" to put the pages onto the surface in heads down.
Then ComponentLink/@Orientation="Rotate180" will rotate the page so that the bottom of the sheet (with the head side of the pages) is rotated so that it is now the top, which aligns with the head of the pages.
Stripping and Layout allow similar placement of the pages.
Powered by a free Atlassian Confluence Open Source Project License granted to CIP4. Evaluate Confluence today.