|
|
Home » U++ Library support » RichText,QTF,RTF... » Weird problems with Report / PDF Export / Printing, sometimes even crashes
Weird problems with Report / PDF Export / Printing, sometimes even crashes [message #39000] |
Tue, 05 February 2013 21:15 |
frozen
Messages: 13 Registered: January 2013
|
Promising Member |
|
|
Hello guys!
I hit another problem. Ultimate++ is awesome, but as a newbie I guess I need some time to find out how everything works, especially in case of a problem. Now I hit another such problem and hope for help.
If this is the wrong section of the forum or I missed to add some important information, please tell me!
Sorry for the huuuge width of this post - I included my code as is.
I am running version 5739 on a Debian system (compiler is gcc), using the nightly package from the repository. The application I develop is intended to run on Linux and Windows.
This system doesn't have a physical printer, instead CUPS is configured to use a PDF printer (Debian package cups-pdf).
The latest thing I tried was to add a menu item that shows a QTF-Document - ready to be printed.
This is the callback for this menu entry:
Quote: |
void MyApp::preisliste()
{
Report r;
Size s;
r.ChooseDefaultPrinter("Preisliste");
s = Size(6000 * 210 / 254, 6000 * 297 / 254);
r.SetPageSize(s);
r.Margins(100, 100);
String preisliste;
preisliste << "[ [ [*2 Preisliste]&][2 &][ [2 Alle Preise sind Preise pro Anwesenheitstag.]&][2 &][ {{1935:1612:1612:1612:1612:1617h1; [= [2 Bezeichnung]]:: [= [2 Stufe 0]]:: [= [2 Stufe I]]:: [= [2 Stufe II]]:: [= [2 Stufe III]]:: [= [2 Stufe III Härtefall]]:: [ [2 Tagespflege]]:: [> [2 `_`_Preis0`_`_€]]:: [> [2 `_`_Preis1`_`_€]]:: [> [2 `_`_Preis2`_`_€]]:: [> [2 `_`_Preis3`_`_€]]:: [> [2 `_`_Preis4`_`_€]]:: [ [2 Altenpflegeumlage ][`2 `*]]:: [> [2 `_`_APU0`_`_€]]:: [> [2 `_`_APU1`_`_€]]:: [> [2 `_`_APU2`_`_€]]:: [> [2 `_`_APU3`_`_€]]:: [> [2 `_`_APU4`_`_€]]:: [ [2 Investitionskosten ][`2 `*`*]]:: [> [2 `_`_IKP0`_`_€]]:: [> [2 `_`_IKP1`_`_€]]:: [> [2 `_`_IKP2`_`_€]]:: [> [2 `_`_IKP3`_`_€]]:: [> [2 `_`_IKP4`_`_€]]:: [ [2 Unterkunft]]:: [> [2 `_`_U0`_`_€]]:: [> [2 `_`_U1`_`_€]]:: [> [2 `_`_U2`_`_€]]:: [> [2 `_`_U3`_`_€]]:: [> [2 `_`_U4`_`_€]]:: [ [2 Verpflegung]]:: [> [2 `_`_V0`_`_€]]:: [> [2 `_`_V1`_`_€]]:: [> [2 `_`_V2`_`_€]]:: [> [2 `_`_V3`_`_€]]:: [> [2 `_`_V4`_`_€]]:: [ [2 Unterkunft `+ Verpflegung]]:: [> [2 `_`_UV0`_`_€]]:: [> [2 `_`_UV1`_`_€]]:: [> [2 `_`_UV2`_`_€]]:: [> [2 `_`_UV3`_`_€]]:: [> [2 `_`_UV4`_`_€]]}}&][>2 &][# [`2 `*][2 Die Altenpflegeumlage ist im Preis für die Tagespflege enthalten.]&][# [`2 `*`*][2 Die Investitionskosten werden von der örtlichen Kommune übernommen.]&][#2 &][# [*2 Leistungen der Pflegekasse (normal)]&][#2 &][# [2 Ambulante Pflege hat Vorrang vor Tagespflege. Die Leistungen der Pflegekasse sind jeweils pro Monat zu verstehen.]&][#2 &][ {{1935:1612:1612:1612:1612:1617h1; [= [2 Bezeichnung]]:: [= [2 Stufe 0]]:: [= [2 Stufe I]]:: [= [2 Stufe II]]:: [= [2 Stufe III]]:: [= [2 Stufe III Härtefall]]:: [# [2 Pflegesachleistung (100 Prozent)]]:: [> [2 `_`_SachLeistung100St0`_`_€]]:: [> [2 `_`_SachLeistung100St1`_`_€]]:: [> [2 `_`_SachLeistung100St2`_`_€]]:: [> [2 `_`_SachLeistung100St3`_`_€]]:: [> [2 `_`_SachLeistung100St4`_`_€]]:: [# [2 Pflegesachleistung (50 Prozent)]]:: [> [2 `_`_SachLeistung50St0`_`_€]]:: [> [2 `_`_SachLeistung50St1`_`_€]]:: [> [2 `_`_SachLeistung50St2`_`_€]]:: [> [2 `_`_SachLeistung50St3`_`_€]]:: [> [2 `_`_SachLeistung50St4`_`_€]]:: [# [2 Pflegesachleistung (150 Prozent)]]:: [> [2 `_`_SachLeistung150St0`_`_€]]:: [> [2 `_`_SachLeistung150St1`_`_€]]:: [> [2 `_`_SachLeistung150St2`_`_€]]:: [> [2 `_`_SachLeistung150St3`_`_€]]:: [> [2 `_`_SachLeistung150St4`_`_€]]:: [# [2 Pflegegeld]]:: [> [2 `_`_PG0`_`_€]]:: [> [2 `_`_PG1`_`_€]]:: [> [2 `_`_PG2`_`_€]]:: [> [2 `_`_PG3`_`_€]]:: [> [2 `_`_PG4`_`_€]]}}&][#2 &][# [*2 Leistungen der Pflegekasse (bei eingeschränkter Alterskompetenz)]&][#2 &][# [2 Ambulante Pflege hat Vorrang vor Tagespflege. Die Leistungen der Pflegekasse sind jeweils pro Monat zu verstehen.]&][#2 &][ {{1935:1612:1612:1612:1612:1617h1; [= [2 Bezeichnung]]:: [= [2 Stufe 0]]:: [= [2 Stufe I]]:: [= [2 Stufe II]]:: [= [2 Stufe III]]:: [= [2 Stufe III Härtefall]]:: [# [2 Pflegesachleistung (100 Prozent)]]:: [> [2 `_`_SachLeistungeA100St0`_`_€]]:: [> [2 `_`_SachLeistungeA100St1`_`_€]]:: [> [2 `_`_SachLeistungeA100St2`_`_€]]:: [> [2 `_`_SachLeistungeA100St3`_`_€]]:: [> [2 `_`_SachLeistungeA100St4`_`_€]]:: [# [2 Pflegesachleistung (50 Prozent)]]:: [> [2 `_`_SachLeistungeA50St0`_`_€]]:: [> [2 `_`_SachLeistungeA50St1`_`_€]]:: [> [2 `_`_SachLeistungeA50St2`_`_€]]:: [> [2 `_`_SachLeistungeA50St3`_`_€]]:: [> [2 `_`_SachLeistungeA50St4`_`_€]]:: [# [2 Pflegesachleistung (150 Prozent)]]:: [> [2 `_`_SachLeistungeA150St0`_`_€]]:: [> [2 `_`_SachLeistungeA150St1`_`_€]]:: [> [2 `_`_SachLeistungeA150St2`_`_€]]:: [> [2 `_`_SachLeistungeA150St3`_`_€]]:: [> [2 `_`_SachLeistungeA150St4`_`_€]]:: [# [2 zusätzliche Betreuungsleistung]]:: [> [2 `_`_PK45`_`_€]]:: [> [2 `_`_PK45`_`_€]]:: [> [2 `_`_PK45`_`_€]]:: [> [2 `_`_PK45`_`_€]]:: [> [2 `_`_PK45`_`_€]]:: [# [2 zusätzliche Betreuungsleistung (erhöht)]]:: [> [2 `_`_PK45`+`_`_€]]:: [> [2 `_`_PK45`+`_`_€]]:: [> [2 `_`_PK45`+`_`_€]]:: [> [2 `_`_PK45`+`_`_€]]:: [> [2 `_`_PK45`+`_`_€]]:: [# [2 Pflegegeld]]:: [> [2 `_`_PGeA0`_`_€]]:: [> [2 `_`_PGeA1`_`_€]]:: [> [2 `_`_PGeA2`_`_€]]:: [> [2 `_`_PGeA3`_`_€]]:: [> [2 `_`_PGeA4`_`_€]]}}&][#2 &][# [2 Die zusätzlichen Betreuungsleistungen können zur Abrechnung von allen Leistungen der Tagespflege genutzt werden, inklusive Fahrtkosten.]&][# &][> [*1 alle Angaben ohne Gewähr]]]";
// here we have lots of Replaces, I included just one example..
preisliste.Replace("`_`_PK45`+`_`_", Format("%2,!nl", 200.0));
r << preisliste;
Perform(r);
}
|
It compiles without error.
When I click the menu entry the list shows in the print preview with all the replaces done.
The problems are:
- When I click PDF-Export I can save a PDF-File. This looks okay. But the page is too big, 227x314 mm instead of 210x297 mm.
- When I click Print it seems to print - but the resulting PDF is empty, 2.3 Kb in size but the empty page has the correct dimensions.
- I changed the code to show the Printer selection dialog by replacing ChooseDefaultPrinter with ChoosePrinter. When I select the printer manually this way and click Print the program crashes immediately, showing "Fatal error" with the message
"Assertion failed in /home/frozen/upp/uppsrc/Core/Vcont.h, line 33
i >= 0 && i < items"
It creates the same empty PDF than before though.
The QTF was created with the QTF designer.
Could the problem be cups-pdf? It prints well using other programs, but it is not a physical printer..
How do I fix the dimensions of the PDF created by the PDF-Export?
I am stuck on both problems.
Kind regards,
frozen
(Update: changed code section to a quote section so that this page renders normally and is no longer that wide..)
[Updated on: Fri, 08 February 2013 01:08] Report message to a moderator
|
|
|
|
|
Re: Weird problems with Report / PDF Export / Printing, sometimes even crashes [message #39030 is a reply to message #39000] |
Fri, 08 February 2013 01:06 |
frozen
Messages: 13 Registered: January 2013
|
Promising Member |
|
|
Update:
Is it possible, that Report is rather to be used very carefully? Maybe even buggy?
Today I spent some hours playing around with the report.
I couldn't fix it but I found some confusing things.
Removing everything manipulating the output (so it is just Report r; r << preisliste; Perform(r); ) leads to no more crashes! The page that is printed has exactly the correct size - but now we have TWO pages! And magically there is some rather big margin added all around the pages.
But the exported PDF now is too small. 185mm x 274mm. It also gets some margins, but these are smaller than the ones from the "print". This PDF also has two pages.
Just putting r.Margins(100,100); back into the code changes things a lot.
It still doesn't crash on printing. The resulting print still has two pages and the correct size. It has very small margins to the left and top. On the right and bottom the margins are huge though. As if the margins from the previous try were combined on the right and bottom.
The exported PDF is exactly the same as it was when Margins() wasn't used.
Using r.Margins(200,200) doesn't change the exported PDF. It is exactly the same again.
On the printed document the margins are larger now, the content seems to be shifted around by them.
Using no r.Margins() but reinserting r.SetPageSize(s); leads to a printed document that has one page, the correct size and absolutely no margins.
The exported PDF also has just one page but it added margins all around the document. It seems these margins are added to the size I have set which results in a page size that is too big.
Combining r.Margins(200,200) and r.SetPageSize(s) just adds the left and top margins to the printed document, leaving none to the right and bottom - and thus moving some content outside of the page.
The exported PDF again doesn't change compared to the one with just size set.
As a last test I readded the ChoosePrinter() without setting margins or size - boom, printing leads to the crash.
The exported PDF now is again too small and has two pages with some margins.
This is pretty confusing...
I expect
- the printed document to look the same as the exported PDF. In no situation this was achieved.
- r.Margins() to set a margin all around the page, but at least to the left and top (as it is documented) without changing the right and bottom one.
- r.ChoosePrinter() or r.ChooseDefaultPrinter() not to lead to a crash.
Should my expectations be wrong but the code right, could someone please tell me how I can build this functionality? Maybe I need to "build it by hand" by drawing all the texts using Draw or DrawingDraw and/or PDFDraw and a PrinterJob and a TopWindow or maybe a Ctrl to do a preview (please say I don't have to do this.. )?
Thanks again,
frozen
|
|
|
Re: Weird problems with Report / PDF Export / Printing, sometimes even crashes [message #39056 is a reply to message #39000] |
Mon, 11 February 2013 19:58 |
|
mirek
Messages: 14039 Registered: November 2005
|
Ultimate Member |
|
|
1. Problems with ChooseDefaltPrinter/ChoosePrinter - these were bugs in POSIX version of PrinterJob, now fixed (with some additional improvements). (Commited to svn).
2. The page size issue - this one is quite tricky.
The main issue to consider here is that physical size of paper is not the same as printable area and that we do not really know what printable area is. In this sense, ChoosePrinter / ChooseDefaultPrinter do not quite do the correct thing (they are added to much later), as they set the report page size to physical size...
Anyway, under normal circumstances, the page size is decision of program (well, mostly we want consistent report output at all times, do not we?). There is some conservative default value for pagesize, which can be increased by Report::SetPageSize.
What happens during printing process (in POSIX it is CUPS doing) is that pages are rendered to this SetPageSize size, then printed centered with the physical page size.
Margin then is only simple too to move top-left offset instead of centering.
I have also tested Pdf output, it seems quite consistent with printed output (BTW, in my Linux PDF viewer there is "Fit to page" option that is on by default, it can skew results when testing).
|
|
|
Re: Weird problems with Report / PDF Export / Printing, sometimes even crashes [message #39057 is a reply to message #39056] |
Mon, 11 February 2013 21:17 |
frozen
Messages: 13 Registered: January 2013
|
Promising Member |
|
|
Thank you very much!
I couldn't get a new nightly debian package yet, so I couldn't try. Hopefully the debian package will be updated soon. Looking into the SVN commit I think it could change some behavior I have problems with.
Special thanks for explaining how all this works internally. This helps a lot to understand what is happening.
mirek wrote on Mon, 11 February 2013 19:58 | (BTW, in my Linux PDF viewer there is "Fit to page" option that is on by default, it can skew results when testing).
|
Yes, I always checked the size of the document by looking into the properties of the document, not the visual appearance alone.
I am now waiting for the new nightly package to arrive. Should this take too long I might use the SVN version for testing. That debian package is preferred though..
Again, thank you very much!
Kind regards,
frozen
|
|
|
Re: Weird problems with Report / PDF Export / Printing, sometimes even crashes [message #39058 is a reply to message #39057] |
Mon, 11 February 2013 21:20 |
|
mirek
Messages: 14039 Registered: November 2005
|
Ultimate Member |
|
|
frozen wrote on Mon, 11 February 2013 15:17 | Thank you very much!
I couldn't get a new nightly debian package yet, so I couldn't try. Hopefully the debian package will be updated soon. Looking into the SVN commit I think it could change some behavior I have problems with.
Special thanks for explaining how all this works internally. This helps a lot to understand what is happening.
mirek wrote on Mon, 11 February 2013 19:58 | (BTW, in my Linux PDF viewer there is "Fit to page" option that is on by default, it can skew results when testing).
|
Yes, I always checked the size of the document by looking into the properties of the document, not the visual appearance alone.
I am now waiting for the new nightly package to arrive. Should this take too long I might use the SVN version for testing. That debian package is preferred though..
Again, thank you very much!
Kind regards,
frozen
|
Give svn a thought. In the end, it is the most convenient way to keep yourself in sync with development.
|
|
|
|
Re: Weird problems with Report / PDF Export / Printing, sometimes even crashes [message #39062 is a reply to message #39059] |
Mon, 11 February 2013 23:38 |
|
mirek
Messages: 14039 Registered: November 2005
|
Ultimate Member |
|
|
frozen wrote on Mon, 11 February 2013 15:45 |
mirek wrote on Mon, 11 February 2013 21:20 | Give svn a thought. In the end, it is the most convenient way to keep yourself in sync with development.
|
I did and retried with 5797.
Just the first test showed wrong pages size again when using PDF export, setting no sizes, margins or anything else.
|
I have not read into details, but it looks like you are comparing CUPS generated PDF with U++ generated one. If that is so, then our metodology differs: What I have done is to print the report on real printer, then export PDF and print it on the same printer too. Results look identical (maybe there is some small offset).
Mirek
|
|
|
Re: Weird problems with Report / PDF Export / Printing, sometimes even crashes [message #39065 is a reply to message #39062] |
Tue, 12 February 2013 00:18 |
frozen
Messages: 13 Registered: January 2013
|
Promising Member |
|
|
mirek wrote on Mon, 11 February 2013 23:38 |
I have not read into details, but it looks like you are comparing CUPS generated PDF with U++ generated one. If that is so, then our metodology differs: What I have done is to print the report on real printer, then export PDF and print it on the same printer too. Results look identical (maybe there is some small offset).
Mirek
|
I think I understand. That's a problem for me.
My application should be able to create PDF documents AND prints that comply with DIN 5008. This is a industry norm here in germany, which contains a lot of rules defining where what has to be placed on a document. Have a look at the images on http://www.pt-mediengestaltung.de/thema.html - they show quite a lot of these placements that have to be hit precisely.
Currently I don't see a way to comply with that norm using reports and QTF. So I guess I have to reinvent the wheel, adding this functionality. This will be tough for me as a newbie with U++.. I hoped there was a workaround or a way to reach something that is at least close using reports and applying fixed margins and page size. As far as I understand now, this is not possible, right?
I hope you might help me again when I have questions during my tries to implement this stuff..
Thanks again!
Kind regards,
frozen
|
|
|
|
Re: Weird problems with Report / PDF Export / Printing, sometimes even crashes [message #39067 is a reply to message #39066] |
Tue, 12 February 2013 08:16 |
|
mirek wrote on Tue, 12 February 2013 02:08 | Well, I would say we are not that far from that, at least for physical prints. You can replace automatic centering with Margin (in fact, it should rather be called "offset" or perhaps "topleft") and physical prints should be ok (but take into account that with real printers, there will be up to 5 mm difference from one sheet printed to another).
After that, I am willing to change PDF export too to comply, but I guess it might require some new parameters to Report/PdfDraw.
Mirek
|
If I may suggest something. In one of my app I had Report class and it collided with Upp class. In my uppsrc copy I changed Report class to ReportDraw. Could we do similar change ? Report is a very popular term and should not be reserved by a toolkit IMO. I know I could use upp namespace but most of my code starts with: using namespace Upp
|
|
|
Re: Weird problems with Report / PDF Export / Printing, sometimes even crashes [message #39068 is a reply to message #39067] |
Tue, 12 February 2013 08:20 |
|
mirek
Messages: 14039 Registered: November 2005
|
Ultimate Member |
|
|
unodgs wrote on Tue, 12 February 2013 02:16 |
mirek wrote on Tue, 12 February 2013 02:08 | Well, I would say we are not that far from that, at least for physical prints. You can replace automatic centering with Margin (in fact, it should rather be called "offset" or perhaps "topleft") and physical prints should be ok (but take into account that with real printers, there will be up to 5 mm difference from one sheet printed to another).
After that, I am willing to change PDF export too to comply, but I guess it might require some new parameters to Report/PdfDraw.
Mirek
|
If I may suggest something. In one of my app I had Report class and it collided with Upp class. In my uppsrc copy I changed Report class to ReportDraw. Could we do similar change ? Report is a very popular term and should not be reserved by a toolkit IMO. I know I could use upp namespace but most of my code starts with: using namespace Upp
|
You can still use namespaces even if you are "using".
Anyway, name clashes happen, in this particular case I would mind renaming to ReportDraw, but it would be backward incompatibility...
Mirek
|
|
|
Re: Weird problems with Report / PDF Export / Printing, sometimes even crashes [message #39069 is a reply to message #39066] |
Tue, 12 February 2013 08:28 |
frozen
Messages: 13 Registered: January 2013
|
Promising Member |
|
|
mirek wrote on Tue, 12 February 2013 08:08 | Well, I would say we are not that far from that, at least for physical prints. You can replace automatic centering with Margin (in fact, it should rather be called "offset" or perhaps "topleft") and physical prints should be ok (but take into account that with real printers, there will be up to 5 mm difference from one sheet printed to another).
After that, I am willing to change PDF export too to comply, but I guess it might require some new parameters to Report/PdfDraw.
Mirek
|
I see. So you think the calculations are reasonable precise to an error level of about a millimeter or two (more difference from intended positions could lead to trouble when the printer adds another 5 millimeters...) when I set up a table, using the relative distribution of columns and spaces with a precise font size and fixed margins for the cells. To be honest I had my doubts, when seeing all these differences with set and not set pagesizes or margins.
I will try this as soon as I find the time to do so.
New parameters for Report/PdfDraw are no problem for me.
Thanks again, I will tell how things went after trying to create the first complying report.
Kind regards,
frozen
|
|
|
Re: Weird problems with Report / PDF Export / Printing, sometimes even crashes [message #39071 is a reply to message #39068] |
Tue, 12 February 2013 10:07 |
|
mirek wrote on Tue, 12 February 2013 02:20 |
You can still use namespaces even if you are "using".
|
You're right, I just don't like it
Quote: |
Anyway, name clashes happen, in this particular case I would mind renaming to ReportDraw, but it would be backward incompatibility...
|
Yes, that's a pity. All my bigger projects have their own uppsrc copy and that's why I never think about backward compatibility. I think that from time to time we could consider breaking it to clean up broken things or to introduce better design (like rgba Color in Draw)
|
|
|
Goto Forum:
Current Time: Fri Sep 20 19:57:47 CEST 2024
Total time taken to generate the page: 0.03421 seconds
|
|
|