Issue with Sierra and printing from PDFView

MichaelBothMichaelBoth AUMember ✭✭✭

I have a Mac Classic application that has been running in the field for well over a year now without issues, however recently some users have upgraded to OSX Sierra and have reported a problem. I utilise a PDFView component to preview the results of some reports (which are generated in HTML, and then converted to a PDF file using WKHTMLTOPDF), and users can then either print or export to PDF; the problem is that on Sierra the printed or PDF-exported results are shrunken on the page and only the first page of results are printed / exported. For this process I simply call "ThePDFView.Print(usePDFPrintInfo)".

This approach has worked fine on previous OSX versions, so I am unsure if this is a Sierra issue - as it seems odd to me that a well-formed and correctly-appearing PDF file can somehow be mangled in such a way - or if it is an issue with Xamarin for Mac that has been solved in recent months (as the version 'in the field' has been compiled with a version of Xamarin for Mac that is at least a year old).

So.... has anyone experienced this? Is this something that could well be simply addressed by converting my application to the Unified API and compiling with the most recent Xamarin for Mac / Mono / Xamarin Studio? I would really love to hear, especially, if someone can reproduce this issue on a simple Xamarin Mac app on Sierra to see if it's a general problem.

Posts

  • ChrisHamonsChrisHamons USForum Administrator, Xamarin Team Xamurai

    That is rather strange.

    It seems unlikely that XM has anything to do with it. It is possible, but a majority of the time issues at my layer end up in crashes / exceptions / etc, not wrong behavior.

    To be honest, Apple does not have a high testing level for 32-bit APIs anymore. I've seen them break API compatibility on multiple APIs, including one time they literally removed 32-bit compatibility for any entire "Kit". The radar was closed with roughly "yep we did that, but we don't know anyone big using the 32-bit version."

    They really want you to move to 64-bit. And to be honest, I'd really like you to consider moving to Unified if you plan on doing future development on your program. Unified has gotten so much more love and attention the last few years, from better bindings and a better build system, to more testing and QA.

  • MichaelBothMichaelBoth AUMember ✭✭✭

    @ChrisHamons said:
    That is rather strange.

    It seems unlikely that XM has anything to do with it. It is possible, but a majority of the time issues at my layer end up in crashes / exceptions / etc, not wrong behavior.

    Thanks for the reply, Chris; this was exactly my thought as well.

    They really want you to move to 64-bit. And to be honest, I'd really like you to consider moving to Unified if you plan on doing future development on your program. Unified has gotten so much more love and attention the last few years, from better bindings and a better build system, to more testing and QA.

    Certainly future development is required. I guess it's time to bite the Unified bullet, and see if this fixes things. :) I'll change the app over to Unified and will report back.

    BTW it's great to see you are still here supporting users - your earlier replies made a huge difference when I was developing this app in the first place.

  • MichaelBothMichaelBoth AUMember ✭✭✭

    I've updated our application to the Unified API, and the exact same problem still occurs. Using the same PDF file we are previewing (and that doesn't print properly from within our Xamarin Mac application), and using the Sierra "Preview" then "Print" option, everything works fine (i.e. all pages of the PDF are shown in the preview and the contents are of the correct size).

    I'll put together a new Unified Xamarin Mac app with a PDF view and print functionality to try and create a basic reproducible case.

  • MichaelBothMichaelBoth AUMember ✭✭✭

    I discovered what the problem was. Previously I was calling print for my PDFView like so:
    NSPrintInfo thePDFPrintInfo = NSPrintInfo.SharedPrintInfo; ThePDFView.Print(thePDFPrintInfo);
    ... and this worked fine up until Sierra, at which point this call was failing in the way I've previously described. However, changing the call to:
    NSPrintInfo thePDFPrintInfo = NSPrintInfo.SharedPrintInfo; ThePDFView.Print(thePDFPrintInfo, true);
    ... fixes the problem I was experiencing, i.e. the second parameter related to whether rotation is required or not seems to now be necessary for correct functioning (?). Perhaps I was getting away with the previous single-parameter call in some way? Anyway, all good now! :)

Sign In or Register to comment.