Bug 336776

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

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.

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.

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?

@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).

Created attachment 87429 [details]
Sample PDF output

@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).

(like most others, this wish applies to any Platform so I set unspecified/All)

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.

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

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?

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?

In the KDE print dialog, I have an option to save as PDF or PS

@Ian yes I would recommend using KDE's print but in principle Kexi shouldn't force to use KDE Plasma Dekstop...

@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

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!

Yes, performing task #335150 is the ultimate way to address the core issue.