Pitstop Server skipping pages on XML Report?

[Soul Forge]

So, I've built this flow for one of my clients that takes many information generated by Pitstop Server checks, then it sends e-mails with the treated information.

But they noticed that some pages were missing in the reports my flow sent.

After performing multiple tests I've noticed that some pages are missing in the Ink Info report. What could be the cause of it?

[loicaigon]

Hi,

Can you address this to support?

Loic

[Soul Forge]

Hi,

Can you address this to support?

Loic

E-mail sent!

Thank you.

[JimmyHartington]

I just got to ask the simple question.
Could it be blank pages?

If yes, I would of course still have them reported in the XML with zero as value.

[tdeschampsBluewest]

Could it be the label of the page in the report instead of the page number?
Do you have a missing ones in your label names?

[Soul Forge]

I just got to ask the simple question.
Could it be blank pages?

If yes, I would of course still have them reported in the XML with zero as value.

Unfortunately it's not. Nevertheless even if it was it should report 0 ink usage, as it could be useful for decision making.

Could it be the label of the page in the report instead of the page number?
Do you have a missing ones in your label names?

I actually don't know what you mean by page label.

The page number 56 actually has 80 something percent of black ink usage. The flow should report just that, when a page uses ink above a certain percentage.

Using pitstop pro, the pdf report is working fine.

[JimmyHartington]

Not to say anything isn’t wrong with Pitstop Server.

But if you are running it through Switch, what have you set as the limit in the configurator?

[Soul Forge]

Not to say anything isn’t wrong with Pitstop Server.

But if you are running it through Switch, what have you set as the limit in the configurator?

Well, the default number is 100, but when I looked at it before I created this post it was 1000. Then, also before I posted, I tried changing it to 50.000.
Nothing worked.

Even if it was a problem with this limit, I guess the intended behaviour would be to truncate the last lines, not some in the middle, right?

[JimmyHartington]

Even if it was a problem with this limit, I guess the intended behaviour would be to truncate the last lines, not some in the middle, right?

You are right. It should truncate from the end.
I think you have now exclude the obvious possiblities for user error.
So lets here what Loïc and the support finds out.

[tdeschampsBluewest]

[/quote]
I actually don't know what you mean by page label.
[/quote]

Page number can differ from page label.
The index, is the position as an integer, the label is a string,
In most case, page label = page index, but in some case if you added label to your pages, and remove some pages, the labels can mismatch the index.

[Soul Forge]

In most case, page label = page index, but in some case if you added label to your pages, and remove some pages, the labels can mismatch the index.

Oh! I've seen a couple files with this problem before, some even using roman numerals, for whatever reason.
Unfortunately it's not the case for this file.

[loicaigon]

Hi all,

We identified a bug in the XML V3 report that doesn't translate information as it should. First, it's important to understand that in the PDF report, pages having a same amount of Ink coverage get gathered ( Page 2, 6, 15…). Here the xml report applies the same logic but doesn't report properly.

This is logged and will be fixed. The workaround right now is to choose XML v2 reports.

Loic

[Soul Forge]

Hi all,

We identified a bug in the XML V3 report that doesn't translate information as it should. First, it's important to understand that in the PDF report, pages having a same amount of Ink coverage get gathered ( Page 2, 6, 15…). Here the xml report applies the same logic but doesn't report properly.

This is logged and will be fixed. The workaround right now is to choose XML v2 reports.

Loic

Thanks for the workaround, I'll apply it in the flow!