Spread Designer xml saved size verus FpSpread output

Posted by: greygranite on 8 September 2017, 4:35 am EST

  • Posted 8 September 2017, 4:35 am EST

    Hello,


    When performing final testing on our implementation of the Farpoint Spreadsheet in our project, we noticed a size difference between the xml files from Spread Designer and the FpSpread component's output.  We were surprised to see that the output from FpSpread was larger even when no changes were made to the sheet.  Running comparsions between the xml files with WinDiff showed that the FpSpread xml file would have four items added to the NamedStyles section.  In the output from Spread Designer, there was not any data in that section.


    Version
       Farpoint.Win.Spread  4.0.2005.2005


    Named Styles Added:
       ColumnHeaderEnhanced
       RowHeaderEnhanced
       CornerEnhanced
       DefaultDataArea


    Examples
       - Blank sheet of 27 cols, 80 rows is 37 kb in Spread Designer but grows to 46 kb after being saved from FpSpread through an xml document.


       - A tax form of 27 cols, 80 rows is 577 kb but then grows to 588 kb.


     


    The size in kb is very small, but as a percentage on the file size it can be significant on smaller files.  Out client was concerned about the file size difference.


    Is this size difference by design?  It looks like the default named styles are being saved from FpSpread but not from Spread Designer.  Should we expect the size to generally be different between the two?


    Thank you,


    Ed Ostrowski

  • Replied 8 September 2017, 4:35 am EST

    I did a small test with your specifications and the designer file was actually larger(22.3k as compared to 22.1 in spread).  These differences are certainly negligible but I have no explanation as to the size difference.  Comparing the files line-by-line they are identical.
  • Replied 8 September 2017, 4:35 am EST

    Ed,


    The Spread Designer has these NamedStyles built in and are not exposed through the Designer. Thus, when the XML is generated, these classes are not defined.

  • Replied 8 September 2017, 4:35 am EST

    Thanks for the info guys.  This helped us come up with a solution to save the xml more efficiently.


     When saving before, we would read the FpSpread xml into an xml document because we needed to in certain instances to append additional state information to the output xml.  We would then use the xmlDocument.Save to write to either disk or stream.  By changing this to use an xml writer with formatting set to none, we removed all of the padding spaces and carriage returns from the output.  This saved a significant amount of size and usually resulted in the FpSpread output being smaller then the Spread Designer output.


    Thanks,


    Ed Ostrowski

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels