(logocert_api) testLocalPrintLayout expects a different output for the file sent

[dansinadjan]

I am now failing on testLocalPrintLayout which I am previously passing in the version 1 of the tool.

I noticed that the test sends the same image/pwg-raster file twice with these parameters respectively: "page_orientation": {"type": "PORTRAIT"}; and "page_orientation": {"type": "LANDSCAPE"}.

I'm now getting two portrait printouts, which made me wonder why I passed the test on the previous version. So what I did is that I sniffed out the data while printing from the Chrome browser and manually selecting LANDSCAPE.

This is the image that is sent to the printer:

The image is already sent in landscape format.

I've checked with our engineers and confirmed that we don't handle the page orientation in the job ticket because Chrome is already handling the orientation. Receiving an already landscaped page and getting it to rotate to landscape will result in a portrait image. This is why we are passing in the previous version of the tool because we don't do anything with the orientation in the ticket.

I don't think we need to run this test (in Local Printing) if the Chrome browser already takes care of the orientation but let me know if I'm wrong.

Thanks.

[chok]

Hi,

Thanks for the detailed write up of the issue. You are correct, in the case of a printer that only supports the PWGRaster format for local printing, it is not the printer's responsibility to handle the orientation; Chrome does the image transformation and sends the Raster file to the printer directly.

This issue has been resolved already in a commit on March 23rd: 8318cc4

For Local printing with PWGRaster as input, only 2 CJT options are tested now:

• Color
• Duplex

As for Local printing with PDF as input, all 6 of the CJT options are tested:

• Color
• Duplex
• Margins
• Layout
• Page Range
• Copies

Since this branch is still in development, please pull from it often to keep it up-to-date. There has been other changes since March 23rd; however, they are mostly small fixes and improvements. One noteworthy change that may apply to you is that a new test has been added to the Cloud Printing suite, testPrintMarginsOptions.

Please let me know if the issue has been resolved after updating the tool. Thanks for bearing with us and providing feedback while we finalize on the tool, we are getting close!

Thanks,
Kevin

[dansinadjan]

Hi Kevin, You may also want to look at the LocalPrintPDFPageRange test. From what I'm seeing, printing from Chrome and from the Management Page will give me a file that has already been selected according to the page range applied (e.g. I'm receiving pages 2 and 3 only and not pages 1-3). Is there another interface that you could print from that sends you the whole file plus the page range only? Because it may be that this test is unnecessary to perform if Chrome/Management Page has already handled it. Thanks. P.S. Many thanks to your details replies as well. ;)

…

On Tue, Apr 4, 2017 at 2:33 AM, chok ***@***.***> wrote: Hi, Thanks for the detailed write up of the issue. You are correct, in the case of a printer that only supports the PWGRaster format for local printing, it is not the printer's responsibility to handle the orientation; Chrome does the image transformation and sends the Raster file to the printer directly. This issue has been resolved already in a commit on March 23rd: 8318cc4 <8318cc4> For Local printing with PWGRaster as input, only 2 CJT options are tested now: - Color - Duplex As for Local printing with PDF as input, all 6 of the CJT options are tested: - Color - Duplex - Margins - Layout - Page Range - Copies Since this branch is still in development, please pull from it often to keep it up-to-date. There has been other changes since March 23rd; however, they are mostly small fixes and improvements. One noteworthy change that may apply to you is that a new test has been added to the Cloud Printing suite, testPrintMarginsOptions. Please let me know if the issue has been resolved after updating the tool. Thanks for bearing with us and providing feedback while we finalize on the tool, we are getting close! Thanks, Kevin — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#107 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZFF71UxEmED_HTNXeOdBeYSWu2sEXzGks5rsTtsgaJpZM4MxQDV> .

-- Thanks and best regards, *Dan Michael L. Sinadjan*

[chok]

The driving force behind Logocert 2.0 is to replace all Chrome interactions with API calls; therefore, there is no longer any automated tests that print via the Chrome dialog or Mgmt Page.

The interfaces for GCP printing are:

1. Cloud Print - Submit (GCP API)
2. Local Print - CreateJob & SubmitDoc (Privet API)

