Opened 8 years ago

Closed 6 years ago

#818 closed defect (wontfix)

“report button” followed by “save” makes an empty pdf file???

Reported by: richardh Owned by: wojciech
Priority: trivial Milestone: SasView 4.2.0
Component: SasView Keywords:
Cc: Work Package: SasView Bug Fixing


Discovered that on my windows 7, 32 bit, build “report button” followed by “save” currently makes an empty pdf file, though “print” seems to work.

Will someone else please check.


Change History (16)

comment:1 Changed 7 years ago by butler


  • ESS Build 631, from commit ef0e644c356799b2007f2020e3594f5c19111961
    • Windows 10 laptop (development machine)
    • Old old machine but running windows 10 desktop (no opencl)
  • source code in development from latest commits (should be same as build 631)

All create proper PDF. Will have to use one of the machines at NIST to test Windows 7

HOWEVER — there is an error when launching the report (hitting the report button) which is only reported in the log files. I get a series of the same error (presumably one for each name:value pair)

2017-01-22 17:08:32,280 ERROR Report string expected 'name: value' but got u''

Suspect this is actually the root of the problem

comment:2 Changed 7 years ago by butler

Double checked on Windows 7enterprise (office computer) using ESS windows 7 build 632 (which only includes a change to the version number) The behavior is exactly the same as above (both that it produces a proper PDF and throws the string error in the logs).

Since this seems to work would tend to believe this can be moved to 4.2?

comment:3 Changed 7 years ago by richardh

I just pulled master to my pc (Windows 7) and did usual 32 bit build. (Did I need to download a specific buid frim server?)
Still only a zero length pdf file on "save" in report.

sasview.log has lots of:

2017-01-25 17:21:48,032 ERROR Report string expected 'name: value' but got u
2017-01-25 17:21:48,032 ERROR Report string expected 'name: value' but got u

2017-01-25 17:21:48,032 ERROR Report string expected 'name: value' but got u
2017-01-25 17:21:48,032 ERROR Report string expected 'name: value' but got u

2017-01-25 17:21:48,032 ERROR Report string expected 'name: value' but got u
2017-01-25 17:21:48,032 ERROR Report string expected 'name: value' but got u

2017-01-25 17:22:17,654 ERROR Error creating pdf: No module named xhtml2pdf

comment:4 Changed 7 years ago by butler

  • Milestone changed from SasView 4.1.0 to SasView 4.2.0
  • Priority changed from minor to trivial

The last line is the problem and indicates that you have not installed xhtml2pdf on your computer. This is listed as one of the required packages. You can run to see if your system has all the required packages and if not what is missing and needs to be downloaded and installed. This is therefore not a SasView problem per se, though it may be a problem with the build system instructions or anaconda packages? The missing string error however would be nice to fix though apparently is not causing any obvious issues. So will move this to 4.2 for now… and could be kicked further if necessary.

comment:5 Changed 7 years ago by richardh

Indeed, was missing xhtml2pdf, have added this to the anaconda instructions for Win32 developer build on the wiki. This sorted my line mode build but not Steve's Eclipse build.

comment:6 Changed 7 years ago by krzywon

  • Owner changed from butler to krzywon
  • Status changed from new to assigned

The errors in the log file are from blank lines in the string that gets passed to the report dialog. The errors are generated when the report window is first opened, not when saving the data. A check for empty strings and skipping them should be a straight forward and easy fix for this.

Outside the log errors, are there any other issues for this? I am aware of #884, but that seems to be a different issue altogether.

comment:7 Changed 7 years ago by krzywon

Lionel is having this same issue right now running on OS X El Capitan, running release v4.1 (not source).

He has this error in his sasview.log:
ERROR Error creating PDF: tobytes

I compared the console output for the build servers between the windows7 and OSX builds and there are four packages only bundled with Window.
byte-compiling c:\python27\lib\site-packages\xhtml2pdf\ to xhtml2pdf\paragraph.pyc
byte-compiling c:\python27\lib\site-packages\xhtml2pdf\ to xhtml2pdf\paragraph2.pyc
byte-compiling c:\python27\lib\site-packages\xhtml2pdf\ to xhtml2pdf\pdf.pyc
byte-compiling c:\python27\lib\site-packages\xhtml2pdf\ to xhtml2pdf\turbogears.pyc

comment:8 Changed 7 years ago by butler

Has been resolved on PC in version 4.1.2, but still an issue on the mac — looks like a server issue as it works locally on Wojciech's machine.

comment:9 Changed 7 years ago by smk78

See #984

comment:10 Changed 6 years ago by butler

  • Owner changed from krzywon to wojciech

Wojcieck to check … if still a problme move to 4.3

comment:11 Changed 6 years ago by smk78

Just tested this on a local build on Win7 pulled from Master this morning. Still builds the report pdf fine. But someone needs to check on a Mac.

comment:12 Changed 6 years ago by wojciech

Still doesn't work from installer but works from local build. Will look into it.

comment:13 Changed 6 years ago by wojciech

It is really nasty bug and almost impossible to debug. It works on VM that we host OSX build but it doesn't work from installer. There is a problem creating pdf with images (pure text works) and most likely it is due to PIL.

This will most likely work with anaconda python and/or python3 (there are simillar issues people been reporting).

comment:14 Changed 6 years ago by butler

Was about to move to 5.0 as a GUI problem that will go away — but just noticed your comment that it will probably work with anaconda python. I thought the build servers were now running anaconda python plus the yaml file to ensure they are using the exact same environment everybody has if they follow our simple instructions? Is this not the case? and if not should we be doing that? and if we are going to do will it fix the problem do we think? If not probably best to move to 5.0 though all mac users will be very annoyed at us I'm sure.

comment:15 Changed 6 years ago by wojciech

Mac build server currently uses native python as we had a problem with final packaging (py2app and pyinstaller issues). These issues have to large extent been overcome but we are not fully anaconda ready yet. Would anaconda based installer happen before 5.0 - hard to say.

comment:16 Changed 6 years ago by butler

  • Resolution set to wontfix
  • Status changed from assigned to closed

Between moving away from wx, moving to python 3, and rebuilding the GUI from scratch this should go away in 5.0. For now Mac users can save to PDF from the print menu so not really worth a ton of effort to fix now. The only issue is reputational for mac users who click save only to find out later they lost all their work cause it did not save.

As per Tuesday meeting this ticket is thus closed and a new ticket to remove the save button from the mac version created.

Note: See TracTickets for help on using tickets.