Bug 336776 - Add export of tabular data in HTML-based formats
Summary: Add export of tabular data in HTML-based formats
Status: CONFIRMED
Alias: None
Product: KEXI
Classification: Applications
Component: Migration/Import/Export (show other bugs)
Version: 2.8.3
Platform: unspecified All
: NOR wishlist
Target Milestone: ---
Assignee: Kexi Bugs
URL: https://invent.kde.org/office/kexi/-/...
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-26 21:02 UTC by Ian Balchin
Modified: 2023-04-03 21:30 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Sample PDF output (8.19 KB, application/octetstream)
2014-06-27 15:41 UTC, Jarosław Staniek
Details
pdf of kexi report (466.41 KB, application/octet-streamn)
2014-06-27 18:46 UTC, Ian Balchin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Balchin 2014-06-26 21:02:00 UTC
Primarily it should be possible to export data direct into a formatted html table

Reproducible: Always

Steps to Reproduce:
feature not yet available


Expected Results:  
Export of data in html table as an alternative to the csv format which is the only option currently provided.

Export of selected data in html format is a must. No end of data ends up on a static web page - see my catalogues on www.fables.co.za which except for the head and tail of the page are almost entirely created by perl scripts from delimited output from postgresql. Creating the scripts took a lot of time and although they do more than just export data to a table, in principle to have suitable formatted tabular html data output at a push of the button would be great. I note this feature was included in Paradox all those years back. Provision would be needed to format fields accordingly, not just a bare bones table, or you will only have done half the work. A major undertaking I fear.
Comment 1 Ian Balchin 2014-06-27 08:33:23 UTC
Export in plain text format should also be provided. I am looking at a really nice report layout but I cannot cut and paste this into my email from the report. :(

If I print to pdf I cannot select this text from within this either.  Is this a function of the linux print to pdf setup? Some pdf's allow you to select and copy text, others do not.

Ian
Comment 2 Ian Balchin 2014-06-27 09:10:53 UTC
I now see a tiny 'Report' button to the left of the main Data | Design | Print icons . It really needs a better icon.

This allows reports to be exported as Text/Spreadsheet/Webpage which should alleviate the above issues. The result of exporting to a web page looks fine on screen in a browser looks fine but of course retains no formatting for a sensible cut and paste. The export to text opens up in LibreOffice as a table! I'll file a bug later if there is no comment, this cannot be right.

So we still need a facility to export data as formatted text, but this could be better set up to be done from a report (and not as a data export). Data exported as html fine, this would be tabular with cells and rows matching fields and records. Data exported as text would maybe best be done from a Report to mimic the layout of the report.
Comment 3 Adam Pigg 2014-06-27 11:29:44 UTC
Hi ian

I wrote all those facilitate so blame me for how they work :)

I couldn't and still can't think of a way to export to a word processing format without it being I a tabular table. Report items are positioned differently to how text on a page flows. 

The default html output uses css to mimic the report structure, however you can also choose table format during the export.
Comment 4 Jarosław Staniek 2014-06-27 15:27:31 UTC
Good, thanks. Reduced scope of this wish to HTML-based output formats. 

I believe export to plain text files is another matter and can be handled by the Fixed Width Text export https://bugs.kde.org/show_bug.cgi?id=254621. We would benefit from another wish, "Add export of tabular data to plan text mode" when fields can be positioned freely with discrete coordinates but unlike for the tabular FWT output, positions are not automatically computed but have to be based on what Kexi report provides.

Secondly, specific needs while exporting to HTML differ so much between use cases that employing a template system would be beneficial. See http://en.wikipedia.org/wiki/Web_template_system for more pointers. Areas that users may want to customize:
- header/footer of the HTML page - it would come from external system (static or generated), it's in general outer area of the HTML table
- styling for table, rows, cells, (using CSS/Javascript or some other means)

If the employed template is flexible enough, useful XML and plain text export could be perhaps possible using the same feature. This needs investigation based on real world use cases.

