Routing by size not working on specific PDF

[DavidU54339-XRX]

The problem appears to be that FFCore is using the Media Box dimensions for the FFCore Crop Box variables $FFwfDoc.pdfCropWidth$  $FFwfDoc.pdfCropHeight$.

These are the values that FFCore has using its variables in mm :

Trim Box 230.00 317.00
Art Box 210.01 249.68
Bleed Box 230.00 317.00
Crop Box 235.05 322.05

Media Box 235.05 322.05

This is the content with the pdf in points:

<</ArtBox[35.5039 90.9259 630.784 798.69]/Contents 23 0 R/CropBox[7.15976 7.15714 659.128 905.74]/LastModified(D:20180601094944+01'00')/MediaBox[0.0 0.0 666.288 912.897]/Parent 14 0 R/PieceInfo<</Illustrator 51 0 R>>/

They do not agree.

I have written an AR. Feel free to author a SPAR.

[si]

Thanks David,

Ok, The media box is bigger than the crop box, as per the results from running a callas profile here (in points not mm), the issue being the crop is inset to the media box and I think the logic below for Selection behaviour in FFCore is having a bearing?

<page id="PAG1" nr="1" mediabox="0.0/0.0/666.288/912.897" cropbox="7.16/7.157/659.128/905.74" trimbox="7.16/7.157/659.128/905.74">

 If the selected PDF box is not defined in the PDF, the component falls back to using another PDF box per the following:

The Art Box falls back to the Trim Box.
The Trim Box falls back to the Bleed Box.
The Bleed Box falls back to the Crop Box.

The Crop Box falls back to the Media Box.

So that is why the route fails?

The behaviour above is relying on the crop box being set to zero?

Should I post this to support in the UK aswell would that help?

Thanks

Simon

[DavidU54339-XRX]

The two attachments are:

1.       Customer job

2.       Job processed with the FFCore 5.1.0.3 with FFCore variable values watermarked on – box sizes

When I view both jobs in Acrobat I get a Crop Box of 230mm by 317 mm.

FFCore is claiming (the watermarked values) the Crop Box is 235mm by 322mm.

I am mystified by the above and have asked development to look into the reason.

[si]

Ok Turns out only admin users can upload PDFs!

Anyway here is an update to where I am with this issue, which is now growing.

Problem 1

My initial idea/solution for the specific PDF which has a media box not equal to crop box was to do a check and on error, route that way. That would be fine however, some of the other PDFS I am testing do not have crop boxes. I am fast understanding that doing anything with crop boxes is a bad idea, the problem being that we have so many legacy PDFs that are malformed!

So...Screen shot here of the check I have made in FF.

This worked OK for the problematic PDF and I built this test workflow to fix the issues with the PDF.

The above is lacking adding the correct trims back in, which I THINK could possibly be done like so..

Generates a Trim and Bleed boxes based on the crop marks

Removes the old crop marks (they cause the box)

Fix the Media Box size (sets it to the Crop Box)

Set Media box to zero

Adds new crop marks based on the Trim and Bleed boxes

Problem 2:

But for a PDF that has NO Crop box, it also errors and goes down the route of being fixed, this is the resulting preflight parts that indicates there is no crop box:

<pages>
<page id="PAG1" nr="1" mediabox="0.0/0.0/907.087/1275.59">
<plates>4</plates>
<platenames>
<platename>Cyan</platename>
<platename>Magenta</platename>
<platename>Yellow</platename>
<platename>Black</platename>
</platenames>
</page>
</pages>

I will continue to work on this, but now looks like I will have to build a preflight check in Callas First.?....to see if there is a crop box and if there is NOT, route accordingly.

To put this into context here is a screen shot of the main workflow I am trying to work with and the problematic route highlighted...maybe I may need to re think the whole thing? I dont want to because as mentioned before I am transferring Process Manager to FFCore here and am dealing with legacy/old ideas and methods and old PDFs.

If anyone can assist or have any ideas on how best to deal with these I would be most grateful.

Thanks

Simon

[si]

So after trying EDGE, same result ...no file upload window available. I go back to chrome and lo and behold the file upload window appears, I chose a file from my desktop and then I get the above error, I have full access rights to the file this end. When logging back in and clicking reply, the File upload windows does not appear. This is flaky and is not browser specifc.

We are a Mac based company so unfortunately we do not run Windows10 Clients here as a default therefore Edge is not available to me in th normal run of things. I do have 1 x VM using it and have tested it and as mentioned the file upload does not appear.

Can we escalate this to Xerox? How do we push this to the forum sys admin team?

Thanks for your patience.

Simon

[DavidU54339-XRX]

I am able to use Edge to see/use the attachment field.

[si]

I have tried 3 different browsers, each one does not show that window. However when trying my second browser it did show and I chose a file, it then threw an error "Access denied/premission type error" I unfortunately did not get a screen shot.

Now whenever I hit reply I do not see the file upload section on any browser I have tried....Chrome, Safari, Firefox on MAC OSX. Very frustrating!

I thought it might be a browser issue but now think not?  I am not sure what to do next to be able to upload a file to this Post!

Thanks for your help

Simon

[si]

No i don't have that!!! Let me log out and back in, see if that works!!

[DavidU54339-XRX]

No problem. Here is a screen snap of what I see. The "attachments" at the bottom should be visible on your browser.

[si]

OK, forgive me, but I don't see an attachments field!!..only insert image or video?