Re: [lmi] calculation summary, questions about xslt

[Greg Chicares]

On 2006-10-10 0:23 UTC, Evgeniy Tarassov wrote:
> 
> This is a compiled list of questions about xslt resources for
> calculation summary part of lmi. The most important if the first one.
> The rest is just some small or not so big issues.

Let me reply to that most important question first.

> 0) clipboard data

I believe this is intended to address the following "user story":

  https://savannah.nongnu.org/support/?105592
  "Copy and paste calculation summary"

Let me expand upon that, to make sure we understand it the same
way. Users often need to change input data manually in order to
produce the results they want (some iterations are too complex
to automate). Usually, what they see on the calculation summary
is enough to guide them to the next iteration: for instance,
they might change "premiums" until they get a desired pattern of
"loans", and "loans" can be shown directly on the summary.

But sometimes that's not enough. For example, they might want to
change some input fees in order to get a desired internal rate
of return (IRR). That IRR might be unavailable on the summary,
but easily derived from data that is on the summary. In that
case, they'd want to copy and paste the data to a spreadsheet
that can calculate IRR.

Or they might have a competitor's numbers in a spreadsheet
already, and want to paste ours next to them for comparison.

For those purposes, they need only the data, and formatting
doesn't matter.

I suppose it would be technically possible to copy elaborately-
formatted data to the clipboard so that it would have the same
appearance when pasted into a spreadsheet as it does on the
screen. That's not a requirement, and probably wouldn't even be
very useful. What they really need is just the raw data.

> currently we are going to put tab delimited data into clipboard. I
> have noticed that there are several workarounds (hacks?) in the code
> that generates the data only to make it prettier once its pasted into
> excel. As an example a really complex code that breaks column titles
> into words and spawn it onto multiple cells only to try reserve some
> space for title not to overlap (since tab delimited data cannot
> specify column width).

Would you please tell me the names of the functions that do this,
so that I can be sure I'm looking in the right place? I think
there are several different sorts of "spreadsheet" output that
we create in various circumstances.

If it's some thousand-line function like
  void Ledger::write(xml::node& x) const
then maybe you could point to the approximate line number or copy
a few lines here.

> Do you think that we could put our ledger data into clipboard in
> multiple formats so that the end user favourite spreadsheet software
> could pick up the format it prefers the most and use? For example we
> could put "XML Spreadsheet" (xml based microsoft format for
> spreadsheets) _and_ TEXT data (tab delimited) so that if users prefers
> excel then he gets the pretty formatted data, and if he uses something
> else, then at least he has the data.
> 
> The huge 'pro' is that its simple to do (add some formatting to the
> existing tab_deimited.xsl template) and it allows us to drop those
> hacks from tab delimited data generation code mentioned above.

I'd like to keep it simple (or make it simple where it isn't yet).

What I don't see is why plain tab-delimited text isn't the simplest
choice. I imagine that all spreadsheet programs would handle that
well, and in particular the one from ms does.

Avoiding any platform-specific format seems like an easy way to
preserve software freedom by making sure our code works as well on
GNU/Linux as on any proprietary platform.

> Microsoft Excel keeps data in the clipboard in the following formats
[...]

They've been known to change their spreadsheet's API. I once wrote
an "add-in" for that spreadsheet. Then they removed the official,
published API I had used. That spreadsheet has its own way of
handling the clipboard, which is different from the way all their
other applications work; that might change, too. So might any
format they support today. And of course different versions of
their applications behave differently, even when they're
claimed to be compatible; that has already been a real problem
for us.

Lack of software freedom has practical disadvantages like that,
but freedom is a value in itself--it's more than just the best
solution to particular problems like this.

> To summarise the question -- do we want to simplify our current 'tab
> delimited' data format and in addition to it put 'XML Spreadsheet'
> into the clipboard?

I'm in favor of simplification in general, and we have much code
that isn't simple enough yet.

I would resist using on any proprietary ms format. I think tab-
delimited text meets our calculation-summary copy-and-paste needs
completely.