Since the goal of this tool is to certify a printer, there are no differences in starting a print job via Chrome or Mgmt page since they call the same underlying APIs anyway. We understand that this is the most common use case for GCP printing and so we still have manual tests to verify Chrome-related print jobs.

For LocalPrintPDFPageRange, we want to test the printer's ability to handle the page range specification in the CJT sent via SubmitDoc instead of Chrome's ability to truncate the document before sending it to the printer.

Hopefully that helps!

Cheers,
Kevin

[dansinadjan]

Okay, got it Kevin. Thanks! Will give you updates once I get a chance to take a look at the other tests.

…

On Fri, Apr 7, 2017 at 2:21 AM, chok ***@***.***> wrote: The driving force behind Logocert 2.0 is to replace all Chrome interactions with API calls; therefore, there is no longer any automated tests that print via the Chrome dialog or Mgmt Page. The interfaces for GCP printing are: 1. Cloud Print - Submit (GCP API) 2. Local Print - CreateJob & SubmitDoc (Privet API) Since the goal of this tool is to certify a printer, there are no differences in starting a print job via Chrome or Mgmt page since they call the same underlying APIs anyway. We understand that this is the most common use case for GCP printing and so we still have manual tests to verify Chrome-related print jobs. For LocalPrintPDFPageRange, we want to test the printer's ability to handle the page range specification in the CJT sent via SubmitDoc instead of Chrome's ability to truncate the document before sending it to the printer. Hopefully that helps! Cheers, Kevin — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#107 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZFF75mext1E-gv9tmimATDbNZ9BJUTZks5rtS03gaJpZM4MxQDV> .

-- Thanks and best regards, *Dan Michael L. Sinadjan*

[dansinadjan]

Hi Kevin, I'm looking at test_11_LocalPrintPDFLayout and I'm running into some layout issues. On the previous tool, the Chrome browser layouts the PDF already into Portrait/Landscape so the way we handled this is that when the file is a PDF, we directly print the file and we get the expected output. Now, the new tool sends the same file in portrait and sends the corresponding orientation in the ticket. We are now failing this test since we will always print in Portrait (the original layout of the file.) If we acknowledge the orientation in the ticket, then we will not be able to correctly handle the jobs sent from Chrome since, for example, Chrome sends an already Landscape job and also sends the Landscape orientation, we will end up printing a Portrait page (since you are rotating an already landscape page). While I understand that the new version of the tool aims to go away from using Chrome to certify, we seem to be running a little problem in this case. Also, printing a PDF file through Chrome, I don't see an option to change the orientation. From the user's perspective, this option isn't even available for PDFs. In this case, this seems to me another unnecessary test for LocalPrinting. Please help me understand if otherwise. Thanks. On Fri, Apr 7, 2017 at 10:48 AM, Dan Michael Sinadjan <[e-mail]

…

wrote: Okay, got it Kevin. Thanks! Will give you updates once I get a chance to take a look at the other tests. On Fri, Apr 7, 2017 at 2:21 AM, chok ***@***.***> wrote: > The driving force behind Logocert 2.0 is to replace all Chrome > interactions with API calls; therefore, there is no longer any automated > tests that print via the Chrome dialog or Mgmt Page. > > The interfaces for GCP printing are: > > 1. Cloud Print - Submit (GCP API) > 2. Local Print - CreateJob & SubmitDoc (Privet API) > > Since the goal of this tool is to certify a printer, there are no > differences in starting a print job via Chrome or Mgmt page since they call > the same underlying APIs anyway. We understand that this is the most common > use case for GCP printing and so we still have manual tests to verify > Chrome-related print jobs. > > For LocalPrintPDFPageRange, we want to test the printer's ability to > handle the page range specification in the CJT sent via SubmitDoc instead > of Chrome's ability to truncate the document before sending it to the > printer. > > Hopefully that helps! > > Cheers, > Kevin > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#107 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AZFF75mext1E-gv9tmimATDbNZ9BJUTZks5rtS03gaJpZM4MxQDV> > . > -- Thanks and best regards, *Dan Michael L. Sinadjan*

