Uploaded image for project: 'IGB'
  1. IGB
  2. IGBF-412

Revert SVG library back to Freehep

    Details

    • Type: Task
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      This story has been created to serve as a reminder to clean up the export image code in IGB because it is a real mess and bugs may be present.

      The linked story IGBF-381 shows one bug that should be cleaned up if possible.

        Attachments

        1. MacWindowTooSmall.png
          MacWindowTooSmall.png
          186 kB
        2. test.svg
          311 kB
        3. test2.svg
          77 kB

          Issue Links

            Activity

            Hide
            mason Mason Meyer (Inactive) added a comment - - edited

            Bugs/Usability Issues:

            1) A user cannot actually save an SVG or JPEG file through the native file chooser. What I mean is that if a user selects SVG or JPEG as their desired file type and then clicks "Save" from the "Save Image" dialog then their files gets saved as an SVG file or JPEG file (as expected). However, if a user selects SVG or JPEG and then chooses "Save As..." to browse for a location to save and then hits "Save" from the native file chooser the file actually gets saved as a PNG file. ****Upon further examination it seems that the native file chooser can save SVG/JPEG files but it doesn't always (maybe depends on file name...will look into further)
            -After looking into further it seems that the Mac does not really have this issue because it appends the file extension to the end of the file name in the native file chooser (Windows does not). If you delete the file extension though from something like "test.svg" to just "test" then even the Mac file chooser saves it as a PNG file, even though SVG or JPEG may be what was selected in the IGB "Save Image" dialog. (I think what is happening on Windows is that if a user types in the native file chooser to replace the name then the "hidden" file extension automatically gets replaced with ".png")

            2) Pressing "Cancel" or closing the File Chooser (after clicking on "Save As..." in the Save Image dialog box) closes the Save Image dialog box as well. This does not happen on the Live Version and this behavior may cause many users frustration.

            3) After saving a file, the input text for the file path and name should default to the last saved file path and name. This behavior would be much more useful to the user and this is the way it works on the Live Version.

            4) Not only should the last saved file path and name be remembered when opening the dialog, but IGB should also open up the dialog box containing the last saved unit (pixels or inches), the image size that was last saved, and the resolution and preview options (whole frame, main view, etc.) This allows for a user to quickly make a few minor adjustments to quickly replace their last saved image.

            5) When a user chooses "inches" as the unit from the drop-down menu they are able to input their desired size (in inches) into the text boxes. If they later change the resolution it alters the inch sizes they have set and this could be rather annoying. This is how it works on the Live Version, but really, changing the resolution SHOULD NOT change the inches of their image, but instead it should alter the pixel dimensions displayed to the left of "resolution" (this point only applies when "inches" is selected as the unit; see #4 below for a related issue).

            6) When a user chooses "pixels" as the unit from the drop-down menu they are able to input their desired size (in pixels) into the text boxes. If they later choose to change the resolution then the resolution changes but this should actually force either inches or pixels to change (because the number of pixels per inch defines the resolution). Since "pixel" has been selected as the unit type then I believe changing the resolution should force the size in inches to change (displayed to the left of "resolution"). This would be to the users benefit if they knew their desired image size in pixels and knew their desired resolution.

            7) A usability enhancement may be to make "inches" the default unit type when the "Save Image" dialog opens. My reasoning is that most users may be taking pictures in IGB for use in their publications and they will probably want to set the size of the pictures in inches before adjusting any other save image parameters.

            8) If a user opens the dialog box while on the main screen some issues with the dialog box may arise. For example, if they choose a genome with the dialog box still open and then click the "Update Preview Image" button the image preview changes but the selectable options do not (Main View and Main view with Labels remained greyed out). To fix this we could: 1- Force the Save Image window to refresh when selecting a genome or 2- disable the "Save Image" option if no genome has been selected (unless a user wants to take an image of the roulette screen)

            9) It seems that the window on Mac should have a minimum size because when opening the "Save Image" dialog for the first time (or after resetting preferences) the "Save Image" dialog is cutoff at the bottom (not all the preview options are visisble...see screenshot "MacWindowTooSmall".

            10) It also seems that the Whole Frame option is not selectable for SVG files (as expected) but you can still export SVG files with this option by selecting PNG or JPEG, then selecting Whole Frame, and then switching to SVG.

            Show
            mason Mason Meyer (Inactive) added a comment - - edited Bugs/Usability Issues: 1) A user cannot actually save an SVG or JPEG file through the native file chooser. What I mean is that if a user selects SVG or JPEG as their desired file type and then clicks "Save" from the "Save Image" dialog then their files gets saved as an SVG file or JPEG file (as expected). However, if a user selects SVG or JPEG and then chooses "Save As..." to browse for a location to save and then hits "Save" from the native file chooser the file actually gets saved as a PNG file. ****Upon further examination it seems that the native file chooser can save SVG/JPEG files but it doesn't always (maybe depends on file name...will look into further) -After looking into further it seems that the Mac does not really have this issue because it appends the file extension to the end of the file name in the native file chooser (Windows does not). If you delete the file extension though from something like "test.svg" to just "test" then even the Mac file chooser saves it as a PNG file, even though SVG or JPEG may be what was selected in the IGB "Save Image" dialog. (I think what is happening on Windows is that if a user types in the native file chooser to replace the name then the "hidden" file extension automatically gets replaced with ".png") 2) Pressing "Cancel" or closing the File Chooser (after clicking on "Save As..." in the Save Image dialog box) closes the Save Image dialog box as well. This does not happen on the Live Version and this behavior may cause many users frustration. 3) After saving a file, the input text for the file path and name should default to the last saved file path and name. This behavior would be much more useful to the user and this is the way it works on the Live Version. 4) Not only should the last saved file path and name be remembered when opening the dialog, but IGB should also open up the dialog box containing the last saved unit (pixels or inches), the image size that was last saved, and the resolution and preview options (whole frame, main view, etc.) This allows for a user to quickly make a few minor adjustments to quickly replace their last saved image. 5) When a user chooses "inches" as the unit from the drop-down menu they are able to input their desired size (in inches) into the text boxes. If they later change the resolution it alters the inch sizes they have set and this could be rather annoying. This is how it works on the Live Version, but really, changing the resolution SHOULD NOT change the inches of their image, but instead it should alter the pixel dimensions displayed to the left of "resolution" (this point only applies when "inches" is selected as the unit; see #4 below for a related issue). 6) When a user chooses "pixels" as the unit from the drop-down menu they are able to input their desired size (in pixels) into the text boxes. If they later choose to change the resolution then the resolution changes but this should actually force either inches or pixels to change (because the number of pixels per inch defines the resolution). Since "pixel" has been selected as the unit type then I believe changing the resolution should force the size in inches to change (displayed to the left of "resolution"). This would be to the users benefit if they knew their desired image size in pixels and knew their desired resolution. 7) A usability enhancement may be to make "inches" the default unit type when the "Save Image" dialog opens. My reasoning is that most users may be taking pictures in IGB for use in their publications and they will probably want to set the size of the pictures in inches before adjusting any other save image parameters. 8) If a user opens the dialog box while on the main screen some issues with the dialog box may arise. For example, if they choose a genome with the dialog box still open and then click the "Update Preview Image" button the image preview changes but the selectable options do not (Main View and Main view with Labels remained greyed out). To fix this we could: 1- Force the Save Image window to refresh when selecting a genome or 2- disable the "Save Image" option if no genome has been selected (unless a user wants to take an image of the roulette screen) 9) It seems that the window on Mac should have a minimum size because when opening the "Save Image" dialog for the first time (or after resetting preferences) the "Save Image" dialog is cutoff at the bottom (not all the preview options are visisble...see screenshot "MacWindowTooSmall". 10) It also seems that the Whole Frame option is not selectable for SVG files (as expected) but you can still export SVG files with this option by selecting PNG or JPEG, then selecting Whole Frame, and then switching to SVG.
            Hide
            mason Mason Meyer (Inactive) added a comment -

            After testing the new SVG library it seems that there are compatibility issues with IGB's SeqMap that were not present in the old SVG library (see attached SVG files).

            Observe that the "barbed wire" lines for introns no longer have the "barbed wire" look. Also Adobe Illustrator cannot open SVG files generated using the new SVG library. There is also some weird "transparency" issue with one of the gene models (it should look like the rest of the gene models in the image).

            My recommendation would be to revert to the SVG library that was used in the past because we did not seem to have the same problems listed in this comment.

            Show
            mason Mason Meyer (Inactive) added a comment - After testing the new SVG library it seems that there are compatibility issues with IGB's SeqMap that were not present in the old SVG library (see attached SVG files). Observe that the "barbed wire" lines for introns no longer have the "barbed wire" look. Also Adobe Illustrator cannot open SVG files generated using the new SVG library. There is also some weird "transparency" issue with one of the gene models (it should look like the rest of the gene models in the image). My recommendation would be to revert to the SVG library that was used in the past because we did not seem to have the same problems listed in this comment.
            Hide
            mason Mason Meyer (Inactive) added a comment -

            The SVG library has been reverted back to Freehep. There were already known issues with the Freehep SVG library which is why we tried to use a newer SVG library. Unfortunately, the newer SVG library has more problems so we decided to revert back to Freehep.

            There are still some SVG problems which we may be able to fix for the major release of 8.4.0, but these problems will be tracked in new JIRA stories.

            Since this issue is resolved it will now be closed.

            Show
            mason Mason Meyer (Inactive) added a comment - The SVG library has been reverted back to Freehep. There were already known issues with the Freehep SVG library which is why we tried to use a newer SVG library. Unfortunately, the newer SVG library has more problems so we decided to revert back to Freehep. There are still some SVG problems which we may be able to fix for the major release of 8.4.0, but these problems will be tracked in new JIRA stories. Since this issue is resolved it will now be closed.

              People

              • Assignee:
                mason Mason Meyer (Inactive)
                Reporter:
                mason Mason Meyer (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: