When using the Copy to clipboard function, the clipboard content can only be pasted successfully into Excel spreadsheets. In that case, the entire report is reproduced quite faithfully and requires only minor adjustments to column widths and possibly number formats (such as for number of decimal places):
When pasting into Numbers, LibreOffice Calc, Google Sheets, Word, and other document types, the HTML code for the report display itself is pasted, generally into a single cell or as raw text. For example, see screen shots from Numbers and Word:
I get the same results using Microsoft Windows 10
The data pastes correctly into Excel, apart from column size, number formats
But pastes as HTML code into Word, Notepad
If you save the Notepad file as a .html file, then it can be opened directly in Word but has formatting problems with spacing and also can be opened using a browser (sort of obvious this, I suppose)
HTML rendering in Word
For Libre Office read https://help.libreoffice.org/Common/Text_Import
So first save your copied data, for instance with Notepad, in a file and give this file an .html extension.
Then choose [File] - [Open] in Libre Office.
Again, a multi-step process involving an intermediate outside application and an extension modification.
That is obvious, I was just trying to be helpful for Libre Office users, no more no less.
So sorry for any inconvenience caused, and hereby I stop contributing to this forum.
I was not criticizing you, @ries. I was just reinforcing my original bug report. Personally, I hope you will continue your contributions.
Sometimes, forum members (myself included) offer workarounds and end up being misunderstood. I think the important thing is to get bugs fixed. But if any of us can help other users get around the problem before that happens, we should try.
I don’t see this as a bug in Manager.
Do these other spreadsheet programs support HTML pasting? It seems like LibreOffice does support HTML pasting but you need to use
Copy to Clipboard could be extended so you can either choose
Rich Text (HTML) or
Plain Text would work for Notepad and other simple text editors while spreadsheet should be able to support HTML. If they don’t,
Plain Text would.
Excel has the feature to fix this (not sure why it doesn’t do it automatically). Under
Home tab, you can click
Format button, then
AutoFit Row Height /
AutoFit Column Height
Numbers doesn’t seem to have this capability. A few minutes of research turns up information that delimitation characters are the issue. Several people report having written scripts to modify files, but I found nothing about pasting from the clipboard. Maybe somebody has more experience with Numbers than I do.
OK, then I will need to make the button being capable to copy to clipboard both HTML and plain text. This way any spreadsheet can be supported although if spreadsheet doesn’t support HTML then formatting will be lost.
LibreOffice support HTML input but it is not recognising the clipboard contents as containing HTML. When using Manager’s “Copy to clipboard” button, then LibreOffice’s “paste Special” only offers to paste text which when done puts all the HTML code in one cell.
I believe the clipboard can contain multiple formats of the copied data simultaneously together with labelling of the data type. It appears when using the copy to clipboard button in manager, only html is put in the clipboard and it’s data type is not set so it defaults to plain text.
In Manager manually selecting the reports contents, copying the selection then in LibreOffice “paste special” does enable selection of which data type to paste. Unfortunately it appears line termination is done with line feed not carriage return, so subsequent lines do not align columns when “Paste special” “stripped HTML” is used. “Paste special” “plane text” is not useful as the column delimiter is a space. “Paste special” “Rtf” also isn’t useful as it appears the line feeds are ignored completely.
A work around is to manually add the data type identifier outside of Manager as ries described
or use Manager’s “Export” button at the bottom of the reports which has tab delimited data (not sure if the line delimiter is cr or lf), so imports into spread sheets (without any formatting).
In summary I believe the bug in Manager is the copy to clipboard button is not setting the data type (so it defaults to plane text). An enhancement would be for the copy to clipboard button to save the data in more than one format (with labelling for each).
Interesting, I had noticed setting the clipboard data type was fairly straight forward from most programming languages, but had not thought through doing it from a web page. Clearly not as easy.
I suppose the options are
- Wait for the clipboard API to be accepted and incorporated into the web browser Manager uses. API initial draft is dated Nov 2006, so I suspect it maybe awhile before this options is available.
- Use an addon in the web bowser to allow more general clipboard access. Or restrict the functionality to a browser with greater clipboard access. Firefox has a clipboard API with access permission.
- Only save text to the clipboard
To expand on option 3, which maybe to easiest way of achieving reliable and flexible report exporting given current limitations.
- The current “Export” button could be repositioned and labelled “Copy to clipboard” give plane text is the only universal data type a web application can write to the clipboard.
- The current “Copy to clipboard” button could be relabelled “html” or “Save as html” and function similar to the current “PDF” / “Save as PDF” button. LibreOffice & Excel open .html files appropriately, I haven’t tested Numbers.
I do not know if this has been resolved else where.
I find the plain text copy to spreadsheets is my preferred option , rather than html copy.
Using Ubuntu and Libre office, the small export button is ample for my use.
The problem is the button only appears on built in reports. Custom reports look as if they have missed out.
Am I missing something??
No, @Malton, you have not missed anything. Custom reports are still a work in progress.