-- Thanks and best regards, *Dan Michael L. Sinadjan*

[chok]

Hi Dan,

The printer's Local Printing Privet API needs to work with Chrome, GCP Servers, and any other applications that may interact with it. Therefore, this test is necessary for the certification of a printer.

Regarding local printing a PDF file via the Chrome browser, indeed there is no orientation option to specify, but the user may right-click and rotate the image in the print dialogue view. Either way, Chrome just uses 'AUTO' as the orientation option in the CJT. In this case, the printer does not have to handle the transformation and just uses the default orientation option to print the job.

Since you cannot specify orientation from Chrome's local printing, I'm assuming you are referring to Cloud Print which is sending an already transformed image with the Landscape option in the CJT. In the case of Cloud Printing, similar logic as local printing is applied, the image is transformed at the server but the orientation option in the CJT should be 'PORTRAIT'. It is strange that your printer is getting 'LANDSCAPE' in the CJT.

Please verify this by kicking off a job with the landscape orientation set. Then you can inspect the CJT that is sent by the GCP servers using the Job Fetch API on https://www.google.com/cloudprint/simulate.html. Just fill in the 'Job ID' field, check the 'Use CJT' box, and click 'Get Print Ticket'.

In the resulting page, the CJT will be shown. The 'page_orientation' field should be 'PORTRAIT' regardless of the orientation specification you've specified earlier. Please let me know if this is not that case for you.

Cheers,
Kevin

[dansinadjan]

Hello Kevin, Thanks for the clarifications on how Chrome handles the orientation in printing and also on why this test is necessary. One more question though. Since the API allows you to send an orientation that may not coincide with the original orientation set on the PDF file, how would the printouts look like? For example, I have a PDF that is originally in portrait, will I expect the output to be this way if I send it over the API with PORTRAIT/LANDSCAPE as layout?  In the similar way, do I expect the following output if my file is originally landscaped?  Are my assumptions correct? Thanks.

…

On Sat, Apr 8, 2017 at 4:29 AM, chok ***@***.***> wrote: Hi Dan, The printer's Local Printing Privet API needs to work with Chrome, GCP Servers, and any other applications that may interact with it. Therefore, this test is necessary for the certification of a printer. Regarding local printing a PDF file via the Chrome browser, indeed there is no orientation option to specify, but the user may right-click and rotate the image in the print dialogue view. Either way, Chrome just uses 'AUTO' as the orientation option in the CJT. In this case, the printer does not have to handle the transformation and just uses the default orientation option to print the job. Since you cannot specify orientation from Chrome's local printing, I'm assuming you are referring to Cloud Print which is sending an already transformed image with the Landscape option in the CJT. In the case of Cloud Printing, similar logic as local printing is applied, the image is transformed at the server but the orientation option in the CJT should be 'PORTRAIT'. It is strange that your printer is getting 'LANDSCAPE' in the CJT. Please verify this by kicking off a job with the landscape orientation set. Then you can inspect the CJT that is sent by the GCP servers using the Job Fetch API on https://www.google.com/cloudprint/simulate.html. Just fill in the 'Job ID' field, check the 'Use CJT' box, and click 'Get Print Ticket'. [image: image] <https://cloud.githubusercontent.com/assets/23246871/24818223/6447b2c2-1b94-11e7-8324-0d45f1e2f384.png> In the resulting page, the CJT will be shown. The 'page_orientation' field should be 'PORTRAIT' regardless of the orientation specification you've specified earlier. Please let me know if this is not that case for you. Cheers, Kevin — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#107 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZFF73scSsAeSvFtwAUTFr89RDBO0W20ks5rtpyfgaJpZM4MxQDV> .

-- Thanks and best regards, *Dan Michael L. Sinadjan*

[chok]

Hi Dan,

The general idea is correct.

As for whether or not the 'flipped' image should be centered, I would just kick off Cloud Print jobs with the same image but with different orientations and see how the GCP server handles it.

In my experience, I have seen the 'flipped' images printed near the top of the page instead of in the center.

Thanks,
Kevin

[dansinadjan]

Since all clarifications had been addressed, I'll close this issue. Thanks for the accommodation, Kevin.