Spam:****, Re: Reports, probably again

[JWatYahooGroups]

Being a newbie (to gnucash, not programming) I agree that including the 
formatting in exported reports makes things difficult.

CSV is certainly a simple format, easily imported into spreadsheets, for 
those who wish to do so for further fiddling.

Another alternative: output in XML, so that context (headings and such) can 
be identified. Many XML tools exist for further parsing and processing, and 
XSLT can directly produce reports from the XML, for those with the 
programming skill or recurring production needs.

JimW




>Your comments are in one sense absolutely spot on, and yet in another 
>completely miss the point.
>
>On the one hand, gnucash has a "pretty-print" format which is more or less 
>OK for on-screen viewing by the operator, but in no sense suitable (as you 
>suggest) for distribution to the Board.  This is fine, and - so far as it 
>goes - not a problem.
>
>However, when it comes to exporting the reports, all that pretty-print 
>layout is actually exported along with the data (the format is, after all, 
>HTML - presumably the same HTML used to pretty-print the screen!) which 
>actively impedes attempts to process and lay-out the data in a finished 
>form, and must be identified and discarded before serious work can 
>begin.  Worse, since gnucash 2.3 at least the formatting information 
>exported has actually destroyed columnar information, and so the task of 
>the user wishing to layout reports properly is greatly - and entirely 
>unnecessarily - increased.
>
>The ideal format for report exports would be CSV, which contains *only* 
>the data and columnar information, with no formating information to be 
>discarded before processing, and leaves the user free to use his tools of 
>choice to process and lay-out his reports with the minimum of 
>effort.  Exporting as HTLM leaves the user with neither a properly 
>formatted report nor clean data for him to format for himself.  It is this 
>one aspect that is unsatisfactory.
>
>An alternative might be to provide an interface that is realistically 
>usable by one of the many freeware or commercial report-writer 
>applications around, but given the extraordinarily complex schema for 
>Gnucash data, and the correspondingly complex and obscure SQL needed to 
>extract relevant information, it seems unlikely that this could be a 
>realistic or practical proposition without a great deal of preparatory 
>work in preparing views suitable for the purpose.
>
>
>Please remember to CC this list on all your replies.
>You can do this by using Reply-To-List or Reply-All.