Last note, there are at least two aproaches: 
1. Generating HTML from queries
2. Generating autoreports (example wizards and results at http://wiki.alphasoftware.com/Layout+Table+Reports+V11&structure=What%27s+New+in+Version+11) and using HTML export for the report. In theis case tasks to do is: introduce autoreports and enable strong parametrization of HTML export. Perhaps both are wishes to report on their own?
Comment 5 Jarosław Staniek 2014-06-27 15:36:50 UTC
@Ian " The export to text opens up in LibreOffice as a table!"

One day we renamed the action to "Export As -> Text Document" and our intention was "OpenDocument Text" format without using this (technical!) term. Of course in the future it would be possible to specify what format should be used for "Text Document" (sometimes users expect doc, docx).

"OpenDocument Text" confused some normal users (because of the prefix Open). Feel free to propose improvement here.

I perfectly understand you're looking for "Export As -> Plain Text Document" feature. Maybe it can be added as such as a separate action. For this, a wish like "Add export of tabular data to plain text format" would be a better place, as mentioned above (and mistyped plain->plan).
Comment 6 Jarosław Staniek 2014-06-27 15:41:54 UTC
Created attachment 87429 [details]
Sample PDF output
Comment 7 Jarosław Staniek 2014-06-27 15:44:05 UTC
@Ian "If I print to pdf I cannot select this text from within this either. Is this a function of the linux print to pdf setup? "

I printed a report with data to PDF (attached below: https://bugs.kde.org/attachment.cgi?id=87429), then opened in Okular. Selection, and copying works OK (as long as you can accept copying anything from PDF which is a largely unstructured format).
Comment 8 Jarosław Staniek 2014-06-27 15:46:10 UTC
(like most others, this wish applies to any Platform so I set unspecified/All)
Comment 9 Jarosław Staniek 2014-06-27 15:53:22 UTC
Regarding template engines, there's a lot choice for reuse. In aprticular, Qt-friendly Grantlee, look at the template language here: http://steveire.wordpress.com/2009/06/27/some-clarifications-regarding-grantlee/

Sure, I believe we want to pick widely used and stable template system that is not going to disappear.
Comment 10 Ian Balchin 2014-06-27 18:46:48 UTC
Created attachment 87434 [details]
pdf of kexi report

I did copy ok from your pdf sample.
Try this one, I cannot copy from it.

Ian
Comment 11 Adam Pigg 2014-06-27 18:52:25 UTC
You can see from that report that it is rendered as an image and not scalable.  Maybe its an option of how you generate the PDF?
Comment 12 Ian Balchin 2014-06-27 19:18:26 UTC
Are you saying that I can see visually that it looks like an image? If so the answer is yes it does look like an image. But I see no printed information saying 'image' which I have looked for.

It is printed from kexi using the Generic Cups-PDF Printer. There are no pdf-specific options attached to this - just the usual 'paper-size, margins, no of copies' etc.

What do you and Jaroslaw use to print a pdf from kexi that would do the job otherwise?
Comment 13 Adam Pigg 2014-06-27 19:35:41 UTC
In the KDE print dialog, I have an option to save as PDF or PS
Comment 14 Jarosław Staniek 2014-06-27 19:50:33 UTC
@Ian yes I would recommend using KDE's print but in principle Kexi shouldn't force to use KDE Plasma Dekstop...
Comment 15 Jarosław Staniek 2014-06-27 20:04:04 UTC
@Ian: They say oOn various forums and bug reports that "ps-pdf does not embed the fonts"

http://ubuntuforums.org/showthread.php?t=1153731

https://bugs.launchpad.net/ubuntu/+source/cups-pdf/+bug/366949

You use Linux Mint 13, so:

Someone said:
""The "Print to PDF" printer comes from the cups-pdf package; suggest you remove that and you use "Print to File" instead.""

but also try this hint: https://bugs.launchpad.net/linuxmint/+bug/816670/comments/6
Comment 16 Ian Balchin 2014-06-27 21:10:18 UTC
I have looked at all this. There is no doubt that it is the cups pdf printer that is responsible. I don't intend at this stage to change it, mainly because i don't want to break it, and because it is reliable. I don't seem to see the 'print to file' option anywhere so we can ignore that. The workaround that I used this morning was to get the data out of the html file created from the report. This was not bad. Let's not get totally subverted by this pdf issue, but thanks for all the effort put in here but enough is enough. I am feeling pretty guilty right now.

Let's not forget bug 335150 , a proper implementation of this will solve the problem totally!
Comment 17 Jarosław Staniek 2014-06-29 20:02:13 UTC
Yes, performing task #335150 is the ultimate way to address the core issue.